数据库服务器的性能调优-续
一、进程管理
企业级数据库服务器可能拥有数千个并发访问数据库的用户。某些用户可能执行只需较少处理能力的简单事务，而其他用户则可能执行涉及更多系统资源的复杂事务。 数据库性能常常基于诸如每小时的事务数或 X个并发连接下的最小响应时间等度量来讨论。这些性能约束由企业施加，以便确保客户的质量保证等级。由于对并发处理具有如此高的需求，企业级数据库服务器需要运行于大型 SMP服务器上。早期的 Linux内核并不很适合充当需要高并发度的数据库服务器。这些内核并没有随着系统上的处理器数量的增加而提供良好的扩展性，因为早期内核的开发由单处理器机器所驱动。迁移至多处理器平台时需要许多全局内核锁的支持，否则会导致串行化问题。 其中最大的锁是用于保护单个未排序的运行队列的自旋锁(spin lock)。 在单处理器环境中， 单个队列足以调度所有可运行任务。然而， 在 SMP环境中， 单个运行队列并不够，这会成为一个瓶颈。随着处理器数量的增多，在运行队列上锁竞争的可能性也增加。另
外，由于该队列是未排序的，当锁被持有时调度器需要检查队列中的所有任务以便确定每个任务的良好度(每个任务被赋予一个良好度取值， 用于确定哪个任务将是被调度至处理器上运行的最佳候选)。 这增加了锁持有时间， 从而增加了锁竞争的可能性或加剧当前的竞争条件。在 Linux 2.5内核中， 这个唯一运行队列被删除并替换为基于 CPU的运行队列。拥有多个运行队列删除了对单个全局锁的需求并改进了整体的可扩展性。另外，每个运行队列都维护一个优先级列表，有助于调度器选择要运行的最佳任务。这种优先排序可以减少队列上的锁持有时间，并进一步减少了锁竞争 。
二、内存管理
管理大型企业的数据库需要在大型对称多处理(SymmetricalMultiprocessing，SMP)服务器上运行。这种服务器常常配置了海量物理内存。系统的大部分内存都被分配给数据库缓冲区 cache区域(称为数据库缓冲区)。数据库缓冲区用于缓存从磁盘读至内存中的表和索引数据页。由于磁盘访问相对于内存访问来说是缓慢的操作，将更多内存分配给数据库缓冲区可以极大改进数据库性能。适当调优的数据库会占用大部分可用内存，而为其他正在运行的应用和操作系统只保留够用的内存大小。为数据库分配过多内存会剥夺其他应用可用的内存空间。 另外， 过度分配内存会导致过多的交换， 这对于数据库性能极为有害。
Linux内核如何管理物理内存对于数据库服务器的性能而言也很重要。在 IA-32体系结构中， 内核基于 4KB大小的页面管理内存。 另一方面， 大多数当代的处理器都支持更大的页面(高达数兆字节)。对于许多应用来说， 4KB页面大小是理想的。小页面可以减少内部分段，将数据换入和换出内存时会产生更小的开销，并确保使用中的虚存驻留于物理内存中。大部分数据库服务器对于其数据库缓冲区都使用大型共享内存段。其结果是需要大量页表项(PageTableEntrie， PTE)。这给内存管理器添加了很大的维护开销。 例如，假若某个数据库服务器使用 4MB大小的共享内存段为其缓冲区分配 1GB共享内存。使用4KB页面大小的内核需要 262 144个 PTE， 这个庞大的页表数量会给内存管理器增添极大的维护开销。 当然， 上述数据是过分简化的计算值。 实际的 PTE数将远大于这个数值，因为 Linux无法对共享内存的页表进行共享。
Linux 2.6内核中提供了对更大页面的支持。进程可以从内存池中显式请求大页面。使用大页面可以减少当应用请求大型内存块时所需的 PTE数。因此， 维护 PTE所需的计算成本也得以减少。 对于前面的示例， 如果页面大小是 4MB而不是 4KB， 那么 1GB数据库缓冲区只需要 1 024个 PTE(这个计算也被过度简化)。大页面支持特性的另一个优点是增加了 TLB(translation lookaside buffer)所覆盖的内存范围， 从而降低了 TLB不命中的概率。与页表访问相比较而言， TLB访问的速度极快，因为它是 CPU缓存区域。
三、I/O 管理
数据库性能严重依赖于高效快速的I/O操作。由于有可能要处理 TB量级的数据，任何 I/O瓶颈都会导致数据库服务器难以满足商业需求。 数据库管理员(DBA)通常花费大量时间和金钱对 I/O子系统进行优化，以便减少 I/O延迟并最大化 I/O吞吐率。早期 Linux内核存在着许多阻碍 I/O性能的缺陷，也缺乏诸如原始 I/O、向量 I/O、异步I/O以及直接 I/O等特性， 这限制了 DBA对在其他平台上已知能够改善数据库性能的技术加以利用的能力。另外，功能上的匮乏，例如回弹缓冲和单个 I/O请求队列锁，增添了不必要的系统成本并引入了串行化问题。 幸运的是， 这些问题在 Linux 2.6内核中或通过对2.4内核打补丁都已被消除。1、回弹缓冲区
在早期的 Linux 内核(早期的 2.4及先前的内核版本)中，设备驱动程序无法直接访问高端内存中的虚址。换句话说，这些设备驱动程序无法对高端内存执行直接内存访问I/O。相反， 内核在低端内存中分配缓冲区，数据通过内核缓冲区在高端内存和设备驱动程序之间传输。 这个内核缓冲区通常称为回弹缓冲区(bouncebuffer)， 该过程被称为回弹或回弹缓冲。由于数据库服务器的 I/O密集特征，回弹过程严重地降低了数据库服务器的性能。首先，回弹缓冲区会消耗低端内存，这可能导致内存短缺问题。其次，过量的回弹操作会引起系统占用时间较长， 导致数据库系统完全变成 CPU绑定的。数据库服务器性能领域的一个主要进展即是在最近的内核中消除了回弹缓冲机制。
2、 原始I/O
Linux 2.4内核中引入的块设备原始(raw)I/O接口提供了从用户空间缓冲区直接执行I/O的能力，而不必通过文件系统接口进行额外复制。 raw接口的使用避免了文件系统层次上的操作，因此能够极大改进数据库服务器的 I/O性能。然而，应该注意到，并非所有的数据库工作负荷都能够受益于 raw I/O的使用。如果需要经常访问相同数据， raw I/O就无法利用文件系统缓冲区 cache。raw I/O接口使得 DBA在针对性能目标而进行数据库设计时具有更多的灵活性。 基于数据库服务器的 I/O特征， DBA可选择使用 raw接口以获得更快的 I/O操作，或者使用文件系统缓存机制并减少磁盘访问操作，或者组合使用上述两种机制，这依赖于对数据库中的表的访问方式 。3、 向量I/O
Linux 2.6内核通过readv和writev接口提供了向量I/O(vectored I/O，也称scattered I/O)的完整实现。向量读操作接口 readv将磁盘上的连续页面读入内存中的非连续页面上；与之相反，向量写操作接口 writev通过单个函数调用将内存中的非连续页面写到磁盘上。这种 I/O机制有利于频繁执行大量串行 I/O操作的数据库服务器。如果没有正确的向量
读写实现，则执行串行 I/O的应用会完成以下操作之一：
读写实现，则执行串行 I/O的应用会完成以下操作之一：
- 执行数据库页面大小的 I/O操作。
- 执行大型块 I/O操作，并使用 memcpy函数在读/写缓冲区与数据库缓冲区之间复制数据页面。
4、 异步I/O
异步I/O机制为应用提供了发出 I/O请求后无需阻塞并等待该 I/O完成的能力。该机制很适合数据库服务器。其他平台提供异步 I/O接口已有一段时间，但该特性在 Linux上还相对较新。在没有异步 I/O机制的情况下要提高 I/O吞吐率， 数据库服务器通常创建许多专门执行 I/O的进程或线程。由于大量进程/线程都在执行 I/O活动， 数据库应用不再阻塞于单个 I/O请求上。 使用大量进程/线程方式的缺点是创建、 管理和调度这些进程/线程会产生额外的开销。GNU C Library(GLIBC)异步 I/O接口通过用户级线程来执行阻塞 I/O操作。这种方法只是使得请求对于应用而言看起来是异步的，但与前面描述的方法并无区别，也面临着同样的性能缺陷。为了消除该问题， Linux 2.6 内核中引入了内核异步 I/O(Kernel AsynchronousI/O， KAIO)接口。 KAIO在内核而不是用户空间中以线程方式实现异步 I/O
机制，确保了真正的异步性。
5、 直接I/O
直接 I/O具有可与原始 I/O相媲美的性能，又拥有文件系统的额外灵活性。因此对于希望在保持数据库维护灵活性的同时又使用文件系统作为存储介质的数据库管理员来说，直接I/O是具有吸引力的机制。
使用文件系统而不是 raw设备作为存储介质的主要吸引力是因为其易于调整数据库存储器的容量。只需添加更多的磁盘就可以增加文件系统的大小。 文件系统的另一个优点是提供了许多可用的工具，例如， DBA可以使用 fsck来帮助维护数据完整性。
将文件系统用作没有直接 I/O接口的存储介质也存在着一些缺点。其中之一就是缓冲区 cache守护进程所增加的开销，该进程会主动地将脏页面清空到磁盘上。这种活动所消耗的 CPU周期对于 CPU密集的数据库工作负荷来说是宝贵资源；另一个缺点与缓冲区cache不命中问题有关。如果数据不经常重用，其开销会很大。
对于大型数据库系统而言，会为数据库缓冲区分配内存。大型的数据库缓冲区降低了数据库应用的磁盘读写频率，也减少了文件系统缓冲区 cache可用的内存量。这会对服务器性能产生双面影响。首先， 缓冲区 cache守护进程更积极地将脏页面清空到磁盘上(页面更快地变脏)。 其次， 对于容量更小的缓冲区 cache， 数据驻留于其中的可能性要
小得多，这增加了缓冲区 cache不命中的可能性 。
使用文件系统而不是 raw设备作为存储介质的主要吸引力是因为其易于调整数据库存储器的容量。只需添加更多的磁盘就可以增加文件系统的大小。 文件系统的另一个优点是提供了许多可用的工具，例如， DBA可以使用 fsck来帮助维护数据完整性。
将文件系统用作没有直接 I/O接口的存储介质也存在着一些缺点。其中之一就是缓冲区 cache守护进程所增加的开销，该进程会主动地将脏页面清空到磁盘上。这种活动所消耗的 CPU周期对于 CPU密集的数据库工作负荷来说是宝贵资源；另一个缺点与缓冲区cache不命中问题有关。如果数据不经常重用，其开销会很大。
对于大型数据库系统而言，会为数据库缓冲区分配内存。大型的数据库缓冲区降低了数据库应用的磁盘读写频率，也减少了文件系统缓冲区 cache可用的内存量。这会对服务器性能产生双面影响。首先， 缓冲区 cache守护进程更积极地将脏页面清空到磁盘上(页面更快地变脏)。 其次， 对于容量更小的缓冲区 cache， 数据驻留于其中的可能性要
小得多，这增加了缓冲区 cache不命中的可能性 。
6、块I/O
设备驱动程序以称为块的一组字节为单位来传输数据。块大小被设置为设备的扇区大小，通常为 512B(尽管许多硬件设备及其相关驱动程序可以处理更大的传输文件)。 每个块在内存中都关联着一个缓冲区头部结构。当来自应用的读请求通过read调用到达时，设备驱动程序将读缓冲区划分成扇区大小的多个块，在与每个块相关的缓冲区头部里填
充来自物理设备的数据，然后再将这些块接合为原始的读缓冲区。类似地，当来自应用的一个写请求到达时， 设备驱动程序将写缓冲区划分成扇区大小的块，并使用相关缓冲区头部的取值来更新磁盘上的物理数据。在 Lnux2.6内核中，原始 I/O的块大小为 4096B而不是 512B。 这个简单的变化通过减少原始 I/O操作所需的缓冲区头部数量， 改进了整体 I/O吞吐率和 CPU利用率。缓冲区头部更少的话，也可以降低维护其所需的内核开销，而大型块的使用减少了设备驱动程序针对一个 I/O请求需要执行的划分—接合操作数。
充来自物理设备的数据，然后再将这些块接合为原始的读缓冲区。类似地，当来自应用的一个写请求到达时， 设备驱动程序将写缓冲区划分成扇区大小的块，并使用相关缓冲区头部的取值来更新磁盘上的物理数据。在 Lnux2.6内核中，原始 I/O的块大小为 4096B而不是 512B。 这个简单的变化通过减少原始 I/O操作所需的缓冲区头部数量， 改进了整体 I/O吞吐率和 CPU利用率。缓冲区头部更少的话，也可以降低维护其所需的内核开销，而大型块的使用减少了设备驱动程序针对一个 I/O请求需要执行的划分—接合操作数。
7、 I/O请求锁
Linux内核为每个块设备都维护一个 I/O请求队列。 该队列以一种最大化系统性能的方式对 I/O请求进行排序。在 Lnux 2.2和早期的 2.4内核中，所有的请求队列由一个称为io_request_lock的全局自旋锁加以保护。对于在尤许多磁盘构成的 SMP机器上运行的数据库服务器来说，这个 I/O请求锁会导致严重的串行化问题。
最近的内核版本里已从 SCSI子系统中删除了这个全局锁(io_request_lock)。在其位置上，每个 I/O请求队列都由自己的 request_queue_lock锁加以保护。 I/O请求的串行化现象仍会出现，但只发生在单个请求队列上，而不会发生在 SCSI子系统中的所有请求队列上。
最近的内核版本里已从 SCSI子系统中删除了这个全局锁(io_request_lock)。在其位置上，每个 I/O请求队列都由自己的 request_queue_lock锁加以保护。 I/O请求的串行化现象仍会出现，但只发生在单个请求队列上，而不会发生在 SCSI子系统中的所有请求队列上。
四、 小结
从 Linux 2.4版本转换至 2.6版本后出现的大量内核变化改进了数据库服务器性能。诸如多个运行队列等特性的引入通过删除系统中的串行点增强了 SMP扩展性。诸如向量I/O、异步 I/O和直接 I/O等变化所提供的内核服务已在其他平台上证明有助于提高数据库性能。这些改进特性多数已包含在 SUSE或 RHEL基于 2.4内核的发行版本中。随着Linux不断地向数据库服务器领域扩展，更多的性能瓶颈将会显现出来，从而持续推动内核开发以改进性能，并且在此过程中使得 Linux成为各类数据库应用工作负荷的一种更有吸引力的解决方案。 
