1

Recently I've been having some serious memory issues with my server. Just the other day, my server became completely unresponsive, and oom-killer started killing services at random (httpd, php, etc). I couldn't even SSH into my server, but I was able to PING it.

I did look at the kernel messages log, but there wasn't any clear indication as to what was causing the memory problem - all I could see was all the oom-killer messages.

sar -r command:

03/15/2012 12:00:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 12:10:01 AM 2881812 582380 16.81 26652 250192 4192944 0 0.00 0 12:20:01 AM 2883600 580592 16.76 27104 250196 4192944 0 0.00 0 12:30:01 AM 2878576 585616 16.90 27656 250320 4192944 0 0.00 0 12:40:01 AM 2851856 612336 17.68 28312 271540 4192944 0 0.00 0 12:50:01 AM 2843560 620632 17.92 28968 274468 4192944 0 0.00 0 01:00:01 AM 2843892 620300 17.91 29440 274644 4192944 0 0.00 0 01:10:01 AM 22868 3441324 99.34 60764 2947884 4192936 8 0.00 8 01:20:01 AM 13836 3450356 99.60 62064 2882544 4192844 100 0.00 92 01:30:03 AM 14024 3450168 99.60 7820 3040976 4192844 100 0.00 0 01:40:01 AM 18600 3445592 99.46 18720 3039152 4192844 100 0.00 0 01:50:01 AM 25352 3438840 99.27 20048 3034584 4192844 100 0.00 0 02:00:01 AM 22572 3441620 99.35 20872 3036896 4192844 100 0.00 0 02:10:01 AM 21408 3442784 99.38 21776 3038236 4192844 100 0.00 0 02:20:01 AM 23240 3440952 99.33 23168 3032372 4192844 100 0.00 0 02:30:01 AM 72392 3391800 97.91 25100 2981488 4192844 100 0.00 0 02:40:01 AM 70876 3393316 97.95 25824 2981756 4192844 100 0.00 0 02:50:01 AM 74200 3389992 97.86 26464 2981860 4192844 100 0.00 0 03:00:01 AM 64980 3399212 98.12 32616 2982240 4192844 100 0.00 0 03:10:01 AM 63704 3400488 98.16 33564 2984268 4192844 100 0.00 0 03:20:01 AM 59564 3404628 98.28 34592 2988936 4192844 100 0.00 0 03:30:01 AM 53972 3410220 98.44 35740 2992484 4192844 100 0.00 0 03:40:01 AM 89120 3375072 97.43 36472 2956088 4192844 100 0.00 0 03:50:01 AM 88788 3375404 97.44 36920 2956324 4192844 100 0.00 0 04:00:01 AM 78540 3385652 97.73 37740 2964452 4192844 100 0.00 0 04:10:01 AM 21720 3442472 99.37 106636 2892836 4192844 100 0.00 0 04:20:01 AM 22796 3441396 99.34 107172 2890796 4192844 100 0.00 0 04:30:01 AM 30604 3433588 99.12 107812 2884644 4192844 100 0.00 0 04:40:01 AM 32744 3431448 99.05 108568 2875944 4192844 100 0.00 0 

Here is top sorted by swapped size:

top - 14:32:01 up 15:37, 1 user, load average: 0.10, 0.10, 0.04 Tasks: 110 total, 3 running, 107 sleeping, 0 stopped, 0 zombie Cpu(s): 0.5%us, 0.3%sy, 0.0%ni, 98.4%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3464192k total, 2663384k used, 800808k free, 140796k buffers Swap: 4192944k total, 100k used, 4192844k free, 2073748k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 1975 mysql 15 0 222m 43m 4652 S 0.0 1.3 0:11.82 178m mysqld 1859 named 22 0 161m 5228 1948 S 0.0 0.2 0:00.04 156m named 2144 root 18 0 143m 47m 1072 S 0.0 1.4 0:00.00 95m spamd 2119 root 15 0 143m 49m 2628 S 0.0 1.5 0:01.17 94m spamd 2161 root 15 0 93372 1280 936 S 0.0 0.0 0:00.01 89m pure-ftpd 2163 root 18 0 91016 976 804 S 0.0 0.0 0:00.01 87m pure-authd 20035 root 15 0 91800 3096 2408 S 0.0 0.1 0:00.00 86m sshd 19432 root 15 0 92232 3656 2900 R 0.0 0.1 0:00.00 86m sshd 2377 root 19 0 93268 14m 1940 S 0.0 0.4 0:00.00 76m cpdavd 2380 root 15 0 87824 11m 1520 S 0.0 0.3 0:00.07 74m cpsrvd-ssl 3115 root 15 0 74832 1168 584 S 0.0 0.0 0:00.05 71m crond 18548 root 18 0 73624 3036 236 S 0.0 0.1 0:00.00 68m httpd 19713 nobody 18 0 73760 4460 1584 S 0.0 0.1 0:00.00 67m httpd 19712 nobody 15 0 73760 4484 1584 S 0.0 0.1 0:00.00 67m httpd 19709 nobody 18 0 73624 4460 1584 S 0.0 0.1 0:00.00 67m httpd 19508 nobody 15 0 73760 4600 1680 S 0.0 0.1 0:00.00 67m httpd 19162 nobody 15 0 73756 4640 1708 S 0.0 0.1 0:00.01 67m httpd 19154 nobody 15 0 73756 4656 1728 S 0.0 0.1 0:00.00 67m httpd 19157 nobody 15 0 73756 4696 1740 S 0.0 0.1 0:00.01 67m httpd 19327 nobody 15 0 73756 4700 1740 S 0.0 0.1 0:00.01 67m httpd 19163 nobody 15 0 73756 4768 1836 S 0.0 0.1 0:00.00 67m httpd 19164 nobody 15 0 73756 4788 1856 S 0.0 0.1 0:00.00 67m httpd 2145 root 18 0 73624 5740 2940 S 0.0 0.2 0:00.60 66m httpd 1911 root 20 0 65952 1276 1044 S 0.0 0.0 0:00.01 63m mysqld_safe 

