没有合适的资源?快使用搜索试试~ 我知道了~
DB2最佳实践性能调优和问题诊断最佳实践.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 122 浏览量
2022-07-13
22:23:48
上传
评论
收藏 1.25MB PDF 举报
温馨提示
试读
36页
DB2最佳实践性能调优和问题诊断最佳实践.pdf
资源推荐
资源详情
资源评论
DB2 最佳实践 : 性能调优和问题诊断最佳实践, 第
1 部分
性能调优从配置和监控开始
2009 年 3 月 12 日
本系列介绍了 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 x number-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 个处理器内核的系统可能
有一个编目分区和 N 个数据分区。如果这个编目分区将被大量使用(例如,拥有单分区维度的表),那
么它最好被分配一个处理器内核。 如果这个系统将支持许多并发活动用户, 就可能每个分区需要两个内核。
作为一个一般性的指南,你应该在每个分区上计划大约 250G 活跃的裸数据。
在 InfoSphere Balanced Warehouse 的文档中有关于 DPF 配置最佳实践的更深入的信息,也包含对
于 non-Balanced Warehouse 部署的有用资料。
代码页的选择和校验
除了影响数据库性能的行为之外,代码页或代码集的选择和比较的顺序也许会对性能造成很大的影响。由
于 Unicode 允许客户在他们的数据库中比传统单字节代码页呈现更多类型的字符串,使得 Unicode 的
使用变得越来越普遍。事实上,它也是 DB2 9.5 的默认值。然而由于 Unicode 代码集使用多字节来呈
现一些单独的字符, 这将增加磁盘占用和内存需求。 如,UTF-8 代码集是一个最常用的 Unicode 代码集,
每个字符使用一到四个字节。一个字符串从单字节代码到 UTF-8 代码集在迁移过程中的扩大因素是非常
难预测的。因为它取决于多字节字符的使用频率。对于典型的北美内容,通常没有扩大。对于大多数西欧
语言,音标字符的使用一般导致 10% 的扩大,但是您的成本会有所不同。
此外,相对于单字节代码页,使用 Unicode 会导致额外的 CPU 开销。首先,如果发生了扩充,越长的
字符串处理工作就越久。其次,也更显著的是,该算法采用更先进的 Unicode 整理序列,如
UCA500R1_NO ,这比系统整理的典型单字节代码要昂贵得多。 而这完全是由于 Unicode 串行排序成文
化正确性的方式的复杂性造成的。操作受到了包括排序,字符串比较, like ()处理以及创建索引的影响。
如果正确显示你的数据 Uincode 是必须的,那么请仔细选择校验顺序
如果数据库需要存储多语言的数据,并且数据正确的排序顺序非常重要,则应该使用一个文化正
确性校验(比如 UCA500R1_xxx )。不过请注意,由于一致性的关系,根据不同的数据和应用
程序这将有 1.5x 到 3x 的性能消耗。
在文化正确性校验中,有规范化和非规范化的不同。规范化校验(如 UCA500R1_NO )有附加
的检查来处理乱码,反之非规范化校验(如 UCA500R1_NX )则不会。除非处理乱码是一个问
题,由于避免编码正常化可以带来性能上的好处,我们建议使用非规范化版本。不过,就算是非
规范化文化校验也是非常昂贵的。
如果一个数据库被从单字节环境迁移到 Unicode 环境,却没有被严格要求支持多种语言(大多
数客户属于这个范畴),明确的语言校验或许比较合适。事实上许多 Unicode 数据库值包含一
种语言,明确的语言校验(如 SYSTEM_819_BE )将会得到好处。它们使用相同的基于校验运
算法则的检查表作为单字节校验,比如 SYSTEM_819 ,非常有效率。作为一个一般的规则,如
果在最初的单字节数据库中的校验行为可以接受,并且语言内容在很长时间内不会改变为
Unicode ,明确的文化校验是可以考虑的。这对于文化正确性校验有非常大的性能好处。
数据库的物理设计
详细的数据库物理设计已经在 Sam 的数据库物理设计文章中很好的覆盖了,但是为了达到我们的意图,
我们将在这里讨论两个最高阶的最佳实践。
通常,数据库管理基于文件存储的普通表空间提供了比系统管理存储普通表空间更好的性能。系
统管理表空间经常使用于临时表空间,尤其是临时表非常小的时候。然而数据库管理表空间的性
能优势缩短了完成的时间。
之前,使用裸设备的数据库管理表空间拥有比使用文件的数据库表空间要好很多的性能优势,但
是随着直接 I/O (现在默认通过通过 CREAT 或者 ALTER TABLESPACE 使用 NO FILE
SYSTEM CACHING 子句)的引入,使用文件的数据库表空间提供了几乎与使用裸设备的数据
库管理表空间相同的性能。
DB2 数据库配置初始设置
数据库配置建议程序,也就是通常所说的 autoconfigure 命令,它根据你提供的系统指南确定一个比较
好的数据库配置参数初始值。 Autoconfigure 的确对默认配置的设置有所改进,也是一个用来获得初始
配置值的推荐方法。根据不同的系统特性,对 autoconfigure 的推荐值进行一些额外的微调是必要的。
使用 autoconfigure 的建议:
虽然从 DB2 9.1 开始会在数据库创建的时候自动运行 autoconfigure ,但是直接运行
autoconfigure 仍是一个不错的主意。因为这样我们可以指定关键字 / 值,这有助于在询问中
自定义系统的结果。
在数据库完成填充后再运行(或重新运行) autoconfig ,将向这个工具提供更多关于数据库本身
的信息。注意这里的 “完成填充 ”的含义是你将可用的活动数据总量 (如,它影响缓冲池大小计算) ,
太多或者太少的数据都将降低计算的精度。
尝试 autoconfigure 的重要关键字如 mem_percent,tpm, 以及 num_stmts ,判断改变哪
些配置值有效,在多大程度上有效。
如果你在试验不同的关键字和值时用了 ” apply none ”选项,这将让你有机会来对推荐值和当前
值进行对比。
对所有关键字指定具体值,因为默认值可能并不适用与你的系统。例如 mempercent 默认值设
置为 25% 这对一个纯 DB2 服务器来说太低了,在这种情况下 85% 是推荐值。
DB2 自调整和自调整参数
DB2 最新版本不论在实例启动还是数据库启动的时候都显著地增加了自动调整或者在操作过程中动态调
整参数的数目。除了那些手动精心调试的系统,这对于大多数系统自动设置会带来最好的性能。这主要归
功于 DB2 的自调整内存管理器( STMM ),它动态调整 DB2 系统中数据库内存总量的分配,如四个主
要的内存消费者:缓冲池, lock list ,包缓存以及排序堆。
因为那些参数都是基本应用于各个分区的, 对于分区环境 STMM 需要注意几点。 在分区环境中 STMM 将
在一个分区上( DB2 自动选择的,但是可以被废除)持续检查内存需求,判断并把堆大小的更新值推向所
有启动了 STMM 的分区。由于所有的分区都使用相同的值, STMM 在各分区的数据总量,内存需求以及
综合活动水平都非常统一的 DPF 环境中工作最佳。如果个别分区有数据倾斜或者有不同的内存需求,
STMM 则应该在那些分区上停用,而在更一致的分区上启用。例如, STMM 通常应该在编目节点上停用。
对于数据分布发生倾斜的 DPF 环境,不推荐进行跨集群的内存调整, STMM 可以在 “调试阶段 ”有选择临
时的使用,以用来帮助确定比较好的手动设置堆大小:
剩余35页未读,继续阅读
资源评论
cjd13107639592
- 粉丝: 0
- 资源: 5万+
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功