文档介绍：莈DB2最佳实践:性能调优和问题诊断最佳实践袇本系列介绍了DB2系统性能的最优方法,分两部分。第1部分首先介绍为了达到良好性能,我们如何从软硬件配置方面来保障,紧接着讨论了在多种在操作和故障诊断的情况下,有助于我们了解系统性能的监控方法。第2部分我们介绍在出现性能问题时如何逐步地、有条不紊地去处理它们。螄概述袃就算是配置最仔细的系统也终究会发现它仍然需要一定的性能调优,并且这时我们已经搜集了的运行监控数据,将来非常便于搜集。蒁保持一种系统的方法来调优和进行故障诊断对我们非常重要。当发生了一个问题,为了解决这个问题,很容易随意的进行调整。然而,当我们这么做了,事实上定位到问题的可能性非常低,甚至让问题更糟糕。性能调优的一些基本原则:袆有备而来,去了解系统一切正常的情况下性能怎么样。搜集运行监视信息来跟踪一段时间内系统行为的变化。膅了解整个场景,不要局限于你从DB2上看到的–也要搜集并分析来自于操作系统、存储、应用程序甚至来自用户的数据。了解系统本身将有助于你解释监控数据。芁只调整能解释你看到的症状的参数,如果连发动机都无法启动就不要更换轮胎。不要试图通过降低CPU来解决磁盘的瓶颈。膀一次只改一个参数,在更改其它参数之前先观察效果。羆你可能遇到的问题类型薆性能问题往往分为两大类:影响了整个系统的问题和只影响了部分系统的问题。比如某一特定应用或SQL语句,在研究的过程中-种类型的问题可能转化为另外一种类型的问题,或者相反。例如造成整个系统性能降低可能是一个单独的语句,或者是整个系统的问题只是在一个特定的区域被发现。羃下面我们从整个系统的问题开始。罿我们发现的所有导致性能降低的原因的方法就是从高层入手并逐渐提炼我们的诊断。这个“判断树”策略可以帮助我们尽可能早的排除那些不能解释我们所看到症状的因素,适用于整个系统或者更加局部的问题。我们将把瓶颈分成下面4种普通类型:肆磁盘蚃CPU蒁内存螈‘懒惰系统’膆在开始一个对DB2调查之前,首先考虑一些准备问题常常是有帮助的,比如:肄是否有性能降低,与什么相关?我们的‘基准’是什么?膃一个系统的性能看起来在随时间流逝下降了?与一个不同的系统或不同的应用比较下降了?这个问题可以对性能降低的原因展开不同的可能性。数据量增加了?所有的硬件都运行正常吗?螁性能下降是什么时候发生的?在另一个任务运行之前、之中、之后,性能下降或许周会期性的发生。甚至如果这个任务没有直接和数据库相关,它也可能由于消耗网络或者CPU资源影响数据库性能。芆性能下降的前后关系有什么变化吗?通常是,添加了新硬件、或应用程序被更改了、大量数据被加载、或者更多的用户访问这个系统。蒅在据库专家和应用程序以及架构方面的专家一起工作的情况下,这些问题通常是一个综合分析方法一个很重要的部分。DB2服务器几乎总是硬件、其它中间件、和应用程序这样一个复杂环境的一部分,所以解决问题可能需要有多领域的技能。蚀蕿莆袅莂回页首芈蒆芆磁盘瓶颈螀SystemBottleneck>DiskBottleneck?莁磁盘瓶颈的基本症状是:蒆在vmstat或iostat结果中出现较高的I/O等待时间。这显示系统会花费一小段时间等待磁盘I/O完成请求。等待时间达到20%或25%是很少见的。如果CPU时间非常低,那么高I/O等待时间是一个很好的预示了瓶颈所在。蒃从iostat或perfmon显示磁盘高达80%的繁忙程度。薂从vmstat输出中看到较低的CPU利用率(25%-50%)膀可能最终我们可能需要添加磁盘,但现在我们将检查我们是否能通过调优DB2系统消除这个瓶颈。薅如果存在一个磁盘瓶颈,系统管理员可以帮忙映射一个繁忙设备镜像的文件系统路径。从这里你可以决定DB2如何使用这些受到影响的路径:袄瓶颈是表空间容器?,TBSP_ID和CONTAINER_NAME的结果,查看造成瓶颈的路径是否在CONTAINER_NAME结果中。芄瓶颈是事务日志路径?这取决于检查数据库配置参数的结果,查看造成瓶颈的路径是否是“日志文件路径”。衿作为诊断日志路径?这取决于检查数据库管理配置参数的结果,查看造成瓶颈的路径是否是DIAG_PATH。蚅我们将分别考虑这几种情况。芅SystemBottleneck>ContainerDiskBottleneck>HotDataContainer>HotTable?蚂为了判断是什么导致容器成为瓶颈的,我们需要判断都有哪些表存储在这那个表空间而且最活跃。蚈要判断什么表在这个表空间,,,,选择在我们繁忙的容器上的表