When running a MySQL hot backup, I was finding that Linux would return an errno: 24 (Too many open files) while backing up. Searches on the internet told me to tweak /proc/sys/fs/file-max, but the setting there was HUGE (about 450,000) on my system.
It turned out that the shell itself had a limit of 1024 file descriptors, so the solution was to tweak the shell's open file descriptor limit thusly: "ulimit -n 8192" (where 8192 is a guess at the max number of files the shell and its subprocesses will ever want to open).
This doesn't only apply to MySQL, but rather to any Linux process that's getting an "errno: 24 Too many open files." Note to Linux hackers: there's more to it than just /proc/sys/fs/file-max!
To find out if your system is affected, log in to a shell and type "ulimit -a" which should list something like the following (note: open files is 1024):
:) ulimit -a
core file size (blocks, -c) 1000000
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 3071
virtual memory (kbytes, -v) unlimited
Oh, and to the anti-Linux zealots, the default limit on file descriptors on OpenBSD? looks like it's 64, and on Solaris 256, so you would have this same error except sooner. The Linux 1024 default seems somewhat reasonable. We didn't notice this until our data warehouse grew to a fairly sizeable chunk.
--
PhiloVivero
23 May 2003