数据库服务器的性能调优

1、I/O调优

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

2、队列长度与响应时间

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

3、负载平衡

    Linux系统提供了多个工具来断定数据库系统是否须要负载平衡。完成这项工做的一种简单方法是使用 iostat。
    下面给出了 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的速度不会受到基准测试其余方面的影响。

4、全局内存

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

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

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

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工做负荷中)。要确保控制这些区域的数据库参数被置为最大值(除以数据库代理的数目)，同时仍不超过系统的内存(包括内核)范围。

5、 日志设备
    当其余全部瓶颈都被解决后，对日志记录设备的优化每每将最终决定 OLTP数据库的性能。尽可能将日志文件与全部其余数据库文件加以分离是很重要的。
    下一步应决定使用原始设备仍是文件系统设备来运行日志文件。历史上，原始设备对于支持数据库来讲是首选的日志记录设备。有些数据库使用了直接 I/O文件系统，其性能能够达到原始设备的 5%。 另外一些(一般为非商用的)数据库则利用 Linux提供的缓冲机制来进行文件系统缓冲。建议在具体设定的环境中对这些方案进行直接比较。