[asterisk-bugs] [Asterisk 0015356]: After a few thousand calls, or at random, Asterisk stops receiving events from the network
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Jul 31 17:02:36 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=15356
======================================================================
Reported By: falves11
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 15356
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: acknowledged
Target Version: 1.6.2.x Pending Blocker
Asterisk Version: SVN
Regression: Yes
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.2
SVN Revision (number only!): 201533
Request Review:
======================================================================
Date Submitted: 2009-06-18 17:59 CDT
Last Modified: 2009-07-31 17:02 CDT
======================================================================
Summary: After a few thousand calls, or at random, Asterisk
stops receiving events from the network
Description:
The application is up, you may do "core restart now", "core show channels",
etc., but no new calls entert and I think no packests are delivered. Other
times it is dead and only a "killall asterisk" will restart it.
======================================================================
----------------------------------------------------------------------
(0108480) falves11 (reporter) - 2009-07-31 17:02
https://issues.asterisk.org/view.php?id=15356#c108480
----------------------------------------------------------------------
The Parallels engineers have found a bug that takes down asterisk because
the server runs out of sockets, and also it degrades the perfornce because
it takes more and more time for the processor to find an empty socket. The
load on the processor grows over time,
This is what they saw:
"As i can see, the number of UDP sockets are more or less permanently
grows:
[root at host-208 ~]# cat /proc/net/sockstat
sockets: used 90645
TCP: inuse 1242 orphan 0 tw 117 alloc 1322 mem 150
UDP: inuse 88881 mem 6744
RAW: inuse 0
FRAG: inuse 0 memory 0
Processors again spend more and more time to get need socket out from
86366 "inuse".However the traffic not growing and much less now:
[root at host-208 ~]# vzstat -l
5:23pm, up 3:17, 5 users, load average: 24.79, 25.45, 18.39
CTNum 23, procs 1762: R 22, S 1731, D 0, Z 0, T 0, X 9
CPU [ OK ]: CTs 100%, CT0 0%, user 33%, sys 8%, idle 60%, lat(ms)
85/0
Mem [ OK ]: total 128737MB, free 124755MB/0MB (low/high), lat(ms) 7/2
ZONE0 (DMA): size 9MB, act 0MB, inact 0MB, free 10MB (0/0/0)
ZONE1 (DMA32): size 2986MB, act 0MB, inact 0MB, free 2789MB (1/1/1)
ZONE2 (Normal): size 126000MB, act 2756MB, inact 528MB, free 121955MB
(43/54/65)
Mem lat (ms): A0 0, K0 5, U0 0, K1 7, U1 0
Slab pages: 437MB/437MB (ino 117MB, de 43MB, bh 5MB, pb 35MB)
Swap [ OK ]: tot 2055MB, free 2055MB, in 0.000MB/s, out 0.000MB/s
Net [ OK ]: tot: in 3.275MB/s 15778pkt/s, out 1.876MB/s 8706pkt/s
lo: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
eth0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
eth1: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
eth2: in 3.275MB/s 15778pkt/s, out 1.876MB/s 8706pkt/s
eth3: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
sit0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
veth9102.0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
veth9106.0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
veth9100.0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
veth9111.0: in 0.000MB/s 0pkt/s, out 0.000MB/s 0pkt/s
Disks [ OK ]: in 0.000MB/s, out 0.480MB/s
[root at host-208 ~]# vztop -n2 -d3
vztop - 17:26:11 up 3:19, 5 users, load average: 20.27, 23.55, 18.61
Tasks: 902 total, 1 running, 901 sleeping, 0 stopped, 0 zombie
Cpu(s): 13.4% us, 3.3% sy, 0.0% ni, 27.6% id, 0.0% wa, 0.0% hi, 55.7%
si
Mem: 131826772k total, 4050364k used, 127776408k free, 111156k
buffers
Swap: 2104472k total, 0k used, 2104472k free, 1559484k cached
CTID PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9112 39281 root 18 0 584m 232m 11m S 184 0.2 104:47.71
asterisk
9100 39326 root 18 0 581m 209m 11m S 181 0.2 94:24.69
asterisk
9102 39709 root 18 0 577m 207m 11m S 171 0.2 89:55.23
asterisk
9113 39355 root 18 0 578m 212m 11m S 166 0.2 95:13.56
asterisk
9101 16934 root 18 0 595m 212m 11m S 156 0.2 86:46.97
asterisk
9105 39340 root 18 0 407m 70m 11m S 73 0.1 30:09.99
asterisk
9103 39486 root 18 0 402m 66m 11m S 56 0.1 27:52.46
asterisk
9110 39535 root 18 0 401m 65m 11m S 44 0.1 28:23.30
asterisk
9104 39686 root 18 0 396m 65m 11m S 40 0.1 26:59.71
asterisk
9106 39485 root 18 0 396m 63m 11m S 38 0.0 27:29.80
asterisk
9108 39366 root 18 0 405m 70m 11m S 31 0.1 27:43.83
asterisk
0 39220 root 15 0 11188 1700 824 R 1 0.0 0:00.08 vztop
0 51361 root 16 0 11188 1712 816 S 1 0.0 1:15.12 vztop
9114 39062 root 15 0 70824 28m 28m S 1 0.0 0:27.20
opensips
9107 39259 root 18 0 277m 17m 10m S 1 0.0 0:08.53
asterisk
9114 39060 root 15 0 70824 28m 28m S 0 0.0 0:27.18
opensips
0 1 root 15 0 10344 676 568 S 0 0.0 0:02.85 init
0 2 root RT -5 0 0 0 S 0 0.0 0:00.02
migration/0/0
i guess probably asterisk might leave some sockets open instead of closing
them after end of calls/meetings/etc.
Issue History
Date Modified Username Field Change
======================================================================
2009-07-31 17:02 falves11 Note Added: 0108480
======================================================================
More information about the asterisk-bugs
mailing list