[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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. For a typical user, even for setups with a lot of concurrent
connections or tables exceeding the 2G 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 see whether it meets
your needs. If you discover that our binary is not good enough, then
you may want to try your own build. In that case, we would appreciate
a note about it, so 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 get
LinuxThreads at http://www.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 you issue INSERT DELAYED
statements. We recommend that you not use
INSERT DELAYED
before upgrading glibc
.
Note that Linux kernel and the LinuxThread library can by default only have 1024 threads. If you plan to have more than 1000 concurrent connections, you will need to make some changes to LinuxThreads:
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.)
The page http://www.volano.com/linuxnotes.html contains additional information about circumventing thread limits in LinuxThreads.
There is another issue that greatly hurts MySQL performance, especially on
SMP systems. The mutex implementation in LinuxThreads in glibc
2.1 is very bad 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://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 likelihood that this condition
will occur can be reduced by renicing the mysqld
process to the highest
priority. We have also been able to correct the overspin behavior 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 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 the commands needed to produce
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 that require
LinuxThreads against the
patched static version of the library, or build a patched shared version and
install it on your system, you are doing it 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 will resolve 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:
-Wl,r/full-path-to-libmysqlclient.so
flag rather than with -Lpath
).
libmysqclient.so
to `/usr/lib'.
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 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |