(mysql.info) source-notes-linux

 
 2.12.1.3 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 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. We recommend that you 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.
 
 Additional information about circumventing thread limits in
 LinuxThreads can be found at `http://www.volano.com/linuxnotes.html'.
 
 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://www.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://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 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'.
 
 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 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:
 
    * 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
      your client.
 
 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
Info Catalog
(mysql.info) binary-notes-linux
(mysql.info) linux
(mysql.info) linux-post-install
automatically generated byinfo2html