Skip navigation links
MySQL 5.4 Reference Manual :: 2 Installing and Upgrading MySQL :: 2.1 General Installation Issues :: 2.1.1 Operating Systems Supported by MySQL Community Server
2.1.2 Choosing Which MySQL Distribution to Install »
Section Navigation      [Toggle]

2.1.1. Operating Systems Supported by MySQL Community Server

This section lists the operating systems on which MySQL Community Server is known to run.

Important

Oracle Corporation does not necessarily provide official support for all the platforms listed in this section. For information about those platforms that are officially supported, see http://www.mysql.com/support/supportedplatforms.html on the MySQL Web site.

We use GNU Autoconf, so it is possible to port MySQL to all modern systems that have a C++ compiler and a working implementation of POSIX threads. (Thread support is needed for the server. To compile only the client code, the only requirement is a C++ compiler.)

MySQL has been reported to compile successfully on the following combinations of operating system and thread package.

MySQL has also been known to run on other systems in the past. See Section 2.13, “Operating System-Specific Notes”. Some porting effort might be required for current versions of MySQL on these systems.

Not all platforms are equally well-suited for running MySQL. How well a certain platform is suited for a high-load mission-critical MySQL server is determined by the following factors:

  • General stability of the thread library. A platform may have an excellent reputation otherwise, but MySQL is only as stable as the thread library it calls, even if everything else is perfect.

  • The capability of the kernel and the thread library to take advantage of symmetric multi-processor (SMP) systems. In other words, when a process creates a thread, it should be possible for that thread to run on a CPU different from the original process.

  • The capability of the kernel and the thread library to run many threads that acquire and release a mutex over a short critical region frequently without excessive context switches. If the implementation of pthread_mutex_lock() is too anxious to yield CPU time, this hurts MySQL tremendously. If this issue is not taken care of, adding extra CPUs actually makes MySQL slower.

  • General file system stability and performance.

  • Table size. If your tables are large, performance is affected by the ability of the file system to deal with large files at all and to deal with them efficiently.

  • Our level of expertise here at Oracle Corporation with the platform. If we know a platform well, we enable platform-specific optimizations and fixes at compile time. We can also provide advice on configuring your system optimally for MySQL.

  • The amount of testing we have done internally for similar configurations.

  • The number of users that have run MySQL successfully on the platform in similar configurations. If this number is high, the likelihood of encountering platform-specific surprises is much smaller.


User Comments

Posted by S Harper on October 4 2004 3:20pm[Delete] [Edit]

The information above on FreeBSD (covering versions up through 4.X) is now outdated. A lot of work has gone into improved threading libraries with FreeBSD versions 5.X in conjunction with the SMPng project. For older versions of FreeBSD, you can also use the linuxthreads options.

See `man pthread` and `man libkse` within FreeBSD 5.X for more details on libkse, libthr and the improved threading model.

To quote from the 5.X release notes:

"The libkse library, providing POSIX threading support using KSE, is now enabled and installed by default. This library currently supports M:N threading. Both process and system scope threads are supported, as well as getting/setting the concurrency level. By default, the library sets the concurrency level to the number of CPUs in the system. Each concurrency level correlates to a KSE, and all process scope threads run in these KSEs. Each system scope thread gets its own KSE in addition to those corresponding to concurrency levels. libkse is still considered a work-in-progress, and is not used by default. However, it can be used as a replacement for the libc_r thread library, by substituting -lkse instead of -pthread when linking programs.

MySQL is now being used with success with the FreeBSD 5.X threading models on multiple websites, so you shouldn't let this manual section discourage you from installing and using MySQL on your own FreeBSD 5.X server. Real-life experience with 5.X demonstrates that while there may still be a few minor issues, the situation is much improved and much closer to the previous support for MySQL's desired threading model on Linux.

Posted by Unreal Hshh on January 21 2005 6:59pm[Delete] [Edit]

Compile MySQL 4.1.x in FreeBSD 5.2+ with KSE threads:

./configure --prefix=/usr/local/mysql --without-libedit --without-readline --without-debug --without-bench --enable-thread-safe-client --enable-assembler --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --with-extra-charsets=complex --with-named-thread-libs='-lkse -D_THREAD_SAFE' CFLAGS='-pipe -march=i686 -fno-omit-frame-pointer -O2 -D_THREAD_SAFE' CXXFLAGS='-pipe -march=i686 -fno-omit-frame-pointer -O2 -felide-constructors -fno-rtti -fno-exceptions -D_THREAD_SAFE'

You must tune somethings abount sysctl

kern.threads.max_threads_per_proc
kern.threads.max_groups_per_proc

Default is 150 50 ,and it's too low
Try to change them to 1000.


Also you can build the mysql with pthread, dynamic execuable.
Then add the libc_r to libkse at /etc/libmap.conf

If you are using FreeBSD 5.3+, use -lpthread instead of -lkse

Add your own comment.