<div dir="auto">Hi Neels,<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Mar 14, 2017 03:05, "Neels Hofmeyr" <<a href="mailto:nhofmeyr@sysmocom.de">nhofmeyr@sysmocom.de</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Mon, Mar 13, 2017 at 11:01:57PM +0100, Keith wrote:<br>
> I temporarily disabled a cron job we run at rhizomatica that purges the<br>
> hlr SMS table of sent messages every day.<br>
><br>
> After a few days I noticed slightly sluggish behaviour in the VTY, and<br>
> sure enough, the nitb was consuming 100% cpu, not always, but presumably<br>
> whenever it does a queue run.<br>
<br>
</div>Hmm, that's a very vague indicator. How performant is the hardware? For how<br>
long does this load endure? Does the process hang otherwise, is service<br>
disrupted?<br>
<br>
>From how I got to know the SMS code, it appears to have sound safeguards in<br>
place, e.g.  limits the number of SMS to be delivered per queue run, and only<br>
attempts deliveries of SMS for actually attached subscribers ... But in fact we<br>
don't have load testing in place. It would be good to find out where<br>
unproportional CPU load is coming from -- SQlite? The NITB sms code? From a<br>
theoretical standpoint I'd also expect the SMS database to discard messages<br>
that are past a certain age, not sure though, as I'm not that deeply familiar<br>
with that (yet).<br>
<br>
Would be good to know: how many SMS are pending, for how many subscribers, of<br>
which how many are currently attached? How often are SMS deliveries being<br>
retried and end in failure? ... and anything else you can think of.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">We looked into this a couple years ago, but didn't come up with a good solution context switched to something else.</div><div dir="auto"><br></div><div dir="auto">Just add a few thousand SMS to the DB (DB should 10Mb or more roughly) and start OsmoNITB. You'll notice it's agony immediately.</div><div dir="auto"><br></div><div dir="auto">It's been a while, but IIRC the issue is that the DB didn't have proper indexes for the kinds of queries we're running on it, so it's getting super inefficient.</div><div dir="auto"><br></div><div dir="auto">Regarding removing SMS - it should be fine based on validity time of the SMS and it was completely broken. I had a patch set which fixed validity time handling, but IIRC it wasn't merged. We can probably dug it up, but I don't have much time to rebase / adapt it to the new codebase right now. If there are any volunteers, that would be great.</div><div dir="auto"><br><span style="font-family:sans-serif">Please excuse typos. Written with a touchscreen keyboard.</span><br style="font-family:sans-serif"><br style="font-family:sans-serif"><span style="font-family:sans-serif">--</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">Regards,</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">Alexander Chemeris</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">CTO/Founder Fairwaves, Inc.</span><br style="font-family:sans-serif"><span style="font-family:sans-serif"><a href="https://fairwaves.co">https://fairwaves.co</a></span><br></div><div class="gmail_extra" dir="auto"></div></div>