(mysql.info)Linux

The notes below regarding *glibc* apply only to the situation when you
build MySQL yourself. If you are running Linux on an x86 machine, in
most cases it is much better for you to just use our binary. We link
our binaries against the best patched version of *glibc* we can come up
with and with the best compiler options, in an attempt to make it
suitable for a high-load server. So if you read the text below, and are
in doubt about what you should do, try our binary first to see if it
meets your needs, and worry about your own build only after you have
discovered that our binary is not good enough. In that case, we would
appreciate a note about it, so we can build a better binary next time.
For a typical user, even for setups with a lot of concurrent
connections and/or tables exceeding 2GB limit, our binary in most cases
is the best choice.

MySQL uses LinuxThreads on Linux.  If you are using an old Linux
version that doesn't have `glibc2', you must install LinuxThreads
before trying to compile MySQL.   You can get LinuxThreads at
`http://www.mysql.com/Downloads/Linux'.

*NOTE:* We have seen some strange problems with Linux 2.2.14 and MySQL
on SMP systems; If you have a SMP system, we recommend you to upgrade
to Linux 2.4 ASAP!  Your system will be faster and more stable by doing
this!

Note that `glibc' versions before and including Version 2.1.1 have a
fatal bug in `pthread_mutex_timedwait' handling, which is used when you
do `INSERT DELAYED'.  We recommend you to not use `INSERT DELAYED'
before upgrading glibc.

If you plan to have 1000+ concurrent connections, you will need to make
some changes to LinuxThreads, recompile it, and relink MySQL against
the new `libpthread.a'.  Increase `PTHREAD_THREADS_MAX' in
`sysdeps/unix/sysv/linux/bits/local_lim.h' to 4096 and decrease
`STACK_SIZE' in `linuxthreads/internals.h' to 256 KB. The paths are
relative to the root of `glibc' Note that MySQL will not be stable with
around 600-1000 connections if `STACK_SIZE' is the default of 2 MB.

If you have a problem with that MySQL can't open enough files, or
connections, it may be that you haven't configured Linux to handle
enough files.

In Linux 2.2 and forwards, you can check the number of allocated file
handlers by doing:

     cat /proc/sys/fs/file-max
     cat /proc/sys/fs/dquot-max
     cat /proc/sys/fs/super-max

