Asterisk 1.8.11 eating cache memory

Hi there!

I installed, for the first time, Asterisk last week. From what I’ve heard and read it would be a really great solution for our company, and in the first tests I’ve made it works excellent!

Until a few days ago.

Suddenly it did not connect any calls, I found the reason was that the cache memory was almost full (less than 256 Mb were free), restarting all programs did not solve the problem. The only way I found was to empty cache brutally by

However the cache continues to grow, during the night it increased from 102 to 381 Mb (the server only used for asterisk, and emacs/vi) asterisk up and running keeping contact with about 5 software phones but not connecting any calls at all.

root@The_asterisk_server:/proc/sys/vm# free -m
            total       used       free     shared    buffers     cached
Mem:         1000        527        473          0         42        381
-/+ buffers/cache:       103        897
Swap:        1019          2       1017
root@Sandbox:/proc/sys/vm#

What could be the reason? The server is not very new (1 GB ram) but cleaned out before the installation with a new installation of Ubuntu 12.04 server edition, not intended to use for anything else but this. Version of gcc is

gcc -v
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

Version of Asterisk is 1.8.11-cert4.

Is there a more stable version more suitable for us? Or is the problem somewhere else, have we missed something?

It would solve a lot of problems if we get this working.

The cache usage isn’t your problem. You OS manages this (not asterisk, or any other app), and usually does a fine job. Check the system logs to start with.

It is normal for cache and buffers to grow. That is just Linux trying to make the most effective use of otherwise free memory, to improve system performance. Linux will try and make the actual unused memory be only a small percentage of available memory. As long as swap used is small and free on the +/- line is adequate, you have no memory problems.

As already said, this is totally irrelevant to any failure to make calls.