Hello,
when it occurs again, get the backtrace with gdb using the PIDs from all
kamailio processes eating lot of CPU.
Btw, what version are you using (kamailio -V)?
Cheers,
Daniel
On 6/25/12 9:43 AM, Konstantin M. wrote:
do you have
heavy traffic on that instance? How many children have
you configured?
Yes, but only a voip. There are over 10k calls per day.
fork=yes
children=4
This configuration is working during 1.5 months without any issues
till now...
What you can do is to attach with gdb to a
process using lot of CPU
and do the backtrace:
gdb /path/to/kamailio __pid__
Replace __pid__ with the PID of process eating the CPU. Then run bt
It may be a deadlock/infinite loop somewhere. I saw three processes
in top,
others were down with no much cpu usage.
Is the SIP routing going fine anyhow when CPU
usage is high?
It hard to say 'yes', when looking to call graphs (rrd) I saw that the
calls throughput was slow down...
Looking to logs/PCAP's/etc I'm seeing that some of calls were
processed though (perhaps some of working forks).
But there were > 75-80% of failed calls with 478 Request Terminated.
Also by analyzing a PCAP flows I saw that more than 70% of calls were
de-jittered, de-sync'ed in RTP timestamps, etc...
How do you solve it, by restart or it just
appears from time to time
and solves itself periodically?
I did not restarted kamailio during 20 days, following a charts this
problem was re-appeared during 2 days.
After restart of kamailio -- I can't see any issues for now, there is
0.00 on CPU by all of kamailio instance/forks/etc...
Cheers,
Daniel
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users