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...