Hi Royee,
So, my primary suspicion on the save() points to the event routes - to
confirm this, you can use the benchmark module to log the required time
to execute those routes. And whenever you have an alert on save(), you
can correlate it with the execution time for the event routes.
On the t_relay() part, it may be more complicated, as the TM module has
a complex system of callbacks that are triggered (inline) . And there
are many modules using the TM callbacks , any of them potentially
delaying the t_relay() action. Another reason may be DNS lookups, if
your relaying is DNS based (and not IP based).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/06/2018 10:30 AM, Royee Tichauer wrote:
Thanks for lead Bogdan we will look into it.
Do you also have any idea why the t_relay was blocking for so long?
Royee
On Mon, Feb 5, 2018 at 7:23 PM Bogdan-Andrei Iancu
<bog...@opensips.org <mailto:bog...@opensips.org>> wrote:
Hi Royee,
I don't think it is related to xmlrpc - there are separate
connection, separate processes for this.
I would rather suspect the event routes - the event is in-line
handled in usrloc, so the save() will cover the delivery/handling
of the contact related events. And if you do something time
consuming in event_route[E_UL_CONTACT_INSERT] lets say, this will
reflect as processing time for the save() function.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/05/2018 06:44 PM, Royee Tichauer wrote:
Bogdan,
Not sure I follow about breaking each function. What do you mean
by 'actual internal save()'?
DB insert is not used.
We use:
event_route[E_UL_CONTACT_UPDATE]
event_route[E_UL_CONTACT_DELETE]
event_route[E_UL_CONTACT_INSERT]
btw, we also use the mi_xmlrpc_ng constantly for monitoring if
that might have something to do with it (I saw a comment on
opensips 1.6 that there was an opensips blocking issue in some
cases).
Royee
On Mon, Feb 5, 2018 at 6:34 PM Bogdan-Andrei Iancu
<bog...@opensips.org <mailto:bog...@opensips.org>> wrote:
Hi Royee,
Well, you need to break for each function the possible types
of actions. Like for save():
- actual internal save()
- DB insert if realtime mode used
- potential events triggering - do you use any usrloc
related events ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/05/2018 06:20 PM, Royee Tichauer wrote:
Hi Bogdan, as the logs show:
save - 8912725us
t_relay - 5355333us
Let me know if you have any ideas,
Thanks,
Royee
On Mon, Feb 5, 2018 at 5:50 PM Bogdan-Andrei Iancu
<bog...@opensips.org <mailto:bog...@opensips.org>> wrote:
Hi Royee,
what are the time values reported for 't_relay' and
'save' ? the 50ms threashold may not be so relevant for
explaining delays of seconds.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit 2018
http://www.opensips.org/events/Summit-2018Amsterdam
On 02/05/2018 02:09 PM, Royee Tichauer via Users wrote:
Hi,
We are using opensips 2.1 as an SBC component and we
see that we have loss of registrations happening once
in a while. When we captured SIP we saw that some
messages are being delayed by a couple of seconds. We
enabled 'exec_execute_message=50000' and saw in the
logs that opensips core methods like 't_realy' and
'save' . I looked at SAR during this time and there are
no indications of CPU running high during this time.
Can you help me figure out this issue?
Thanks,
Royee
Logs:
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
