[quote]
*CLI> ==13035== Thread 48:
==13035== Use of uninitialised value of size 8
==13035== at 0x1EB98A27: pj_crc32_update (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB98AEA: pj_crc32_calc (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB8D641: pj_stun_msg_encode (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB8FEB0: send_response (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9003B: authenticate_req (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB90369: on_incoming_request (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9086D: pj_stun_session_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB89A6A: pj_ice_sess_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB7A2B9: __rtp_recvfrom.clone.3 (res_rtp_asterisk.c:1606)
==13035== by 0x1EB7F04E: ast_rtp_read (res_rtp_asterisk.c:1638)
==13035== by 0x223E855D: sip_read (chan_sip.c:8326)
==13035== by 0x4854F7: __ast_read (channel.c:4054)
==13035==
==13035== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==13035== at 0x511AB63: ??? (in /lib64/libc-2.12.so)
==13035== by 0x1EBA9202: pj_sock_sendto (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB7617C: ast_rtp_on_ice_tx_pkt (res_rtp_asterisk.c:1152)
==13035== by 0x1EB8807C: on_stun_send_msg (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB8FF26: send_response (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9003B: authenticate_req (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB90369: on_incoming_request (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9086D: pj_stun_session_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB89A6A: pj_ice_sess_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB7A2B9: __rtp_recvfrom.clone.3 (res_rtp_asterisk.c:1606)
==13035== by 0x1EB7F04E: ast_rtp_read (res_rtp_asterisk.c:1638)
==13035== by 0x223E855D: sip_read (chan_sip.c:8326)
==13035== Address 0x26e9f95f is 79 bytes inside a block of size 1,000 alloc’d
==13035== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==13035== by 0x1EBA8838: default_block_alloc (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EBAF04B: pj_pool_create_block (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EBAF1F7: pj_pool_allocate_find (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EBAEEE0: pj_pool_alloc (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB8FE7E: send_response (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9003B: authenticate_req (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB90369: on_incoming_request (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB9086D: pj_stun_session_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB89A6A: pj_ice_sess_on_rx_pkt (in /usr/lib64/asterisk/modules/res_rtp_asterisk.so)
==13035== by 0x1EB7A2B9: __rtp_recvfrom.clone.3 (res_rtp_asterisk.c:1606)
==13035== by 0x1EB7F04E: ast_rtp_read (res_rtp_asterisk.c:1638)
==13035==[/quote]
The size isn’t changing, so you don’t have a leak. RSS is an indicator of the memory access pattern, not the total memory used. It will probably go up due to increasing fragmentation.
OH thanks T.T … I was stupid…
It is test server… main server I didn’t patch …
main server down every 3 hours and the percentage of memory ( I use top ) increases.
so I want to know why memory increase …T.T…
then I will do the patch thanks~!
The memory used figure displayed by top should increase until it is close to the physical memory present. if it doesn’t, your systems is grossly over-provisioned with memory.
You haven’t provided the logging needed to tackle the second part of the question.
Sorry I can’t understand what you mean… It is cloud server and I didn’t change settings
please tell what I need to do? what log I need?
this is my server memory gragh… It hits top of memory capacity (8G) and goes down to 0.5G.
There is no problem with Asterisk to reboot automatically. However, it disconnected all concurrent calls at the same time…
You will need to take this up with the operators of the cloud server. It may well be their VM environment that is forcing the memory usage back down (e.g. google “memory balloon”).
Basically both Linux and Window NT have a policy of using all available memory. If you read a file or write to a file, the buffer used will remain in memory because you might want to read it again later, and you have no other use for that memory, so there is no harm in keeping it. The result is that memory usage will grow to a large proportion of the memory allocated. Only then will the OS start releasing memory, to ensure that it has a pool of free memory to satisfy urgent demands. (It may not even free memory if it has already been written to the disk. It may just speed up the write backs.)
Contraindications to a memory leak are:
the ps virtual memory size is constant - that’s pretty definitive;
no Asterisk memory leak I have ever seen grows at such a rate, and I would expect any that did to have been found and fixed early.
If you are running on a VM (not something I would recommend), you should set the memory size of the VM consistent with your actual memory needs. That figure is below 1GB in your case, and might not be much above 500MB.
I installed asterisk in my computer it has no problem … the problem is asterisk in EC2…
and I read that "VM must be configured with enough dedicated RAM for all Asterisk’s needs…"
what it means? and how I can do that??
If you over configure it, you are wasting resources that could be available to other machines. That will increase the need of the VM Host to take drastic measures like inflating memory bubbles to force cached contents out of your virtual RAM.
Other VMs will still be triggering this, but the variation in memory allocation, if you only request what you really need, will not be so extreme.
Ideally, you would request dedicated RAM sufficient to cover your needs. If that is available, it will be more expensive than RAM that can be traded between different VMs.
The need is at least 0.5MB, but that will probably have forced out material that does benefit from caching and forced a lot of re-page-ins of code program pages. My guess would be that you actually need between 500 and 750 MB.
The ideal is that you reserve that much RAM exclusively for your machine.
Note that the only real harm that a memory bubble inflation will cause is that time will then be wasted in reloading the pages that have been forced out. If you have any symptoms that are not consistent with that, we are still awaiting logging from Asterisk.
The ability for other VMs to take resources from you is why you shouldn’t run real time applications, like VoIP, on VMs when you don’t manage the complete physical machine. Such applications need to be run on dedicate hardware or lightly loaded VM Hosts.
So… you said vitual make this porblem…so I use IDC server but same problem was happened…
Now I use this
CPU : INTEL Haswell i3-4130 3.4GHz
RAM : DDR3 12800U 16G
SSD/HDD : SSD 128GB + SSD 128GB
I use Asterisk 11.10.2 realtime database(mysql) and linphone …
(I followed this open-voip.org/index.php?titl … me_example )
Someone said vpn can make this problem… I have no idea to fix it.
and I use memory show summary
20732561 bytes in 3126 allocations in file chan_sip.c
…
after sever calls
…
31935985 bytes in 4653 allocations in file chan_sip.c
Looking more closely, it looks like you are using an old version of ps that shows individual thread sizes. I thought you were showing the time progression of the process memory usage, which is what I would do if I suspected a memory leak The memory usage is also too high. However valgrind is saying that there are very few unbalanced heap allocations and they can be accounted for (I assume that valgrind was not in use when the memory measurements were made, as I guess it could use a lot of memory, itself.)
I still find it difficult to believe that such a heavy leak would not have been detected in initial testing. At the very least I suspect you are doing something unusual.
Things to look for are:
core show channels
or
show channels
increasing in numbers;
The size of the increments in VM size;
When in a call they happen.
What’s the increment per call.
Are you leaking any other resource (sockets, etc., even threads).
The issue that you quote hints that you should be using memory show summary as a diagnostic, although I don’t know if that requires special compile time options.
[ Initializing Custom Configuration Options ]
[Jun 17 09:13:37] NOTICE[9577]: cdr.c:1622 do_reload: CDR simple logging enabled.
[Jun 17 09:13:37] NOTICE[9577]: loader.c:1208 load_modules: 202 modules will be loaded.
[Jun 17 09:13:39] WARNING[9577]: loader.c:439 load_dynamic_module: Error loading module ‘chan_dahdi.so’: libpri.so.1.4: cannot open shared object file: No such file or directory
…[Jun 17 09:13:39] NOTICE[9577]: res_smdi.c:1418 load_module: No SMDI interfaces are available to listen on, not starting SMDI listener.
…[Jun 17 09:13:41] WARNING[9577]: loader.c:439 load_dynamic_module: Error loading module ‘chan_dahdi.so’: libpri.so.1.4: cannot open shared object file: No such file or directory
[Jun 17 09:13:41] WARNING[9577]: loader.c:918 load_resource: Module ‘chan_dahdi.so’ could not be loaded.
[Jun 17 09:13:42] NOTICE[9577]: config.c:2442 ast_config_engine_register: Registered Config Engine sqlite3
.[Jun 17 09:13:42] WARNING[9577]: res_config_mysql.c:1515 load_mysql_config: MySQL realtime: no requirements setting found, using ‘warn’ as default.
[Jun 17 09:13:42] NOTICE[9577]: config.c:2442 ast_config_engine_register: Registered Config Engine mysql
…[Jun 17 09:13:43] NOTICE[9577]: chan_skinny.c:7736 config_load: Configuring skinny from skinny.conf
.SIP channel loading…
[Jun 17 09:13:44] NOTICE[9577]: chan_sip.c:30927 build_peer: The ‘username’ field for sip peers has been deprecated in favor of the term ‘defaultuser’
[Jun 17 09:13:44] WARNING[9577]: chan_sip.c:30081 set_insecure_flags: Unknown insecure mode ‘very’ on line 46
[Jun 17 09:13:44] WARNING[9577]: sip/config_parser.c:812 sip_parse_nat_option: nat=yes is deprecated, use nat=force_rport,comedia instead
[Jun 17 09:13:44] WARNING[9577]: chan_sip.c:30081 set_insecure_flags: Unknown insecure mode ‘very’ on line 59
[Jun 17 09:13:44] WARNING[9577]: sip/config_parser.c:812 sip_parse_nat_option: nat=yes is deprecated, use nat=force_rport,comedia instead
[Jun 17 09:13:44] WARNING[9577]: res_config_mysql.c:501 realtime_multi_mysql: MySQL RealTime: Failed to query database: Unknown column ‘callbackextension’ in ‘where clause’
[Jun 17 09:13:44] WARNING[9577]: res_config_mysql.c:1127 require_mysql: Realtime table general@sip_buddies: Column ‘ipaddr’ should be at least 45 long, but is only 15 long.
…[Jun 17 09:13:44] NOTICE[9577]: cel_custom.c:95 load_config: No mappings found in cel_custom.conf. Not logging CEL to custom CSVs.
…[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:164 pbx_load_module: Starting AEL load process.
[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:177 pbx_load_module: AEL load process: parsed config file name ‘/etc/asterisk/extensions.ael’.
[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:180 pbx_load_module: AEL load process: checked config file name ‘/etc/asterisk/extensions.ael’.
[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:187 pbx_load_module: AEL load process: compiled config file name ‘/etc/asterisk/extensions.ael’.
[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:192 pbx_load_module: AEL load process: merged config file name ‘/etc/asterisk/extensions.ael’.
[Jun 17 09:13:45] NOTICE[9577]: pbx_ael.c:195 pbx_load_module: AEL load process: verified config file name ‘/etc/asterisk/extensions.ael’.
…[Jun 17 09:13:49] WARNING[9577]: res_config_mysql.c:1127 require_mysql: Realtime table general@voicemail_users: Column ‘password’ should be at least 10 long, but is only 5 long.
…[Jun 17 09:13:51] NOTICE[9577]: app_queue.c:10007 load_module: No entries were found for ringinuse/ignorebusy in queue_members table. Using ‘ringinuse’
.Asterisk Ready.
*CLI> core stop gracefully
Waiting for inactivity to perform halt…
==9577== Warning: invalid file descriptor -1 in syscall close()
Asterisk cleanly ending (0).
Executing last minute cleanups
==9577==
==9577== HEAP SUMMARY:
==9577== in use at exit: 455,632 bytes in 1,899 blocks
==9577== total heap usage: 832,244 allocs, 830,345 frees, 56,966,796 bytes allocated
==9577==
==9577== 304 bytes in 1 blocks are possibly lost in loss record 204 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x40118A2: _dl_allocate_tls (in /lib64/ld-2.12.so)
==9577== by 0x66981E8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so)
==9577== by 0x573CA3: ast_pthread_create_stack (utils.c:1222)
==9577== by 0x4A9DCD: ast_device_state_engine_init (devicestate.c:750)
==9577== by 0x443724: main (asterisk.c:4284)
==9577==
==9577== 304 bytes in 1 blocks are possibly lost in loss record 205 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x40118A2: _dl_allocate_tls (in /lib64/ld-2.12.so)
==9577== by 0x66981E8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so)
==9577== by 0x573CA3: ast_pthread_create_stack (utils.c:1222)
==9577== by 0x53372D: ast_presence_state_engine_init (presencestate.c:318)
==9577== by 0x443734: main (asterisk.c:4289)
==9577==
==9577== 320 bytes in 1 blocks are possibly lost in loss record 206 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x40118A2: _dl_allocate_tls (in /lib64/ld-2.12.so)
==9577== by 0x66981E8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so)
==9577== by 0x573CA3: ast_pthread_create_stack (utils.c:1222)
==9577== by 0x573E1C: ast_pthread_create_detached_stack (utils.c:1242)
==9577== by 0x1A356A59: load_module (pbx_spool.c:902)
==9577== by 0x4EE4A2: start_resource (loader.c:861)
==9577== by 0x4F0751: load_resource_list (loader.c:1063)
==9577== by 0x4F0D7D: load_modules (loader.c:1216)
==9577== by 0x4437CC: main (asterisk.c:4337)
==9577==
==9577== 320 bytes in 1 blocks are possibly lost in loss record 207 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x40118A2: _dl_allocate_tls (in /lib64/ld-2.12.so)
==9577== by 0x66981E8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so)
==9577== by 0x573CA3: ast_pthread_create_stack (utils.c:1222)
==9577== by 0xFA7BB4A: restart_monitor (chan_phone.c:1166)
==9577== by 0xFA7D59B: load_module (chan_phone.c:1493)
==9577== by 0x4EE4A2: start_resource (loader.c:861)
==9577== by 0x4F0751: load_resource_list (loader.c:1063)
==9577== by 0x4F0D7D: load_modules (loader.c:1216)
==9577== by 0x4437CC: main (asterisk.c:4337)
==9577==
==9577== 320 bytes in 1 blocks are possibly lost in loss record 208 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x40118A2: _dl_allocate_tls (in /lib64/ld-2.12.so)
==9577== by 0x66981E8: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.12.so)
==9577== by 0x573CA3: ast_pthread_create_stack (utils.c:1222)
==9577== by 0x573E1C: ast_pthread_create_detached_stack (utils.c:1242)
==9577== by 0x443983: main (asterisk.c:4388)
==9577==
==9577== 10,536 (112 direct, 10,424 indirect) bytes in 2 blocks are definitely lost in loss record 253 of 257
==9577== at 0x4C2677B: calloc (vg_replace_malloc.c:593)
==9577== by 0x4DC093: ast_format_cap_alloc (utils.h:513)
==9577== by 0x1A772ACC: build_peer (chan_ooh323.c:2460)
==9577== by 0x1A773EA8: reload_config (chan_ooh323.c:3080)
==9577== by 0x1A77525D: load_module (chan_ooh323.c:3786)
==9577== by 0x4EE4A2: start_resource (loader.c:861)
==9577== by 0x4F0751: load_resource_list (loader.c:1063)
==9577== by 0x4F0D7D: load_modules (loader.c:1216)
==9577== by 0x4437CC: main (asterisk.c:4337)
==9577==
==9577== LEAK SUMMARY:
==9577== definitely lost: 112 bytes in 2 blocks
==9577== indirectly lost: 10,424 bytes in 8 blocks
==9577== possibly lost: 1,568 bytes in 5 blocks
==9577== still reachable: 443,528 bytes in 1,884 blocks
==9577== suppressed: 0 bytes in 0 blocks
==9577== Reachable blocks (those to which a pointer was found) are not shown.
==9577== To see them, rerun with: --leak-check=full --show-reachable=yes
==9577==
==9577== For counts of detected and suppressed errors, rerun with: -v
==9577== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 594 from 9)[/code]
Replace by then name of the channel driver teechnology for each one that you use. I guess you use sip. Although you have libpri, I don’t think there is any way of using it on a cloud VM, so you are probably not using dahdi.
My guess is that the problem lies with the MP3 support. Note that, if your music files are static, there is no point in using MP3. It is much better to preconvert MP3 to slin and to any low bit rate codec that you use, offline.
