Out of memory (OOM killer) - what is causing my memory issue?
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Out of memory (OOM killer) - what is causing my memory issue?
Hi,
I would be happy to get some help on this as I cant find the issue.
I try to find the cause why my server gets out of memory every few weeks ans calls the OOM killer. It seems to be that memory usage is stable for about 2 weeks, then going up gradually for 2 weeks. Then there is a big hike resulting in an OOM call.
After a reboot, memory usage drops and system is running well for a few weeks.
Code:
COMMAND %MEM
tor 12.0
mysqld 7.8
/usr/sbin/spamd 6.2
spamd child 6.1
spamd child 6.1
apache2 4.4
apache2 2.9
apache2 2.9
apache2 2.5
apache2 2.0
Memory Space Details
Total Memory space : 1250 MB
Used Memory Space : 659 MB
Free Memory : 590 MB
Swap memory Details
Total Swap space : 255 MB
Used Swap Space : 0 MB
Free Swap : 255 MB
Where is the memory jump coming from? Is it just apache that needs a little more memory and I just run out? But if so, why is the memory usage gradually increasing over a period of 2 weeks?
The problem looks to be with Spam Assassin. I would first suggest to check if you are running perl with cpan. That is, just type in the command "cpan" and see if it responds, you can exit by just typing "exit". If that all checks out then verify he spamd modules are updated. Inside cpan type "install Mail::SpamAssassin::Conf" without the quotes. It will either say it is up to date or start the install. If the install fails then run "reports Mail::SpamAssassin::Conf" to hopefully gleam more information. If it fails or not, run a forced update on spamd. If the cpan install did fail, start asking for further support on that specific issue, but it is beyond what I would want to try to detail here.
Looks like you're trying to d oa fair amount of stuff with not much resource. While it looks like perhaps spamd has a memory leak or just requires more memory as time goes on, this could go away with just a little more resource (RAM).
What do the OOM messages in dmesg or /var/log/messages look like?
The problem is not (necessarily) with spamassassin. Please post the full output of the oom log message. The last line looks like
"kill process <No> (<name>) - score <oom score> - or sacrifice child"
The message you posted "spamd invoked oom killer" means the system was out of memory exactly when spamd tried to reserve a new chunk of memory. This does not mean that spamd is the process having the memory leak. You wrote "the process TOR was killed". From my experience, if exactly one process has a big memory leak, the oom killer is good in identifying and killing the correct process. So maybe tor has the memory leak, but as said, please post the full message.
The OOM message should tell us what order of memory is lacking, and by how much, and you can also run 'cat /proc/buddyinfo' during one of these events and the following details will help us, as well:
I think you have far too little swap space configured to allow reasonable diagnosis of the real problem.
If you had more swap space, instead of the OOM killer being called, performance would only degrade slowly as the problem expands and the problem would then be much more obvious BEFORE the OOM killer starts destroying evidence.
I agree that spamd caused the OOM killer call but I don't think its the root of the problem. I did run a script every 10 minutes to track the memory usage of the top ten processes. All top ten processes were more or less stable.
I also don't think that low resources are my problem. I normally swapped around 80MB in average and that was very stable and I had no peaks.
I also don't think that the process TOR is the cause as its memory usage is also stable as I can see in my top ten statistic. Its normal that OOM will kill TOR in this case. Its on the top and I prefer to loose this process than apache or mysql.
Here is the kernel output during the OOM call. Maybe someone can see something useful in it: http://pastebin.com/rBvbFcyt
I don't want to increase my swap space for trouble shooting. To get some more info, I run a script now every minute and append memory statistics for all running processes to a file (not only top 10).
I hope that will give more hints when it happens next time.
gombi: when you have another incident, it will be good to see /proc/buddyinfo. Sometimes OOM events have nothing to do with RAM, but with some of the zoned memory, instead.
gombi: when you have another incident, it will be good to see /proc/buddyinfo. Sometimes OOM events have nothing to do with RAM, but with some of the zoned memory, instead.
Just to add some of my thoughts to the conversation, I somewhat agree with the other posts about proper diagnostics, but at the same time the perl modules needing to be manually updated is a known issue. As such I tend to try to rule out possible known issues to resolve conflicts to see if that fixes the issue before committing time to do further investigation. Habit from work environments that are strict on productivity levels.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.