(mysql.info.gz) Source notes-Linux
(mysql.info.gz) Binary notes-Linux
18.104.22.168 Linux Source Distribution Notes
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 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 see whether it meets your needs. If you discover that it is
not good enough, then 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 get LinuxThreads at
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 1,024 threads. If you plan to have more than 1,000 concurrent
connections, you will need to make some changes to LinuxThreads:
* 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 will not be
stable with around 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.
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
With `glibc' 2.2.2, MySQL 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
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 these 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 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 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:
* Link clients with the `-Wl,r/full/path/to/libmysqlclient.so' flag
rather than with `-Lpath').
* 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
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'" \
--prefix=/usr/local/mysql --enable-assembler \
--with-mysqld-ldflags=-all-static --disable-shared \
(mysql.info.gz) Binary notes-Linux
automatically generated byinfo2html