一、I/O调优

在进行 I/O调优时必须做出许多决策。是否使用原始设备或文件系统？是否使用直接 I/O？应该为数据库选取多大的块尺寸? 如果正在严格地执行在线事务处理(其特征为小型的随机读/写操作)工作负荷， 则应该选择较小的块尺寸如 2KB。 对于 DSS中长期运行的查询操作而言，在实现了复杂的查询优化器以及复杂的内存(分类/散列区域)参数控制的数据库中， 更大的块尺寸会提高数据库扫描速度， 例如 8KB(如果数据库支持， 或者可选更大尺寸)。在工作负荷同时包含 OLTP 和 DSS的情况下该如何处理？这时需要对数据库参数的调优加以仔细考虑。 在某些情况下有必要做出折中选择， 也许4KB的块大小比较合适。

二、队列长度与响应时间

在Linux系统中， vmstat是很好的 I/O带宽测量工具。该工具的“ I/O section” 结果中bi和bo两列原本分别表示输入到块设备以及从块设备中输出的块数，如vmstat的man帮助命令所述。然而，在各种 Linux发行版本中这些列实际上以 KBps为单位报告字符设备或块设备(文件系统)在测量期间的传输率。对于这两种工作负荷，如果队列长度大于 1， 则存在着某种冲突的可能性。 对于 OLTP来说， 超过 50ms的响应时间是需要解决的问题。

三、负载平衡

Linux系统提供了多个工具来判定数据库系统是否需要负载平衡。完成这项工作的一种简单方法是使用 iostat。

下面给出了 iostat –x的输出示例：

如果未使用软件分条(striping)能力，则应该确保数据库中全部的表都均匀地分布到所有磁盘上。在该基准测试的这个只读操作部分中，磁盘 sdi实际上正在执行写操作，因为日志显然保存在该磁盘上。日志应该位于单独的带卷(stripe volume)上，在可能的情况下甚至位于单独的磁盘上，以便磁盘 sdi的速度不会受到基准测试其他方面的影响。

需要C/C++ Linux服务器架构师学习资料私信“资料”（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

四、全局内存

对于 OLTP工作负荷来说，通常应该利用数据库的全局缓存将尽可能多的 I/O操作移至内存中。多数数据库都提供了工具来查看用户事务是否被缓存，包括关于脏(dirty)缓冲区和已用缓冲区的统计数据。在 Oracle 中若要适当估测内存，需要设置参数database_block_ buffers。这只需确定数据库专用的空闲内存量，然后将该值除以database_block_size即可，如下所示：

4GB内存中为数据库分配 2.5GB，因此 database_block_buffers取值为 2684354560 /4096= 655360

下面给出一个 db_block_buffers公式的示例：

依赖于主关键字索引查询的 OLTP/WEB工作负荷受益于通过大型缓冲池来缓存结果并减少I/O子系统的I/O吞吐率(每秒的I/O工作量)瓶颈。DSS工作负荷常常需要执行大型表扫描操作并返回众多表格行结果。 针对这类工作负荷， 通过为大量sort和join操作分配内存，可以避免在临时磁盘空间上发生会损害高I/O带宽/吞吐率(MBps)的溢出现象。这通过配置 hash和 sort尺寸这些数据库参数来完成。这些工作负荷的全局缓存容量不必很大——可以比 OLTP工作负荷所需的全局缓存小多个数量级。

下面给出一个使用 vmstat来确定空闲内存和已用内存的示例， 随后对各个相关列加以描述。注意该例中包含vmstat在正常情况下可返回的多个数据列。

free 列以千字节为单位显示。 如果仍存在着可用的空闲内存， 那么这可能并不是制约资源。swpd 列以千字节为单位显示，报告所用的虚存量或被换出到磁盘上的内存量。si 列给出在报告期间从磁盘上换入的内存量。so 列给出在报告期间换出到磁盘(虚存)上的内存量。

如果swpd值较大并且从 si 和 so列中可发现大量交换活动，则可能需要添加更多内存或减少为数据库分配的内存量，从而为应用程序保留更多内存。要确保存在着可分配给数据库的内存。另外，这还假定了Linux中已经考虑到锁定数据库的全局缓存区域。

也可以使用 Linux的 top命令来获得关于占用内存较多的进程的更详细信息。在运行 top命令时输入 h，可以得到选项列表；输入 m可根据常驻内存使用情况进行排序，从而确定哪些进程消耗的内存最多。 Linux的/usr/bin/top工具比 vmstat具有更大的干扰，也占用更多 CPU时间。因此首先应使用 vmstat，在需要额外信息时再使用 top工具。

应记住， 在 32位 Linux系统上， 内存容量可能会超出数据库软件的寻址能力。 在这种情况下， 如果出现 I/O问题， 应该寻找新型的空闲内存使用方式。 为了减少 I/O操作，应尽量使用内存。在某些情况下， 可以利用数据库的临时空间区域， 尤其对于使用了 sort或 hash区域的具体进程(典型存在于 DSS工作负荷中)。要确保控制这些区域的数据库参数被置为最大值(除以数据库代理的数目)，同时仍不超过系统的内存(包括内核)范围。

五、 日志设备

当其他所有瓶颈都被解决后，对日志记录设备的优化往往将最终决定 OLTP数据库的性能。尽量将日志文件与所有其他数据库文件加以分离是很重要的。

下一步应决定使用原始设备还是文件系统设备来运行日志文件。历史上，原始设备对于支持数据库来说是首选的日志记录设备。有些数据库使用了直接 I/O文件系统，其性能可以达到原始设备的 5%。 另一些(通常为非商用的)数据库则利用 Linux提供的缓冲机制来进行文件系统缓冲。建议在具体设定的环境中对这些方案进行直接比较。