DB2 最佳实践: 性能调优和问题诊断最佳实践，第 1 部分
正在加载中...
资料简介：
性能调优从配置和监控开始
PDF文档下载见附件
级别： 初级
developerWorks 中国网站编辑团队, 编辑, IBM
原文地址：http://www.ibm.com/developerwork ... les/dm-0903perfbp1/
本系列介绍了 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 个底层驱动，配置的吞吐量将受到非常严重的降低。参见 和
更多信息请参见存储配置最佳实践。
为 DB2 事务日志分配专门的非共享的磁盘是很好的实践。这因为日志的 I/O 特性与 DB2 容器有很大的不同。日志 I/O 与其它类型的 I/O 的竞争能导致日志成为一个瓶颈，尤其是那些有大量行写入行为的系统。
通常， 一对 RAID-1 磁盘能够提供应每秒高达 400 个的事务合理的写负载提供日志吞吐量。如果有更大的吞吐率，或更大量的日志（例如，大批插入）就需要更大的日志吞吐量，这可以通过在 RAID-10 配置中添加硬盘来提供，并通过一个写入高速缓存磁盘控制器连接到系统中。下面的故障诊断章节会讲述如果发生日志瓶颈怎么办。
由于 CPU 和磁盘有效的操作在不同的时间尺度（纳秒 VS 微秒）我们需要分离它们以获得合理的性能。这就是内存来发挥的作用。在一个数据库系统中，内存的主要作用是避免 I/O，归结为一点，拥有更多内存的系统能工作得更好。幸运的是，在过去几年中内存的成本已经有了显著的下降，并且系统拥有几十到上百 GB 的内存已经不在罕见了。通常，对于大多数应用程序每个处理器内核拥有 4 到 8GB 内存是比较合适的。
原文地址：http://www.ibm.com/developerwork ... les/dm-0903perfbp1/
PDF文档下载见附件 [ 本帖最后由 蓝皮猪猪 于 2009-4-24 11:04 编辑 ]
PDF文档下载见附件
级别： 初级
developerWorks 中国网站编辑团队, 编辑, IBM
原文地址：http://www.ibm.com/developerwork ... les/dm-0903perfbp1/
本系列介绍了 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 个底层驱动，配置的吞吐量将受到非常严重的降低。参见
更多信息请参见存储配置最佳实践。
为 DB2 事务日志分配专门的非共享的磁盘是很好的实践。这因为日志的 I/O 特性与 DB2 容器有很大的不同。日志 I/O 与其它类型的 I/O 的竞争能导致日志成为一个瓶颈，尤其是那些有大量行写入行为的系统。
通常， 一对 RAID-1 磁盘能够提供应每秒高达 400 个的事务合理的写负载提供日志吞吐量。如果有更大的吞吐率，或更大量的日志（例如，大批插入）就需要更大的日志吞吐量，这可以通过在 RAID-10 配置中添加硬盘来提供，并通过一个写入高速缓存磁盘控制器连接到系统中。下面的故障诊断章节会讲述如果发生日志瓶颈怎么办。
由于 CPU 和磁盘有效的操作在不同的时间尺度（纳秒 VS 微秒）我们需要分离它们以获得合理的性能。这就是内存来发挥的作用。在一个数据库系统中，内存的主要作用是避免 I/O，归结为一点，拥有更多内存的系统能工作得更好。幸运的是，在过去几年中内存的成本已经有了显著的下降，并且系统拥有几十到上百 GB 的内存已经不在罕见了。通常，对于大多数应用程序每个处理器内核拥有 4 到 8GB 内存是比较合适的。
原文地址：http://www.ibm.com/developerwork ... les/dm-0903perfbp1/
PDF文档下载见附件 [ 本帖最后由 蓝皮猪猪 于 2009-4-24 11:04 编辑 ]
2009-04-24
页数11
浏览8678
下载178
已下载用户的评价7.47分
您还未下载该资料，不能发表评价；
查看我的 待评价资源
查看我的 待评价资源