[asterisk-bugs] [JIRA] (ASTERISK-24837) chan_sip calls to Asterisk result in file descriptors growing exponentially while channels remain up
Private Name (JIRA)
noreply at issues.asterisk.org
Fri Mar 20 00:57:34 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225510#comment-225510 ]
Private Name commented on ASTERISK-24837:
-----------------------------------------
It does not load, can you by any chance figure out why? I am attaching the commands free -g and ulimit -a. The box has plenty of resources.
valgrind --track-fds=yes --show-leak-kinds=all --log-file=valgrind.txt asterisk -cvvvvvvvvvvvvv
Privilege escalation protection disabled!
See https://wiki.asterisk.org/wiki/x/1gKfAQ for more details.
Asterisk SVN-branch-11-r433173M, Copyright (C) 1999 - 2013 Digium, Inc. and others.
Created by Mark Spencer <markster at digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
[ Initializing Custom Configuration Options ]
[Mar 19 17:55:54] NOTICE[21527]: loader.c:1244 load_modules: 7 modules will be loaded.
[Mar 19 17:55:54] NOTICE[21527]: res_odbc.c:1532 odbc_obj_connect: Connecting mysql
.[Mar 19 17:55:55] NOTICE[21527]: res_odbc.c:1564 odbc_obj_connect: res_odbc: Connected to mysql [asterisk]
[Mar 19 17:55:55] NOTICE[21527]: res_odbc.c:919 load_odbc_config: Registered ODBC class 'mysql' dsn->[asterisk]
[Mar 19 17:55:55] NOTICE[21527]: res_odbc.c:1894 load_module: res_odbc loaded.
...[Mar 19 17:55:55] NOTICE[21527]: config.c:2546 ast_config_engine_register: Registered Config Engine odbc
...[Mar 19 17:55:56] NOTICE[21527]: cdr.c:1622 do_reload: CDR simple logging enabled.
[Mar 19 17:55:57] WARNING[21527]: ccss.c:4278 initialize_cc_max_requests: Could not find valid ccss.conf file. Using cc_max_requests default
[Mar 19 17:55:57] WARNING[21527]: ccss.c:4335 initialize_cc_devstate_map: Could not find valid ccss.conf file. Using cc_[state]_devstate defaults
[Mar 19 17:55:57] NOTICE[21527]: loader.c:1244 load_modules: 83 modules will be loaded.
.....SIP channel loading...
..............................Killed
[root at fedora-1 asterisk]# free -g
total used free shared buffers cached
Mem: 98 4 93 0 0 2
-/+ buffers/cache: 2 96
Swap: 1 0 1
[root at fedora-1 asterisk]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 1048576
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
> chan_sip calls to Asterisk result in file descriptors growing exponentially while channels remain up
> ----------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-24837
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24837
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_rtp_asterisk
> Affects Versions: 13.2.0
> Environment: Linux 64
> Reporter: Private Name
> Assignee: Private Name
> Attachments: core_show_fd_120_channels.txt, sip.conf, trace.txt, trace.txt, trace.txt
>
>
> [Edit by Rusty - Please use the wiki formatting available to make reports easy to read - I'm going to clean this up for now.]
> When I originate several hundred calls using a call file, no dialplan, using app Echo() or app MusicOnHold, the calls connect, but when the other side starts to send media, after some 200+ calls I get several errors:
> {noformat}
> "ERROR[2433] res_rtp_asterisk.c: RTCP SR transmission error to 208.78.162.174:34443, rtcp halted Operation not permitted"
> {noformat}
> and the handle count explodes, measured at the end
> {noformat}
> lsof | grep asterisk | grep FIFO | wc -l
> 1025046
> {noformat}
> yes one million and change. The handle count never decreases as long as the channels are open. There are no active calls, only 500 channels.
> The call files are all identical:
> {noformat}
> Channel: SIP/0000000000 at demo
> CallerID: "0000000000" <>
> WaitTime: 45
> MaxRetries: 0
> RetryTime: 0
> Application: Echo
> Data:
> Archive: no
> {noformat}
> where demo is a simple peer like this
> {noformat}
> [demo]
> host=xxx.xxx.xxx.xx
> type=peer
> insecure=port,invite
> context=reject
> disallow=all
> allow=ulaw
> allow=g729
> session-timers=accept
> port=5060
> faxdetect=no
> transport=udp
> directmedia=yes
> {noformat}
> *Note 1:* the caller ID may vary call by call it makes no difference. The issue here is the very high handle count, which slows down and kills the machine, and the errors which show that many calls do not connect.
> *Note 2:* The calls do no across the internet, they go to a local box.
> I need to send as many calls in real life, with media, so this is a killer for my business model.
> If I set up debug=10 and verbose=20, I get thousands of lines identical like this ones
> {noformat}
> Feb 26 23:47:13] DEBUG[2433]: acl.c:963 ast_find_ourip: Attached to given IP address
> [Feb 26 23:47:13] DEBUG[5763]: res_rtp_asterisk.c:3958 ast_rtcp_read: Got RTCP report of 64 bytes
> [Feb 26 23:47:13] DEBUG[5763]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.
> [Feb 26 23:47:13] DEBUG[5763]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting 'dasaro' into...
> [Feb 26 23:47:13] DEBUG[5763]: netsock2.c:226 ast_sockaddr_split_hostport: ...host 'dasaro' and port ''.
> [Feb 26 23:47:13] DEBUG[5763]: acl.c:958 ast_find_ourip: Not an IPv4 nor IPv6 address, cannot get port.
> [Feb 26 23:47:13] DEBUG[5763]: acl.c:963 ast_find_ourip: Attached to given IP address
> {noformat}
> {noformat}
> ulimit -a
> core file size (blocks, -c) unlimited
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) unlimited
> pending signals (-i) 1048576
> max locked memory (kbytes, -l) unlimited
> max memory size (kbytes, -m) unlimited
> open files (-n) 1048576
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) unlimited
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
> {noformat}
> *Note 3:* Please note how the handles start to grow with each additional call
> {noformat}
> Count idle
> 46
> 1 call
> lsof | grep asterisk | grep FIFO | wc -l
> 104
> 2 calls
> lsof | grep asterisk | grep FIFO | wc -l
> 168
> 3 calls
> lsof | grep asterisk | grep FIFO | wc -l
> 240
> 4 calls
> lsof | grep asterisk | grep FIFO | wc -l
> 320
> {noformat}
> As you can see, the handles do not grow linearly, but close to exponentially.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list