( Source notes-Linux

Info Catalog ( Binary notes-Linux ( Linux ( Linux-post-install 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 `' 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
 `'.  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 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: fatal:
      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/' flag
      rather than with `-Lpath').
    * Copy `' to `/usr/lib'.
    * Add the pathname of the directory where `' is
      located to the `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 \
Info Catalog ( Binary notes-Linux ( Linux ( Linux-post-install
automatically generated byinfo2html