6.3 操作系统

li3p

从操作系统的角度，打造一个快速的MySQL服务器需要考虑几个方面。我们下面讨论的内容，包括了几个与文件系统相关的因素、交换分区的配置以及线程的性能。
6.3.1 文件系统（Filesystems）
免费可用的文件系统在Linux世界中的蓬勃发展，导致了对Linux操作系统下什么是MySQL最佳文件系统的持久讨论。从某种意义上讲，这与为你的数据表选定正确的存储引擎是同一个问题。你需要考虑每种选择的优势和劣势，并确定你的需求是怎样的。然而与更换表类型不同，你不能随意改变所使用文件系统。而且如果不经历一些维护上恶梦，你也不能简单的为某些表使用一种文件系统，而其他的表使用另外一种文件系统。
值得指出的是，大多数情况下文件系统的性能差距相对而言是很小的。如果你更换了文件系统带来最大的性能提升，那是你作对了这之外的很多其他事情，从而获得的回报。
本章是完全针对Linux系统的。主要是因为Linux是拥有最广泛选择的操作系统，另外碰巧也是本书作者最有经验的系统。
6.3.1.1 文件系统日志（Journaling）
文件系统间最大的区别是日志（Journaling）。日志型文件系统维护一个永远不被缓存的日志（Log或Journal）。日志的概念与预写事务日志（Write-ahead Transaction Log）的概念有些类似。当文件系统更新时，一个描述该事务的记录就被追加到日志中。另外一个空闲的线程就会真正的处理这些事务，并将新的数据写入文件系统，然后在完成后对所处理的每个事务做上标记。
如果机器崩溃，文件系统就会执行一个回滚式恢复，就像InnoDB存储引擎所作的那样。重新启动完成之后，就不再从日志中进行更新了。日志中不完整的事务会被丢弃，文件系统的内部一致性从而就得到了保障。这显著的降低了运行一次文件系统扫描的复杂性，这意味着在系统崩溃后重新启动时耗费的时间更短。尽管InnoDB本身提供了自己的日志机制（以事务日志Transaction Log的形式），为InnoDB采用一个日志型的文件系统仍然是值得的，因为在意想不到的系统重启之后这仍然会节省时间。
比较早的文件系统，比如Linux平台中的ext2和Windows平台中的FAT16/FAT 32是不支持日志的。一旦遭遇一次未预期的崩溃，这些文件系统就会需要在重新启动的时候执行一次一致性检查。在Linux系统中，你必须等待fsck命令完成检查工作。在Windows平台上是scandisk来进行类似的工作。幸运的是Microsoft的服务器操作系统，像Windows NT/ 2000/ XP等，都提供NTFS文件系统作为其标准的日志型文件系统。在Macintosh的平台上，OS X 提供名为HFS的日志型文件系统。Tru64和AIX也提供了它们自己的日志型文件系统实现。
FreeBSD目前还没有日志型文件系统可用，但是它提供了另外一种途径来实现日志，叫做软更新（soft updates）。开发者是BSD的Hacker之一Kirk McKusick，软更新保证元数据改变能够按数据就总能够处于一致状态的顺序写入磁盘。这样一来通过组合磁盘操作提升性能的时候，就消除了对独立的日志和同步磁盘操作的需求。更多的信息可以访问Kirk的网站（
http://www.mckusick.com/softdep/
），同时也可查看FreeBSD的newfs/tunefs的手册页。
　　Solaris平台上需要日志型文件系统的用户，传统上都是从Verita公司购买一个产品。但是新版本的Solaris提供了一个日志型文件系统，不再需要使用第三方的软件了。
6.3.1.2　其它的特性和优化
很多新型的文件系统（指过去10年左右设计出来的）中，包含其他一些会对性能产生影响的重要特性。这些文件系统的设计者那时意识到硬盘的容量会持续增加，以及更强的新型应用程序（大容量的数据库，流媒体，等等）会从文件系统的重新设计中获益。最终的结果，就是我们在今天拥有很多高性能的文件系统可以选择。6.3.1.3章节有更详细的信息。
这些新型文件系统中，有两个增强最值得注意，那就是对大型目录的支持和更好的对磁盘碎片以及空闲空间的管理。大目录支持是指操作含有上千个文件的目录不会明显的比操作起一个小目录来得慢。在MySQL中只有当你的一个数据库包含大量的MyISAM表的时候这才会成为一个问题。因为每个MyISAM表包含三个文件，文件数量会因此迅速增长。
如果拥有大量被频繁改变（大量的删除、插入以及更新）的MyISAM表，空闲空间管理和磁盘碎片影响系统性能。在为文件分配连续的磁盘空间块方面，某些文件系统要比其他的文件系统来的聪明。这有助于减少磁盘碎片，这也意味着操作数据表的时候用于磁盘寻道的时间更少。
6.3.1.3 文件系统的选择
为MySQL选择一种文件系统，实际上就是考虑你的实际需要、可用的文件系统、以及你对此文件系统的熟悉程度。下面我们列出几个对现代Linux系统可选的文件系统的简要描述：

