共计 2363 个字符，预计需要花费 6 分钟才能阅读完成。
一、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 服务器架构师学习材料加群 812855908（材料包含 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 提供的缓冲机制来进行文件系统缓冲。倡议在具体设定的环境中对这些计划进行间接比拟。