文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

如何使用DB2 UDB的电子商务OLTP应用程序进行性能优化

2024-04-02 19:55

关注

这篇文章给大家分享的是有关如何使用DB2 UDB的电子商务OLTP应用程序进行性能优化的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。

  一、 监视开关

  确保已经打开监视开关。如果它们没有打开,您将无法获取您需要的性能信息。要打开该监视开关,请发出以下命令:

  db2 "update monitor switches using

  lock ON sort ON bufferpool ON uow ON

  table ON statement ON"

  二、代理程序

  确保有足够的 DB2 代理程序来处理工作负载。要找出代理程序的信息,请发出命令:

  db2 "get snapshot for database manager"

  并查找以下行:

  High water mark for agents registered = 7

  High water mark for agents waiting for a token = 0

  Agents registered= 7

  Agents waiting for a token= 0

  Idle agents= 5

  Agents assigned from pool= 158

  Agents created from empty Pool = 7

  Agents stolen from another application= 0

  High water mark for coordinating agents= 7

  Max agents overflow= 0

  如 果您发现Agents waiting for a token或Agents stolen from another application不为 0,那么请增加对数据库管理器可用的代理程序数(MAXAGENTS 和/或 MAX_COORDAGENTS取适用者)。

  三、最大打开的文件数

  DB2 在操作系统资源的约束下尽量做一个“优秀公民”。它的一个“优秀公民”的行动就是给在任何时刻打开文件的最大数设置一个上限。数据库配置参数 MAXFILOP约束 DB2 能够同时打开的文件最大数量。当打开的文件数达到此数量时,DB2 将开始不断地关闭和打开它的表空间文件(包括裸设备)。不断地打开和关闭文件减缓了 SQL 响应时间并耗费了 CPU 周期。要查明 DB2 是否正在关闭文件,请发出以下命令:

  db2 "get snapshot for database on DBNAME"

  并查找以下的行:

  Database files closed = 0

  如果上述参数的值不为 0,那么增加MAXFILOP的值直到不断打开和关闭文件的状态停埂。

  db2 "update db cfg for DBNAME using MAXFILOP N"

  四、锁

  LOCKTIMEOUT 的缺省值是 -1,这意味着将没有锁超时(对 OLTP 应用程序,这种情况可能会是灾难性的)。尽管如此,我还是经常发现许多 DB2 用户用LOCKTIMEOUT= -1。将LOCKTIMEOUT设置为很短的时间值,例如 10 或 15 秒。在锁上等待过长时间会在锁上产生雪崩效应。

  首先,用以下命令检查LOCKTIMEOUT的值:

  db2 "get db cfg for DBNAME"

  并查找包含以下文本的行:

  Lock timeout (sec) (LOCKTIMEOUT) = -1

  如果值是 -1,考虑使用以下命令将它更改为 15 秒(一定要首先询问应用程序开发者或您的供应商以确保应用程序能够处理锁超时):

  db2 "update db cfg for DBNAME using LOCKTIMEOUT 15"

  您同时应该监视锁等待的数量、锁等待时间和正在使用锁列表内存(lock list memory)的量。请发出以下命令:

  db2 "get snapshot for database on DBNAME"

  查找以下行:

  Locks held currently= 0

  Lock waits= 0

  Time database waited on locks (ms)= 0

  Lock list memory in use (Bytes)= 576

  Deadlocks detected= 0

  Lock escalations= 0

  Exclusive lock escalations= 0

  Agents currently waiting on locks= 0

  Lock Timeouts= 0

  如果Lock list memory in use (Bytes)超过所定义LOCKLIST大小的 50%,那么在LOCKLIST数据库配置中增加 4k 页的数量。

  怎么使用 DB2 UDB 的电子商务 OLTP 应用程序进行性能优化

  五、临时表空间

  为了改善 DB2 执行并行 I/O 和提高使用TEMPSPACE的排序、散列连接(hash join)和其它数据库操作的性能,临时表空间至少应该在三个不同的磁盘驱动器上拥有三个容器。

  要想知道您的临时表空间具有多少容器,请发出以下命令:

  db2 "list tablespaces show detail"

  查找与以下示例类似的TEMPSPACE表空间定义:

  Tablespace ID= 1

  Name= TEMPSPACE1

  Type= System managed space

  Contents= Temporary data

  State= 0x0000

  Detailed explanation: Normal

  Total pages= 1

  Useable pages= 1

  Used pages= 1

  Free pages= Not applicable

  High water mark (pages)= Not applicable

  Page size (bytes)= 4096

  Extent size (pages)= 32

  Prefetch size (pages)= 96

  Number of containers= 3

  注意Number of containers的值是 3,而且Prefetch size是Extent size的三倍。为了得到最佳的并行 I/O 性能,重要的是Prefetch size为Extent size的倍数。这个倍数应该等于容器的个数。

  要查找容器的定义,请发出以下命令:

  db2 "list tablespace containers for 1 show detail"

  指的是tablespace ID #1,它是刚才所给出的示例中的TEMPSPACE1。

  六、内存排序

  OLTP 应用程序不应该执行大的排序。它们在 CPU、I/O 和所用时间方面的成本极高,而且将使任何 OLTP 应用程序慢下来。因此,256 个 4K 页(1MB)的缺省SORTHEAP大小(1MB)应该是足够了。您也应该知道排序溢出的数量和每个事务的排序数。

  请发出以下命令:

  Db2 "get snapshot for database on DBNAME"

  并查找以下行:

  Total sort heap allocated= 0

  2 Total sorts = 1

  3 Total sort time (ms)= 8

  4 Sort overflows = 0

  5 Active sorts = 0

  6 Commit statements attempted = 3

  7 Rollback statements attempted = 0

  8 Let transactions = Commit statements attempted + Rollback

  9 statements attempted

  10 Let SortsPerTX= Total sorts / transactions

  11 Let PercentSortOverflows = Sort overflows * 100 / Total sorts

  如 果PercentSortOverflows ((Sort overflows * 100) / Total sorts )大于 3 个百分点,那么在应用程序 SQL 中会出现严重的或意外的排序问题。因为正是溢出的存在表明发生了大的排序,所以理想的情况是发现没有排序溢出或至少其百分比小于一个百分点。

  如果出现过多的排序溢出,那么“应急”解决方案是增加SORTHEAP的大小。然而,这样做只是掩盖了真实的性能问题。相反,您应该确定引起排序的 SQL 并更改该 SQL、索引或群集来避免或减少排序开销。

  如 果SortsPerTX大于 5 (作为一种经验之谈),那么每个事务的排序数可能很大。虽然某些应用程序事务执行许多小的组合排序(它们不会溢出并且执行时间很短),但是它消耗了过多的 CPU。当SortsPerTX很大时,按我的经验,这些机器通常会受到 CPU 的限制。确定引起排序的 SQL 并改进存取方案(通过索引、群集或更改 SQL)对提高事务吞吐率是极为重要的。

  七、表访问

  对于每个表,确定 DB2 为每个事务读取的行数。您必须发出两个命令:

  1 db2 "get snapshot for database on DBNAME"

  2 db2 "get snapshot for tables on DBNAME"

  在发出第一个命令以后,确定发生了多少个事务(通过取Commit statements attempted和Rollback statements attempted之和 - 请参阅 技巧 3)。

  在 发出第二个命令以后,将读取的行数除以事务数(RowsPerTX)。在每个事务中,OLTP 应用程序通常应该从每个表读取 1 到 20 行。如果您发现对每个事务有成百上千的行正被读取,那么发生了扫描操作,也许需要创建索引。(有时以分布和详细的索引来运行 runstats 也可提供了一个解决的办法。)

  “get snapshot for tables on DBNAME”的样本输出如下:

  Snapshot timestamp = 09-25-2000

  4:47:09.970811

  Database name= DGIDB

  Database path= /fs/inst1/inst1/NODE0000/SQL00001/

  Input database alias= DGIDB

  Number of accessed tables= 8

  Table List

  Table Schema= INST1

  Table Name= DGI_

  SALES_ LOGS_TB

  Table Type= User

  Rows Written= 0

  Rows Read= 98857

  Overflows= 0

  Page Reorgs= 0

  Overflows 的数量很大就可能意味着您需要重组表。当由于更改了行的宽度从而 DB2 必须在一个不够理想的页上定位一个行时就会发生溢出。

感谢各位的阅读!关于“如何使用DB2 UDB的电子商务OLTP应用程序进行性能优化”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