Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an old Ubuntu 8.10 32-bit with MySQL 5.0.67.

There's 5.7GB of data in it and it grows by about 100MB every day.

About 3 days ago, the MySQL instance begin dying suddenly and quitely (no log entry) during the nightly mysqldump.

What could be causing it?

Upgrading MySQL is a long-term project for me, unless there happens to be a specific bug in 5.0.67 then I guess I'll just need to reprioritize.

I'm hoping somebody might be familiar with this problem since this is a fairly popular version bundled with Ubuntu 8.10.


share|improve this question

Is there a very large table that is being dumped or a bunch of medium sized ones? are you using the -q option with mysqldump? Is there a large table that you're dumping that is being written to? If so, locking a large table will prevent any other threads from executing due to the lock held which might cause your webserver/scripts to wait until the machine is starved for resources.

It is possible that you might be using up all available memory on either the mysql or mysqldump process causing the OOM (out of memory) killer in the kernel to end the process. For that, you might take a look at kern.log, syslog, messages for the string OOM or something similar to:

Mar 29 16:51:10 xxxxxx kernel: 160688 total pagecache pages
Mar 29 16:51:10 xxxxxx kernel: 2048 pages in swap cache
Mar 29 16:51:10 xxxxxx kernel: Swap cache stats: add 25966, delete 23918, find 150791/151181
Mar 29 16:51:10 xxxxxx kernel: Free swap  = 8228916kB
Mar 29 16:51:10 xxxxxx kernel: Total swap = 8297564kB
Mar 29 16:51:10 xxxxxx kernel: 2228208 pages RAM
Mar 29 16:51:10 xxxxxx kernel: 183093 pages reserved
Mar 29 16:51:10 xxxxxx kernel: 2208385 pages shared
Mar 29 16:51:10 xxxxxx kernel: 1864656 pages non-shared
Mar 29 16:51:10 xxxxxx kernel: mysqld: page allocation failure. order:1, mode:0x20
share|improve this answer

If there's no entry in the logs, I'd recommend you to try to strace the mysqldump.

strace -f -o strace.output mysqldump your_mysqldump_options

Then take a look at the last few lines of the file strace.output. This normally enlightens the way and it's a god way to star debugging these issues.

On the other hand, a trending application like Cacti, Ganglia or Munin is also useful in this kind of problems as you can watch the server behavior regarding important metrics like tcp connections, cpu, memory and swap, for instance.

Hope this helps.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.