Thanks for the reply.<br><br>I would also lean to the DB as the problem but I have also experienced it with about the same frequency when not using any database modules and low or now calls. <br>So if you could point me to the patch you refereed to I would appreciate it. I'll then run it through a scripted process of restarting to try to reproduce and catch the problem (as time permits).<br>
<br>Thanks again for all your work with development and support!!<br><br>Dave (cando)<br><br><div class="gmail_quote">On Fri, Aug 27, 2010 at 2:02 AM, Bogdan-Andrei Iancu <span dir="ltr"><<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Dave,<br>
<br>
At sthutdown, opensips modules are mainly doing memory cleanup (dialog,<br>
transactions, caches, etc) or data flush to DB (dialogs, usrloc, etc).<br>
<br>
As memory cleanup is predictable as time and not resource consuming, I<br>
would say it is something related to DB flush - some DB ops that take<br>
random number of (mili) seconds, depending on the DB server load.<br>
<br>
A simple patch to report the shutdown duration of each module can be<br>
made if you consider it helpful - but I suspect the DB ops.<br>
<div class="im"><br>
Regards,<br>
Bogdan<br>
<br>
Dave Singer wrote:<br>
</div><div><div></div><div class="h5">> Sometimes when I'm do a restart on opensips (using init.d script, with<br>
> some customization to handle this problem) opensips takes quite a bit<br>
> of time, like 30 - 50 seconds to stop. Other times it is very quick.<br>
> I'm using 1.6.2 and 1.6.3.<br>
> The servers are fairly busy, less then 200 calls per sec, with around<br>
> 1000 sustained open calls.<br>
> I am using dialog module and db mode is 3 (on shutdown) with<br>
> postgresql 8.4. However since sometimes it is very quick with the same<br>
> call volume it doesn't "feel" like this is the problem. Further I have<br>
> had it be slow to stop when testing a config that is not using dialog<br>
> at all and there are no active calls or any sip activity when I try to<br>
> stop it.<br>
> My hunch is slightly toward it is waiting on a transaction but not so<br>
> sure.<br>
><br>
> The pertinent part of my init.d script customizations are for after<br>
> sending opensips the kill <pid> signal to every 0.1 seconds check if<br>
> it has stopped yet then start it back up.<br>
><br>
> Needless to say, having it take 50 seconds to restart, and not<br>
> responding to sip traffic does not make customers happy when your<br>
> dealing with thousands of call. :(<br>
><br>
> Any thoughts or things to try would be appreciated.<br>
><br>
> Thanks<br>
><br>
> cando<br>
</div></div><div><div></div><div class="h5">> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
<br>
<br>
--<br>
Bogdan-Andrei Iancu<br>
OpenSIPS Bootcamp<br>
20 - 24 September 2010, Frankfurt, Germany<br>
<a href="http://www.voice-system.ro" target="_blank">www.voice-system.ro</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br>