If you have more than 16M of memory, you should add something like the
following in your boot script (`/etc/rc/boot.local' on SuSE):

     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 above from the command line as root, but in this
case your old limits will be used next time your computer reboots.

You should also add /etc/my.cnf:

     [safe_mysqld]
     open-files-limit=8192

The above should allow MySQL to create up to 8192 connections + files.

The `STACK_SIZE' constant in LinuxThreads controls the spacing of thread
stacks in the address space.  It needs to be large enough so that there
will be plenty of room for the stack of each individual thread, but
small enough to keep the stack of some thread from running into the
global `mysqld' data.  Unfortunately, the Linux implementation of
`mmap()', as we have experimentally discovered, will successfully unmap
an already mapped region if you ask it to map out an address already in
use, zeroing out the data on the entire page, instead of returning an
error.  So, the safety of `mysqld' or any other threaded application
depends on the "gentleman" behavior of the code that creates threads.
The user must take measures to make sure the number of running threads
at any time is sufficiently low for thread stacks to stay away from the
global heap.  With `mysqld', you should enforce this "gentleman"
behavior by setting a reasonable value for the `max_connections'
variable.

If you build MySQL yourself and do not want to mess with patching
LinuxThreads, you should set `max_connections' to a value no higher
than 500.  It should be even less if you have a large key buffer,  large
heap tables, or some other things that make `mysqld' allocate a lot of
memory or if you are running a 2.2 kernel with a 2GB patch. If you are
using our binary or RPM version 3.23.25 or later, you can safely set
`max_connections' at 1500, assuming no large key buffer or heap tables
with lots of data.  The more you reduce `STACK_SIZE' in LinuxThreads
the more threads you can safely create.  We recommend the values between
128K and 256K.

If you use a lot of concurrent connections, you may suffer from a
"feature" in the 2.2 kernel that penalizes a process for forking or
cloning a child in an attempt to prevent a fork bomb attack.  This will
cause MySQL not to scale well as you increase the number of concurrent
clients.  On single CPU systems, we have seen this manifested in a very
slow thread creation, which means it may take a long time to connect to
MySQL (as long as 1 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 made a lot of difference for his site.  The
patch is available here
(`http://www.mysql.com/Downloads/Patches/linux-fork.patch'). We have
now done rather extensive testing of this patch on both development and
production systems.  It has significantly improved `MySQL' performance
without causing any problems and we now recommend it to our users who
are still running 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 just upgrade to 2.4, which will also give
you a nice SMP boost in addition to fixing this fairness bug.

We have tested MySQL on the 2.4 kernel on a 2 CPU machine and found
MySQL scales MUCH better - there was virtually no slowdown on query
throughput all the way up to 1000 clients, and MySQL scaling factor (
computed as the ratio of maximum throughput to the throughput with one
client) was 180%.  We have observed similar results on a 4-CPU system -
virtually no slowdown as the number of clients was increased up to
1000, and 300% scaling factor. So for a high-load SMP server we would
definitely recommend the 2.4 kernel at this point. We have discovered
that it is essential to run `mysqld' process with the highest possible
priority on the 2.4 kernel to achieve maximum performance.  This can be
done by adding `renice -20 $$' command to `safe_mysqld'. In our testing
on a 4-CPU machine, increasing the priority gave 60% increase in
throughput with 400 clients.

We are currently also trying to collect more info on how well `MySQL'
performs on 2.4 kernel on 4-way and 8-way systems. If you have access
such a system and have done some benchmarks, please send a mail to
<docs@mysql.com> with the results - we will include them in the manual.

There is another issue that greatly hurts MySQL performance, especially
on SMP systems.  The implementation of mutex in LinuxThreads in

With *glibc-2.2.2* MySQL version 3.23.36 will use the adaptive mutex,
which is much better than even the patched one in *glibc-2.1.3*. Be
warned, however, that under some conditions, the current mutex code in

We recommend that you use the above patches to build a special static
version of `libpthread.a' and use it only for statically linking
against `MySQL'. We know that the patches are safe for `MySQL' and
significantly improve its performance, but we cannot say anything about
other applications. If you link other applications against the patched
version of the library, or build a patched shared version and install
it on your system, you are doing it at your own risk with regard to
other applications that depend on `LinuxThreads'.

If you experience any strange problems during the installation of
MySQL, or with some common utilties hanging, it is very likely that
they are either library or compiler related. If this is the case, using
our binary will resolve them.

One known problem with the binary distribution is that with older Linux
systems that use `libc' (like RedHat 4.x or Slackware), you will get
some non-fatal problems with hostname resolution.  Note: Binary
notes-Linux.

When using LinuxThreads you will see a minimum of three processes
running.  These are in fact threads.  There will be one thread for the
LinuxThreads manager, one thread to handle connections, and one thread
to handle alarms and signals.

Note that the Linux kernel and the LinuxThread library can by default
only have 1024 threads.  This means that you can only have up to 1021
connections to MySQL on an unpatched system.  The page
`http://www.volano.com/linuxnotes.html' contains information how to go
around this limit.

If you see a dead `mysqld' daemon process with `ps', this usually means
that you have found a bug in MySQL or you have a corrupted table. Note:
Crashing.

To get a core dump on Linux if `mysqld' dies with a SIGSEGV signal, you
can start `mysqld' with the `--core-file' option.  Note that you also
probably need to raise the `core file size' by adding `ulimit -c
1000000' to `safe_mysqld' or starting `safe_mysqld' with
`--core-file-sizes=1000000'. Note: `safe_mysqld'.

If you are linking your own MySQL client and get the error:

     ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory

When executing them, the problem can be avoided by one of the following
methods:

   * Link the client with the following flag (instead of `-Lpath'):
     `-Wl,r/path-libmysqlclient.so'.

   * Copy `libmysqclient.so' to `/usr/lib'.

   * Add the pathname of the directory where `libmysqlclient.so' is
     located to the `LD_RUN_PATH' environment variable before running
     your client.

If you are using the Fujitsu compiler `(fcc / FCC)' you will have some
problems compiling MySQL because the Linux header files are very `gcc'
oriented.

The following `configure' line should work with `fcc/FCC':

     CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE -DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib  -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO '-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-low-memory