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 use our binary. We link our binaries against
the best patched version of glibc
we can
find and with the best compiler options, in an attempt to make
it suitable for a high-load server. For a typical user, even
for setups with a lot of concurrent connections or tables
exceeding the 2GB limit, our binary is the best choice in most
cases. After reading the following text, if you are in doubt
about what to do, try our binary first to determine whether it
meets your needs. If you discover that it is not good enough,
you may want to try your own build. In that case, we would
appreciate a note about it so that we can build a better
binary next time.
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 obtain LinuxThreads from
http://dev.mysql.com/downloads/os-linux.html.
Note that glibc
versions before and
including version 2.1.1 have a fatal bug in
pthread_mutex_timedwait()
handling, which
is used when INSERT DELAYED
statements are issued. Do not use INSERT
DELAYED
before upgrading glibc
.
Note that Linux kernel and the LinuxThread library can by default handle a maximum of 1,024 threads. If you plan to have more than 1,000 concurrent connections, you need to make some changes to LinuxThreads, as follows:
Increase PTHREAD_THREADS_MAX
in
sysdeps/unix/sysv/linux/bits/local_lim.h
to 4096 and decrease STACK_SIZE
in
linuxthreads/internals.h
to 256KB.
The paths are relative to the root of
glibc
. (Note that MySQL is not stable
with 600–1000 connections if
STACK_SIZE
is the default of 2MB.)
Recompile LinuxThreads to produce a new
libpthread.a
library, and relink
MySQL against it.
There is another issue that greatly hurts MySQL performance,
especially on SMP systems. The mutex implementation in
LinuxThreads in glibc
2.1 is very poor for
programs with many threads that hold the mutex only for a
short time. This produces a paradoxical result: If you link
MySQL against an unmodified LinuxThreads, removing processors
from an SMP actually improves MySQL performance in many cases.
We have made a patch available for glibc
2.1.3 to correct this behavior
(http://dev.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).
With glibc
2.2.2, MySQL uses 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 likelihood that this condition occurs can be
reduced by re-nicing the mysqld process to
the highest priority. We have also been able to correct the
overspin behavior with a patch, available at
http://dev.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 need to apply it in
the linuxthreads
directory with
patch -p0
</tmp/linuxthreads-2.2.2.patch
. We hope it is
included in some form in 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 is corrected to some more acceptable values for
high-load MySQL setup in the future, so that the commands
needed to produce your own build can be reduced to
./configure; make; make install.
If you use these patches to build a special static version of
libpthread.a
, use it only for statically
linking against MySQL. We know that these patches are safe for
MySQL and significantly improve its performance, but we cannot
say anything about their effects on other applications. If you
link other applications that require LinuxThreads against the
patched static version of the library, or build a patched
shared version and install it on your system, you do so at
your own risk.
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 resolves them.
If you link your own MySQL client programs, you may see the following error at runtime:
ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory
This problem can be avoided by one of the following methods:
If you are using the Fujitsu compiler
(fcc/FCC
), you may 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
User Comments
http://www.mysql.com/doc/en/Source_notes-Linux.html
1. The statement "Link clients with the -Wl,r/full-path-to-libmysqlclient.so flag rather than with -Lpath)." is wrong.
I think the flag should be written like
-Wl,-R/usr/local/mysql/lib/mysql
2. The statement "Add the pathname of the directory where `libmysqlclient.so' is located to the LD_RUN_PATH environment variable before running your client." is also wrong as LD_RUN_PATH is referred when compiling, not when running.
One of the benefits of the statically linked mysqld binary and the LinuxThreads patch is that mysqld will be able to use much more of its address space compared to other mysqld binaries linked with an unpatched LinuxThreads library. The problem is that thread stacks are spaced 2MB apart by LinuxThreads. With the default thread stack size of 192KB, there is a 1.8MB gap between each stack. malloc is able to use 1MB from each gap for small allocation requests. The remainder will only be used when large malloc (> 150KB) requests are made. The result is that there will appear to be much space available in the address space but MySQL can get memory allocation failures because it has lost ~800KB per connection-thread.
This problem does not occur when linked with NPTL.
Add your own comment.