8 Oct
2018
8 Oct
'18
3:59 a.m.
Hi Henning,
Right you are.
Beta trial system with low traffic running on 3 listening interfaces in
udp&tcp&tls + one alternative port in UDP&TCP on public interfaces.
Considering children=4, that makes indeed a lot of processes in total.
The 'problem' should go away by itself once this goes in production.
Meanwhile, I'll look into familiarizing myself with the '*socket_workers**=*'
settings which I just discovered.
Thanks.
On Sun, Oct 7, 2018 at 4:31 PM Henning Westerholt <hw(a)kamailio.org> wrote:
Am Montag, 1. Oktober 2018, 05:25:28 CEST schrieb
Sergiu Pojoga:
I'm trying to understand why some Kamailio
processes become Connor
MacLeod
and go to live forever causing high # of aborted
connections.
While watching in time over *SHOW PROCESSLIST*, some 12 kamailio
connections in *SLEEP* state, most of them are reused over time (time
value
gets reset). However, a select few go on to SLEEP
forever for as much as
the mysql's *wait_timeout* allows them to. Default was 28800 sec, that's
how long they lived. If I lower this to say 600 sec, even higher abort
rate
is observed.
I suppose my questions are:
1. Is this normal to have so many SLEEPing connections?
2. What is the recommended MySQL *wait_timeout* value under Kamailio?
3. Any other suggestions as to why such a high rate of aborted
connections?
Hello Sergiu,
it depends a bit on your configuration - but one reason could be that you
start n kamailio processes for each of your local network interfaces. And
if
you don't see any SIP traffic on this interfaces, then the Kamailio will
sleep
and you can see this aborted connections.
You should be able to check this with e.g. netstat and ps.
Best regards,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio security assessment - https://skalatan.de/de/assessment