Oracle 5.0 Reference Manual page 182

Linux Notes
If you have more than 16MB of memory, you should add something like the following to your init scripts
(for example, on SuSE Linux):
/etc/init.d/boot.local
echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max
You can also run the commands from the command line as root, but these settings are lost the
echo
next time your computer restarts.
Alternatively, you can set these parameters on startup by using the tool, which is used by
sysctl
many Linux distributions (including SuSE Linux 8.0 and later). Put the following values into a file named
/etc/sysctl.conf:
# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024
You should also add the following to /etc/my.cnf:
[mysqld_safe]
open-files-limit=8192
This should enable a server limit of 8,192 for the combined number of connections and open files.
The constant in LinuxThreads controls the spacing of thread stacks in the address
STACK_SIZE
space. It needs to be large enough so that there is plenty of room for each individual thread
stack, but small enough to keep the stack of some threads from running into the global
mysqld
data. Unfortunately, as we have experimentally discovered, the Linux implementation of
mmap()
successfully unmaps a mapped region if you ask it to map out an address currently in use, zeroing
out the data on the entire page instead of returning an error. So, the safety of or any other
mysqld
threaded application depends on the "gentlemanly" behavior of the code that creates threads. The
user must take measures to make sure that the number of running threads at any given time is
sufficiently low for thread stacks to stay away from the global heap. With mysqld, you should enforce
this behavior by setting a reasonable value for the [467] variable.
max_connections
If you build MySQL yourself, you can patch LinuxThreads for better stack use. See Section 2.20.1.3,
"Linux Source Distribution Notes". If you do not want to patch LinuxThreads, you should set
[467] to a value no higher than 500. It should be even less if you have a large
max_connections
key buffer, large heap tables, or some other things that make allocate a lot of memory, or if
mysqld
you are running a 2.2 kernel with a 2GB patch. If you are using our binary or RPM version, you can
safely set [467] at 1500, assuming no large key buffer or heap tables with lots
max_connections
of data. The more you reduce in LinuxThreads the more threads you can safely create.
STACK_SIZE
Values between 128KB and 256KB are recommended.
If you use a lot of concurrent connections, you may suffer from a "feature" in the 2.2 kernel that
attempts to prevent fork bomb attacks by penalizing a process for forking or cloning a child. This
causes MySQL not to scale well as you increase the number of concurrent clients. On single-CPU
systems, we have seen this manifest as very slow thread creation; it may take a long time to connect
to MySQL (as long as one minute), and it may take just as long to shut it down. On multiple-CPU
systems, we have observed a gradual drop in query speed as the number of clients increases. In
the process of trying to find a solution, we have received a kernel patch from one of our users who
claimed it helped for his site. This patch is available at http://dev.mysql.com/Downloads/Patches/linux-
fork.patch. We have done rather extensive testing of this patch on both development and production
systems. It has significantly improved MySQL performance without causing any problems and is
recommended for users who still run high-load servers on 2.2 kernels.
This issue has been fixed in the 2.4 kernel, so if you are not satisfied with the current performance
of your system, rather than patching your 2.2 kernel, it might be easier to upgrade to 2.4. On SMP
systems, upgrading also gives you a nice SMP boost in addition to fixing the fairness bug.
162