1

Possible Duplicate:
Avoid linux out-of-memory application teardown

let me first say that I'm pretty new ti *nix systems and even more to server management. Anyway, I've got a little problem. I got VPS with 1gb mem, system is debian 6. I have few sites running on it, though some load can only be caused by one of them. Recently, OOMK started to kill mysql, causing wp and phpbb giving error that it can't connect to mysql server. Error itself is not good, especially if it happens at night and site becomes unavailable until I wake up and restart mysql. I have probably bad line in my cron which can be cause of it all (again, I'm new to it)

    */20 * * * *    sync; echo 3 > /proc/sys/vm/drop_caches        

Well, if you need any information, let me know, since I don't really know which information can be useful here. Also, I'd like to know if it's not too bad to have above cron task.

2 Answers2

2

There's no point in running echo 3 > /proc/sys/vm/drop_caches. As Linux runs out of memory it will automatically remove the buffers and caches, so you're actually harming system performance by forcing removal of useful i/o caching.

You really need to look at what could be consuming all the memory. Look at the following possible culprits:

  1. Apache - Max clients or number of servers too high. I presume you're running in pre-fork mode.
  2. PHP - Max memory, max upload, number of database connections
  3. Nightly cron jobs, like slocate
  4. Mysql memory usage.

UPD MySQL may be being killed by OOMKiller but not actually the cause. It could be just the largest single memory consumer.

  • -D APACHE_MPM_DIR="server/mpm/prefork" from apache2 -V so I assume it's pre-fork, so part of config ` StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
  • ` 2. memory_limit = 256M , so not too much [?] , 3 - /usr/local/ispmgr/sbin/cron.sh sbin/eximquota.check.sh, /usr/local/ispmgr/sbin/cron.sh sbin/ihttpd.check.sh, /usr/local/ispmgr/sbin/cron.sh sbin/mgrctl -m ispmgr task.daily

    – Igor Yavych Nov 01 '12 at 16:49
  • , /usr/local/ispmgr/sbin/cron.sh sbin/update.sh ispmgr, /usr/local/ispmgr/sbin/dbcache, /usr/local/ispmgr/sbin/rotate,/usr/local/ispmgr/sbin/traffic.pl, mysqlcheck -u root -p"pwhere" --optimize --all-databases >/dev/null 2>&1, sync; echo 3 > /proc/sys/vm/drop_caches 4. For that I'd like your help to find memory usage parameters – Igor Yavych Nov 01 '12 at 16:53
  • AFAIK, if you have memory_limit = 256M and you have MaxClient = 150 then you potentially have 256MB * 150 = 38400MB! This may be the source of your problem. Reduce max_memory to the absolute minimum required and lower MaxClients to match. – Alastair McCormack Nov 01 '12 at 17:06
  • uh, i doubt that would be default configuration if that was the case – Igor Yavych Nov 01 '12 at 18:10
  • The default memory_limit ranges from 8MB to 128MB depending on PHP version so I think my theory is correct that 256MB is too high for your 1GB VM. Of course each process shouldn't consume 256MB but you may have some bad code or a memory leak. Why don't you run ps aux and see how much memory each Apache process is running and prove me wrong? – Alastair McCormack Nov 01 '12 at 19:10
  • See http://groups.drupal.org/node/233663 which backs my suspicion – Alastair McCormack Nov 01 '12 at 19:13