ext2
ext2文件系统从初期就伴随Linux。它没有提供很多高级功能，但是它久经考验并以非常轻量级和可靠而著称。

ext3
对ext2文件系统的加入日志支持的需要，演化出了ext文件系统。你可以简单的认为ext3－就是ext附加上日志功能。大部分ext2文件系统的限制（比如对大型路径处理的糟糕表现）仍然存在于ext3中。
Ext3实现上的一个有趣的副产品，就是你能够使用tunefs 命令真正的打开和关掉ext3的日志。当日志关掉时，一个ext3文件系统有效的又成为了一个ext2文件系统。

ReiserFS
ReiserFS，最初是由Hans Reiser开发，已经在Linux世界中广为使用。这是一个彻底重新实现的现代文件系统。它对大型目录的处理特别好，而且具有非常可靠的日志实现。在写本书的时候，ReiserFS的3版本已经被广泛使用，4版本也在核心开发者和其他一些敢于冒险的使用者中进行测试了。

XFS
由SGI从他们的IRIX操作系统移植而来，XFS被设计在着重于以一致的性能处理大型的文件系统。SGI初衷是创建一个能够处理高端流媒体应用所产生的高负载下工作的文件系统。

JFS
JFS也系出名门，来自向SGI一样著名的另外一个大型科技公司。IBM已经在它们的AIX平台上使用JFS很多年了。向SGI一样，IBM在构建JFS的时候也专注与性能和可靠性。

