|Summary:||ASTERISK-14300: After 20 mins with heaviy traffic it blocks|
|Reporter:||Private Name (falves11)||Labels:|
|Date Opened:||2009-06-10 15:21:30||Date Closed:||2009-06-15 12:23:33|
|Description:|| utils.c:1074 ast_wait_for_output: Timed out trying to write|
I am suddenly out of business. Is it a version issue or something is wromg with my box?
****** ADDITIONAL INFORMATION ******
do know what happens, it started today. this is my ulimit
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 400000
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 400000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1056768
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
I am not using udptl.conf, but its range is 1500-4999
|Comments:||By: Private Name (falves11) 2009-06-11 19:46:55|
if I do this at the Linux command prompt:
lsof -i | wc -l
The number keeps groing even if we keep the same amount calls, and calls per seconds, flowing through. That's why it blows up after a while. everything started, I am guessing, when I added this to file the sip.conf
Which we need because our carriers keep the calls hanging.
By: Private Name (falves11) 2009-06-11 19:56:11
It does not seem to be related. The growth still goes on, however, slower.
By: Private Name (falves11) 2009-06-11 20:24:15
It is related and I can prove it. The amount of handles declines when we are not using Session Timers and the amount of calls goes down. So the culprit is Session Timers, it has a handle leak.
By: Private Name (falves11) 2009-06-12 09:43:33
It is not related. I disabled Session Timers and UDPTL (T38) support in my sip.conf, but the handle cpunt keeps growing. It is now in 15600 handles with only 545 calls open, and I am using directrtpsetup=yes, so no media goes through me.
By: Private Name (falves11) 2009-06-12 13:54:59
It actually crashes
[Jun 12 14:47:52] WARNING: channel.c:2582 __ast_read: read() failed: Bad file descriptor
[Jun 12 14:47:52] ERROR: astobj2.c:110 INTERNAL_OBJ: user_data is NULL
maybe there us another bug open?
By: Private Name (falves11) 2009-06-15 09:07:42
Version 1.4 does not have any handle leak. It shows a steady correlation of about 4 handles per open call, while any of the 1.6.X versions this relationship is a lot bigger, maybe 10. I am going back to 1.4, but we should look into this and fix it.
I can show the developers both cases, with the same calls, and you can see the huge difference.
By: Leif Madsen (lmadsen) 2009-06-15 12:23:32
This is a duplicate of an existing bug. Issue 13623 mentions a work around.