For some reason, it says that it's only using 100k SWAP, but that doesn't make any sense. Isn't VIRT the amount of SWAP being used by each process?

* Update *

Here is some more information on the file systems:

# df -T Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/md2 ext3 468924192 17215692 427504176 4% / /dev/md1 ext3 2030672 58788 1867068 4% /tmp /dev/md0 ext3 101018 13414 82388 15% /boot tmpfs tmpfs 1732096 0 1732096 0% /dev/shm 

* Update 2 *

Here is the free -m that I managed to run when the server was in this OOM state, yesterday:

 total used free shared buffers cached Mem: 3383 3372 10 0 0 6 -/+ buffers/cache: 3365 17 Swap: 4094 4094 0 
2
  • Are you receiving any related messages in dmesg? Commented Mar 15, 2012 at 18:43
  • Not that I know of - is there anything that you'd like me to check for in the dmesg buffer? Commented Mar 15, 2012 at 18:54

1 Answer 1

1

I usually sort by memory ("M" in top) to troubleshoot these kinds of things--that shows you the amount of real memory that each process is using (and touching frequently enough to keep it off the least-recently-used queue for being swapped).

VIRT = RES + SWAP

Another thing to check is whether /tmp is a tmpfs file system and if something is writing a lot of data there.

I am actually a little confused by what I'm seeing. Is this sar output over the interval when your outage occurred or just the default output? And the top output is from a totally different time, 14:32?

Also, it's not really using swap at the time you took these stats because it doesn't need to--nearly 3G of your memory is currently being used as disk cache ("kbcached") and you only have kbmemused - kbcached + kbbuffers = 664072KiB (648MiB) [at 04:40:01] in use by actual processes.

Because no process image is using much memory itself but yet the oom-killer started, then I would guess that something started performing a lot of file I/O and started dirtying pages faster than could be written to disk. I'm not really sure that should trigger the oom-killer though.

None of these dirty pages would go to swap, because it's about as easy to write the content of the file itself out as it is to write the data to swap.

The obvious guess is that mysqld was doing this, although I would suspect that it would open its files with O_DIRECT, which suggests to the kernel to minimize effects on the cache (with the premise that the DB server is doing its own caching).

Update

Based on your free output from update #2, the answer to the question in your topic is that it's using swap just fine; something just used all of it. The other data you provided is normal for a system that has recently boot.

Update 2

I mentioned mysql below, but I would be surprised is that's the culprit, honestly. I would suspect spamd, the CPanel processes or web applications running within Apache first.

I have also been assuming that you're running a reasonably current distro without any tweaking of system tunables and that you're current on security patches. There was a BIND exploit in the last few months that resulted in a DoS but I cannot recall if the exploit triggered memory exhaustion or something else. I have also read of CPanel exploits recently, but I don't know how current those were.

11
  • Just updated the question with the file system types - /tmp is ext3 Commented Mar 15, 2012 at 19:03
  • Hmm, isn't /dev/shm used for shared memory? Kinda confused as to why that is allocated 1732096 and /tmp is allocated 2030672. Is it considering the combination of those 2 as the SWAP? Commented Mar 15, 2012 at 19:17
  • The amount of memory a tmpfs file system uses is controllable at mount time. It usually defaults to 1/2 physical RAM, which seems about right for /dev/shm. /tmp doesn't count for anything since it's ext3. tmpfs doesn't count for the system-wide swap usage unless pages are actually used for the contents. Commented Mar 15, 2012 at 19:27
  • The sar and top I just did at the time of writing this question. Unfortunately, I didn't have any data from when the outages occurred. So you think the culprit might be mysql? Do you think it could be related to a PHP script that is running a large SQL query constantly? And can you recommend any way to try and track down exactly what is going on? Commented Mar 15, 2012 at 19:39
  • I also setup a memory logger to spit out details every 10 minutes into a file; so if it does occur again, I'm hoping that this will have some valid information. Commented Mar 15, 2012 at 19:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.