Table 6-2
汇总了各种Linux平台上文件系统的特性
Table 6-2. Linux filesystem features
Filesystem
Journaling
Large directories
ext2
No
No
ext3
Yes (optional)
No (patch available)
ReiserFS
Yes
Yes
XFS
Yes
Yes
JFS
Yes
No
6.3.1.4 FreeBSD
在FreeBSD平台上，只有两种文件系统可以选择：UFS和UFS2。这两者的主要区别在于UFS2能够处理超过1TB的数据，而且具有内置的存取控制表（Access Control List ，ACL）以及扩展属性支持。除了数据大小，没有会对数据库使用者造成影响的区别。如果你由大目录，UFS_DIRHASH 这个内核选项会有帮助。它为大型目录在内存中创建哈希表，同时并不会对磁盘上的文件分布造成影响。
6.3.1.5 你到底需不需要一个文件系统？
传统的高端数据库服务器通常根本不用操作系统提供的文件系统。取而代之，数据库服务器完全绕过文件系统直接与磁盘进行交互。这种原生的存取方式将管理空间、碎片和读写请求的重担都留给了数据服务器自己。
之所以绕过文件系统，究其历史原因，在于早期的操作系统对于文件系统的性能并不怎么强调。只要它们能够可靠的存取数据，就已经可以让大多数人满意了。另外一个原因是当时没有卷管理器，所以那个时候的操作系统没有办法将服务器的硕大的10M的硬盘组合成单个的、更大的逻辑盘。当数据库持续增长超过了单个硬盘的大小时，数据库的提供商除了提供自己的底层存储机制外就别无选择了。
如今，现代磁盘已经增大了若干数量级，现代的服务器提供了RAID，现代的操作系统通常具备分卷管理器可以轻而易举的为单个卷增加更多的空间。尽管有了这些进步，很多的DBA还是更愿意使用原生分区而不是文件系统。从其他数据库系统转过来的人经常会问MySQL是否具有使用原生分区的能力，而并不关心这对性能的提升到底有多大。不是多嘴，MySQL的InnoDB存储引擎是可以为它的表空间使用原生分区的。
为了利用这个功能，你必须在配置文件中将InnoDB的主目录设置为空，并且指定数据文件路径到原生设备：
innodb_data_home_dir=innodb_data_file_path=/dev/sdb1:18Graw;/dev/sdc1:18Graw
不管怎样，你必须首先初始化这些分区。为了初始化，在首次启动MySQL的时候，使用newraw来替代上述配置中的raw选项，然后启动MySQL。InnoDB将初始化指定的分区。注意查看MySQL的日志文件等待初始化完成，然后停掉MySQL，再将newraw 选项变回到 raw，之后再次启动MySQL。
从性能的角度来看，测试数据表明使用原生分区只会带来非常小（2-5%）的性能提升。当你使用原生分区，你将不能再使用任何你所喜爱的命令行工具（ls，du等等）来检查存储设备。而且，使用原生分区时的备份也变得更加复杂。可勇的备份工具选择范围也变得极窄，因为大多数工具都是处理文件系统而不是原生磁盘分区的。
6.3.2 交换分区（Swap）
在理想情况下，你的服务器将永远不会用到交换（SWAP）分区。交换的发生通常说明你的内存不够或者某些配置有误－也许MySQL的键缓冲区太大了，或者你在系统启动时运行了过多无用的系统服务。也有可能是操作系统本身的问题，某些操作系统即使在仍然有内存可用的情况下也总是要进行交换。
比如，某些2.4版本的Linux内核，就因有点过度交换而闻名。Linux通常将尝试用所有的空闲内存用作磁盘存取缓存。从虚拟内存子系统的角度，空闲的内存是一种浪费。早期的内核版本（2.4.0-2.4.9）是没有问题的，后期的版本（2.4.18之后）也是没问题的。但是中间的版本（2.4.10-2.4.17）就是出名的过份。在一台独立的MySQL服务器上，有2G的物理内存，使用1G作为键缓冲区，会频繁看到在进行一次表扫描的时候，Linux会将键缓冲区的部份内容交换出来，仅仅片刻之后又再放回去。不用说这对性能会造成很大的负面影响。而这种情况唯一的解决办法就是关掉整个交换分区或者升级到新的内核。幸运的是，其他的操作系统不会遭遇这个问题。尽管其他的操作系统都运转良好，很多MySQL管理还是主张将关掉交换分区作为一项预防措施。
6.3.3 线程（Threading）
作为一个多线程的服务器，MySQL在拥有实现良好的线程机制的操作系统上最有效率。Windows和Solaris在这方面都表现优异。Linux，一般来说有些不同。传统上Linux曾经使用略有些不寻常的线程实现－使用克隆的进程作为线程。绝大多数情况下这种方式表现良好，但是在有上千个活动的客户端连接的情况下，就会带来很多的额外开销。
Linux中的调度器最近的一些改进以及一些第三方的线程库改善了这种情况。本地POSIX线程库（Native POSIX Thread Library ，NPTL）已经默认随着RedHat Linux 9.0发布了。其他的发行版也正开始采用NPTL。
另外一个流行的免费操作系统－FreeBSD，在线程上的问题比Linux更加糟糕。5.2之前的版本提供的本地线程实现相当的弱。在某些情形下，I/O密集的线程能够获得多得不正常的CPU执行时间，从而致使其他得线程不能够尽快的执行。基于某些数据库查询的I/O密集的本质，这对MySQL带了极其负面的影响。
如果升级操作系统的办法不可取，那么就要从FreePSD的ports集中编译MySQL，并要确保打开了对LinuxThreads的支持。这样可以让MySQL使用另外的一个更像Linux 2.4版本的线程实现。每个线程实际上都是一个进程，但是得益于FreeBSD的rfork( )调用，每个进行共享MySQL的全局缓冲区。这种实现方式听起来的开销不小，但是实际上这是非常高效的。上百台Yahoo所采用的MySQL服务器就是使用LinuxThreads的方式有效的运行的FreeBSD平台上的。
本章的后续小节6.4.4讨论了MySQL的线程缓存，是如何有助于降低创建和销毁线程所带来额外开销的。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/7114/showart_264495.html