数据库服务器的性能调优

一、I/O调优

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


二、队列长度与响应时间

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


三、负载平衡
    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的速度不会受到基准测试其他方面的影响。


四、全局内存
    对于 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工作负荷常常需要执行大型表扫描操作并返回众多表格行结果。 针对这类工作负荷, 通过为大量sortjoin操作分配内存,可以避免在临时磁盘空间上发生会损害高I/O带宽/吞吐率(MBps)的溢出现象。这通过配置 hashsort尺寸这些数据库参数来完成。这些工作负荷的全局缓存容量不必很大——可以比 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中已经考虑到锁定数据库的全局缓存区域。

    也可以使用 Linuxtop命令来获得关于占用内存较多的进程的更详细信息。在运行 top命令时输入 h,可以得到选项列表;输入 m可根据常驻内存使用情况进行排序,从而确定哪些进程消耗的内存最多。 Linux/usr/bin/top工具比 vmstat具有更大的干扰,也占用更多 CPU时间。因此首先应使用 vmstat,在需要额外信息时再使用 top工具。
    应记住, 在
32Linux系统上, 内存容量可能会超出数据库软件的寻址能力。 在这种情况下, 如果出现 I/O问题, 应该寻找新型的空闲内存使用方式。 为了减少 I/O操作,应尽量使用内存。在某些情况下, 可以利用数据库的临时空间区域, 尤其对于使用了 sorthash区域的具体进程(典型存在于 DSS工作负荷中)。要确保控制这些区域的数据库参数被置为最大值(除以数据库代理的数目),同时仍不超过系统的内存(包括内核)范围。


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

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

发布了303 篇原创文章 · 获赞 25 · 访问量 124万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览