一、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提供的缓冲机制来进行文件系统缓冲。建议在具体设定的环境中对这些方案进行直接比较。