[asterisk-bugs] [JIRA] (ASTERISK-24555) Memory usage increases constantly (frame.c memory cache)

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223860#comment-223860 ] 

Matt Jordan commented on ASTERISK-24555:
----------------------------------------

I can't recall. Are you using T.38 gateway?

> Memory usage increases constantly (frame.c memory cache)
> --------------------------------------------------------
>
>                 Key: ASTERISK-24555
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24555
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2, Core/General
>    Affects Versions: 11.14.0
>         Environment: Ubuntu 11.10 x64
> Kernel 3.0.0-32
> cat /proc/cpuinfo:
> $ cat /proc/cpuinfo 
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 15
> model name	: Intel(R) Xeon(R) CPU           X3220  @ 2.40GHz
> stepping	: 7
> cpu MHz		: 2400.074
> cache size	: 4096 KB
> physical id	: 0
> siblings	: 4
> core id		: 0
> cpu cores	: 4
> apicid		: 0
> initial apicid	: 0
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips	: 4800.14
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
> processor	: 1
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 15
> model name	: Intel(R) Xeon(R) CPU           X3220  @ 2.40GHz
> stepping	: 7
> cpu MHz		: 2400.074
> cache size	: 4096 KB
> physical id	: 0
> siblings	: 4
> core id		: 1
> cpu cores	: 4
> apicid		: 1
> initial apicid	: 1
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips	: 4800.18
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
> processor	: 2
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 15
> model name	: Intel(R) Xeon(R) CPU           X3220  @ 2.40GHz
> stepping	: 7
> cpu MHz		: 2400.074
> cache size	: 4096 KB
> physical id	: 0
> siblings	: 4
> core id		: 2
> cpu cores	: 4
> apicid		: 2
> initial apicid	: 2
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips	: 4800.18
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
> processor	: 3
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 15
> model name	: Intel(R) Xeon(R) CPU           X3220  @ 2.40GHz
> stepping	: 7
> cpu MHz		: 2400.074
> cache size	: 4096 KB
> physical id	: 0
> siblings	: 4
> core id		: 3
> cpu cores	: 4
> apicid		: 3
> initial apicid	: 3
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 10
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow
> bogomips	: 4800.18
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:
>            Reporter: James Lamanna
>
> The memory allocation of Asterisk 11 seems to constantly increase.
> Specifically, the cache allocated in frame.c seems to increase without bound. I haven't let it go this far, but it seems it would likely max out system memory and be killed by the OOM killer.
> $ asterisk -rx "memory show summary" | sort -rn
> 3950471103 bytes allocated (3923172359 in caches) in 5289609 allocations
> 3922949255 bytes (3922882279 cache) in    5184358 allocations in file frame.c
> ..
> $ asterisk -rx "core show channels"
> 8 active channels
> 4 active calls
> 14745 calls processed
> $ asterisk -rx "core show uptime"
> System uptime: 2 days, 14 hours, 17 minutes, 32 seconds 
> Last reload: 2 days, 14 hours, 17 minutes, 32 seconds 



--
This message was sent by Atlassian JIRA
(v6.2#6252)