数据库服务器的性能调优
一、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的响应时间是需要解决的问题。
下面给出了 iostat –x的输出示例：
[solarflar@localhost ~]$ iostat -x
Linux 3.10.0-327.el7.x86_64 (localhost.localdomain) 2016年10月27日 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.81 0.00 0.11 0.00 0.00 99.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.09 0.00 2.21 0.49 30.38 27.93 0.00 0.33 1.18 0.32 0.03 0.01
dm-0 0.00 0.00 0.00 2.17 0.48 17.98 16.97 0.00 0.08 1.17 0.08 0.03 0.01
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 37.23 0.00 1.17 1.17 0.00 1.01 0.00
dm-2 0.00 0.00 0.00 0.12 0.01 12.40 200.85 0.00 4.67 2.06 4.67 0.08 0.00
[solarflar@localhost ~]$ 如果未使用软件分条(striping)能力，则应该确保数据库中全部的表都均匀地分布到所有磁盘上。在该基准测试的这个只读操作部分中，磁盘 sdi实际上正在执行写操作，因为日志显然保存在该磁盘上。日志应该位于单独的带卷(stripe volume)上，在可能的情况下甚至位于单独的磁盘上，以便磁盘 sdi的速度不会受到基准测试其他方面的影响。4GB内存中为数据库分配 2.5GB，因此 database_block_buffers取值为 2684354560 /4096= 655360
Database heap (4KB) (DBHEAP) = 6654 Size of database shared memory (4KB)(DATABASE_MEMORY) = AUTOMATIC Catalog cache size (4KB) (CATALOGCACHE_SZ) = 386 Log buffer size (4KB) (LOGBUFSZ) = 2048 Utilities heap size (4KB) (UTIL_HEAP_SZ) = 10000 Buffer pool size (pages) (BUFFPAGE) = 40000 Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000 Number of extended storage segments (NUM_ESTORE_SEGS) = 0 Max storage for lock list (4KB) (LOCKLIST) = 16384依赖于主关键字索引查询的 OLTP/WEB工作负荷受益于通过大型缓冲池来缓存结果并减少I/O子系统的I/O吞吐率(每秒的I/O工作量)瓶颈。DSS工作负荷常常需要执行大型表扫描操作并返回众多表格行结果。 针对这类工作负荷， 通过为大量sort和join操作分配内存，可以避免在临时磁盘空间上发生会损害高I/O带宽/吞吐率(MBps)的溢出现象。这通过配置 hash和 sort尺寸这些数据库参数来完成。这些工作负荷的全局缓存容量不必很大——可以比 OLTP工作负荷所需的全局缓存小多个数量级。
下面给出一个使用 vmstat来确定空闲内存和已用内存的示例， 随后对各个相关列加以描述。注意该例中包含vmstat在正常情况下可返回的多个数据列。
[solarflar@localhost ~]$ vmstat 4 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 68455376 13124 53729460 0 0 0 1 0 0 1 0 99 0 0 0 0 0 68455720 13124 53729460 0 0 0 6 70 121 0 0 100 0 0 0 0 0 68455856 13124 53729460 0 0 0 1 79 138 0 0 100 0 0
- 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提供的缓冲机制来进行文件系统缓冲。建议在具体设定的环境中对这些方案进行直接比较。
