没有合适的资源?快使用搜索试试~ 我知道了~
DB2 最佳实践: 性能调优和问题诊断最佳实践
需积分: 9 11 下载量 53 浏览量
2010-03-17
09:12:21
上传
评论
收藏 109KB DOC 举报
温馨提示
试读
13页
大多数 DB2 系统都经过了性能的演变。首先,不论出于硬件还是软件的观点,该系统首先要能被配置。在多数情况下,这将成为系统在实施后如何运行的基础。其次,系统一经发布,勤勉的数据库管理员(DBA)将监控系统的性能,来监测任何可能的开发问题。如果发现任何问题,我们就进入下一个阶段 - 故障诊断阶段。每个阶段都是基于上一阶段,如果没有适当的准备,我们极有可能需要处理比较困难的问题。 本文介绍了 DB2 系统性能的最优方法。我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。然后我们讨论多种在操作和故障诊断的情况下,有助于我们了解系统性能的监控方法。最后,尽管我们做了最好的准备,性能问题仍然可以降临到我们身上,我们讨论如何逐步地处理它们,并有条不紊的进行
资源推荐
资源详情
资源评论
本系列介绍了 DB2 系统性能的最优方法,分两部分。第一部分首先介绍为了达到良好性能,我们如何从
软硬件配置方面来保障,紧接着讨论了在多种在操作和故障诊断的情况下,有助于我们了解系统性能的监
控方法。第 2 部分 我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。
内容提要
大多数 DB2 系统都经过了性能的演变。首先,不论出于硬件还是软件的观点,该系统首先要能被配置。
在多数情况下,这将成为系统在实施后如何运行的基础。其次,系统一经发布,勤勉的数据库管理员
(DBA)将监控系统的性能,来监测任何可能的开发问题。如果发现任何问题,我们就进入下一个阶段 -
故障诊断阶段。每个阶段都是基于上一阶段,如果没有适当的准备,我们极有可能需要处理比较困难的问
题。
本文介绍了 DB2 系统性能的最优方法。我首先涉及到一些有助于我们确保良好软硬件性能的重要原则。
然后我们讨论多种在操作和故障诊断的情况下,有助于我们了解系统性能的监控方法。最后,尽管我们做
了最好的准备,性能问题仍然可以降临到我们身上,我们讨论如何逐步地处理它们,并有条不紊的进行。
回页首
简介
任何形式的性能问题都将严重影响并降低一个系统对你组织的价值、削弱业务能力、服务中断、以及增加
管理开销。所有这些都会提升总的拥有成本。缺乏对系统配置的基本原则,监视和性能故障诊断可能导致
不同程度的性能低下,并且降低对于组织的价值。
因此,在前期花些时间去考虑基本的配置指导方针和建立健全的系统监控这样的做法,将使你对处理许多
可能出现的典型性能问题,有充分的准备。并使数据服务器得以高性能运行,以提高投资回报率。
回页首
第一步:从配置上实现性能良好
像 InfoSphere 平衡的仓库(BW)这类的 DB2 部署类型,或者那些在 SAP 系统之内的系统,配置都是
高度确定的。在 BW 案例中,像 CPU 个数、内存对 CPU 的比率、硬盘的个数和配置这样的硬件因素,
以及在预先指定版本的基础上,详尽的测试,以确定最优配置。在 SAP 的案例中,硬件配置并不是精确
指定的,不过却有许多可用的配置样本。此外, SAP 最佳实践对 DB2 的配置提供了建议值。如果您正
在使用它们其中之一的 DB2 系统的话,那么这些系统都提供了经过良好测试的配置指南。你通常应该利
用它们对于更普通的经验法则的优势。
我们来考虑一个建议系统,这个系统不同于 BW,我们并没有有一个详细的硬件配置。虽然深入研究系统
配置已经超出了本文的范畴,但是这儿有一些基本的配置指南只需要我们花时间去理解和应用。我们的目
的是找出几个能让系统拥有良好性能的关键配置决定。
硬件配置
对于系统性能,CPU 的能力是在配置中一个主要的独立变量。因为所有其它的硬件配置向来取决于它,
很难预测完成一个特定工作量需要的 CPU 能力。在商务智能(BI)环境下,我们可以合理地估算出每个
处理器内核 200-300GB 的原始数据。对于其它的环境,一个健全的做法是基于一个或者多个 DB2 系统
估算总的 CPU 需求。例如一个新系统需要处理 50% 的用户,每个用户运行的 SQL 的复杂度类似一个现
有系统,可以合理地假设需要增加超过 50% 的 CPU 能力。同样,要预测 CPU 使用的其它因素改变,如
不同的吞吐量要求,更多或更少的触发器或者参考完整性,等… 都应该被考虑到。
一旦我们对 CPU 需求有了很好的认识,就能利用已有信息进行开发,硬件配置的其它方面也会开始整理
就绪。显然我们必须考虑到该系统的所需的磁盘容量在千兆字节或 TB,最重要的因素就在 I / O 的每秒
( IOPS)的性能,或以兆字节每秒的数据传输。实际上,这取决于涉及多少个单独的磁盘。
这是为什么呢?虽然 CPU 的发展在过去十年在速度上有了惊人的增长,然而磁盘的发展却更多的在它们
的能力和成本上。虽然在磁盘搜索时间和传输率上已经有了提高,但是仍然无法更上 CPU 的速度。因此
为了达到现代的系统总体性能需求,使用多个磁盘比之前任何时候都要重要,尤其是对于那些需要驱动繁
重随机磁盘 I/O 的系统。很多时候,诱惑来自于使用最低的磁盘数目来存放所有数据的系统,然而这通常
会导致非常差的性能。
在使用 RAID 存储的情况,或者单个可选址驱动,凭经验估计合理的配置是最少 10 到 20 个磁盘每个处
理器内核。对于存储服务器,有一个类似的推荐值,不过有一点需要额外的小心。存储服务器在分配空间
的时候更着眼于而容量非吞吐量。了解数据库存储的物理布局,对于确保不会出现逻辑分开的存储由于疏
忽发生物理重叠的现像来说,是一个非常好的主意。例如,对于一个 4-way 的系统应来说,该有 8 组每
组 8 个驱动。然而,如果 8 组共享同样的 8 个底层驱动,配置的吞吐量将受到非常严重的降低。参见
<insert storage BP paper reference here> 和 <insert physical database design BP paper
reference here>
更多信息请参见存储配置最佳实践。
为 DB2 事务日志分配专门的非共享的磁盘是很好的实践。这因为日志的 I/O 特性与 DB2 容器有很大的
不同。日志 I/O 与其它类型的 I/O 的竞争能导致日志成为一个瓶颈,尤其是那些有大量行写入行为的系统。
通常, 一对 RAID-1 磁盘能够提供应每秒高达 400 个的事务合理的写负载提供日志吞吐量。如果有更大
的吞吐率,或更大量的日志(例如,大批插入)就需要更大的日志吞吐量,这可以通过在 RAID-10 配置
中添加硬盘来提供,并通过一个写入高速缓存磁盘控制器连接到系统中。下面的故障诊断章节会讲述如果
发生日志瓶颈怎么办。
由于 CPU 和磁盘有效的操作在不同的时间尺度(纳秒 VS 微秒)我们需要分离它们以获得合理的性能。
这就是内存来发挥的作用。在一个数据库系统中,内存的主要作用是避免 I/O,归结为一点,拥有更多内
存的系统能工作得更好。幸运的是,在过去几年中内存的成本已经有了显著的下降,并且系统拥有几十到
上百 GB 的内存已经不在罕见了。通常,对于大多数应用程序每个处理器内核拥有 4 到 8GB 内存是比较
合适的。
AIX 配置
为了达到比较好的性能,有一些相关参数需要调整。我们是假定 AIX 系统是 5.3 或者更高版本来给的这
些建议。此外如果在你的系统中已经有了一些特定的设置(如,一个 BW 或者 SAP 配置),那么它们提
供的设置将比下面的通用指南有更高的优先级。
VMO 参数 LRU_FILE_REPAGE 应该被设成 0 。这个参数是控制是否牺牲计算页或文件系统
缓存页。另外,minperm 应该被设为 3 。 这两个参数值是 AIX6.1 里面默认值。
AIO 参数的 maxservers 默认值可以不再是每个 CPU 10 个。系统一旦激活 maxservers 就
调整如下
1. 收集 ps – elfk | grep aio 的输出并且判断是否所有的异步 I/O(AIO)核心进程
(aioservers)消耗同样数量的 CPU 时间。
2. 如果是,maxservers 可能太少了。增加 10% 的 maxservers 然后重复第一步。
3. 如果有些 aioservers 较其它的要使用更少的 CPU 时间,那么至少当前系统拥有它所
需要的数目。如果多于 10% 的 aioservers 使用较少的 CPU 时间就降低 10% 的
maxservers 并重复第一步。
AIO 参数 maxreqs 应该被设置成 MAX(NUM_IOCLEANERS x 256, 4096). 这个参数控制
绝大多数突出的 AIO 请求。
Hdisk 参数 queue_depth 应该基于这个队列的物理硬盘数目。例如,对于 IBM 磁盘
queue_depth 的默认值是 3 并建议这个值是 3 xnumber-of-devices。这个控制参数可排队
的磁盘请求。
硬盘适配器参数 num_cmd_elems 应该被设为所有连接到这个适配器的设备 queue_depth
的总和。
Solaris 和 HP-UX 的配置
对于在 Solaris 或 HP-UX 上运行的 DB2,根据系统的大小,利用 db2osconf 工具来检测和推荐内核参
数。 db2osconf 允许你基于内存和 CPU 指定核心参数,或与一般缩放系数来比较现有系统配置和未来
期望的配置。一个好的方法是使用缩放系数 2 或者更高的缩放系数来运行大型系统如 SAP 应用程序。通
常情况下,db2osconf 向你提供了好的起点来配置 Solaris 和 HP-UX,但是由于它无法考虑到现在或者
未来的工作负载,它不能带来优化后的值。
Linux 配置
当一个 Linux 系统被用作 DB2 服务器时,可能不得不修改一些 Linux 的一些内核参数。因为 Linux 的
发行变化和这个系统的高度灵活性,我们将只讨论一些基于 linux 实施中需要确认的最重要的设置。
SHMMAX(一个共享内存的最大值)在一个 64 位系统必须至少设为 1G - 1073741824,反之
SHMALL 参数必须设置数据库服务器的 90% 可用内存。SHMALL 默认值是 8GB 。其它重要的 Linux
内核配置参数以及它们对 DB2 的推荐值是:
kernel.sem(指定内核旗语的设置 -SEMMSL, SEMMNS, SEMOPM, and SEMMNI): 250
256000 32
kernel.msgmni(消息队列的标识数):1024
kernel.msgmax(一个消息的最大大小,字节):65536
kernel.msgmnb(消息队列的默认大小,字节):65536
DB2 数据分区特性
使用 DB2 数据分区特性(DPF),通常并不是纯粹由数据容量决定,而更多的是工作负载的性质。大多
数 DPF 部署在数据仓库和商业智能上是一个常规的指导方针。对于大型的复杂查询环境 DPF 是被高度推
荐的,因为它的 share-nothing 架构提供了优异的可扩展性。对于小一些的不大可能快速增长的数据集
市(达到 300GB),一个 DB2 企业服务器版本(ESE)配置是一个很好的选择。然而大型的或快速增
长的 BI 环境将从 DPF 中获利。
虽然处理一个完整 DPF 系统设计已经超出了这篇文章的范畴,但是一个 CPU 到分区的基本描述还算简
单。一个典型的分区系统通常每个分区拥有一个处理器内核。例如,一个有 N 个处理器内核的系统可能
剩余12页未读,继续阅读
资源评论
iguohao
- 粉丝: 200
- 资源: 269
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功