Search the MySQL manual:

2.6.2 Linux Notes (All Linux Versions)

The following notes 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 following text, 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 the 2G 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/os-linux.html.

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 upgrade to Linux 2.4 as soon as possible. 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 that you 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 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 onward, you can check the number of allocated file handles 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 16 MB of memory, you should add something like the following to your init scripts (for example, `/etc/init.d/boot.local' on SuSE Linux): 

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 preceding commands from the command-line as root, but these settings will be lost the next time your computer reboots.

Alternatively, you can set these parameters on bootup by using the sysctl tool, which is used by many Linux distributions (SuSE has added it as well, beginning with SuSE Linux 8.0). Just 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 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 threads 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" behaviour 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" behaviour 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 2G 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 penalises 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 at 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 queries throughput all the way up to 1000 clients, and the 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 mysqld_safe. 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 information 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 glibc-2.1 is very bad for programs with many threads that only hold the mutex for a short time. On an SMP system, ironic as it is, if you link MySQL against unmodified LinuxThreads, removing processors from the machine improves MySQL performance in many cases. We have made a patch available for glibc 2.1.3 to correct this behaviour (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

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 glibc-2.2.2 overspins, which hurts MySQL performance. The chance of this condition can be reduced by renicing mysqld process to the highest priority. We have also been able to correct the overspin behaviour with a patch, available at http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. It combines the correction of overspin, maximum number of threads, and stack spacing all in one. You will need to apply it in the linuxthreads directory with patch -p0 </tmp/linuxthreads-2.2.2.patch. We hope it will be included in some form in to the future releases of glibc-2.2. In any case, if you link against glibc-2.2.2 you still need to correct STACK_SIZE and PTHREAD_THREADS_MAX. We hope that the defaults will be corrected to some more acceptable values for high-load MySQL setup in the future, so that your own build can be reduced to ./configure; make; make install.

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 utilities 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 Red Hat 4.x or Slackware), you will get some non-fatal problems with hostname resolution. See section 2.6.2.1 Linux Notes for Binary Distributions.

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. See section A.4.1 What To Do If MySQL Keeps 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 mysqld_safe or starting mysqld_safe with --core-file-size=1000000. See section 4.7.2 mysqld_safe, The Wrapper Around 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:

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

Subsections

User Comments

Add your own comment.