Question & Answer
Question
psmon3的输出报告内容不少，用户怎样能快速从报告找到性能问题所在？
Cause
文章《一个很好用的性能分析脚本--psmon3.sql》简单介绍了性能分析脚本psmon3.sql的使用方法，这篇文章将带你走进psmon3的分析报告，介绍一些快速从报告找出有用信息的小窍门。
Answer
总的来说，报告从"REPORT STARTS HERE"开始，包含了两大部分内容：
- 脚本监控（即执行）阶段开始和结束时搜集的实时数据，比如说当时正在运行的SQL，正在执行的utilities（比如load,backup）, 也比如当时的锁等待信息。
- 脚本监控阶段的累积数据
- 这些数据被分到不同层级：数据库层，表空间层，bufferpool层，表层，SQL层，连接层，等等。
- 当前数据库实例的架构分类：DB2 ESE， pureScale, BD2 BLU, 等等。
- 环境信息，比如说：数据库实例配置，数据库配置，注册变量配置，CPU数量及使用情况，内存使用情况。
1) 在报告的稍微前面（搜索"Throughput metrics at database level"可以找到这段输出）, 你可以看到数据库层级的吞吐量，这个报告有助于确认当前系统是否在处理合理且可接受范围内的工作:
上面的报告里面可以看出该系统有4个member, 每个的吞吐量大概是2400 个transaction每秒， 25000个SQL每秒，整个监控时间长度是35秒。注意脚本默认监控时长是30秒，这里监控脚本身搜集数据花了大概5秒，这延长了实际的监控时长。
2) 下面的报告（搜索"Time breakdown at database level"可以找到这段输出）展示了数据库层级所花时间的分布，告诉你多少时间花在编译SQL, 多少时间花在提交或者回滚transactions.
上面的报告中，你可以看到大部分时间都花在执行sections上（PCT_SECTION 包含SQL的执行时间和等待时间）， 其余的时间大部分都花在提交上。系统看起来很正常。
小窍门：如果OLTP系统上发现太多时间（比如说〉15%）花在编译SQL上（即PCT_COMPILE），那么很有可能是应用那边没有使用一次prepare多次execute, 没有使用parameter markers，而是在向数据发送大量的拼接SQLs.
3) 那么是否有太多时间花在等待上，有多少时间花在等待上？等待什么？ 这些信息往往对判断系统是否存在可调优空间很重要。 搜索"Wait times at database level" 可以找到下面的报告：
上面报告可以看出整体有大概70%的时间花在等待上(PCT_RQST_WAIT), 这其中包含一部分等写日志((PCT_LG_DST)和等锁上，但是这些都不重要，最显著的等待是是花在CF通信上(PCT_CF)。 注意，实际报告中其实还会显示很多其它的等待，但是贴到这里太长了展示不好看，所以该文章只摘出了其中一部分值得关注的列。
4) 检查了数据库层级的等待时间分布之后，有必要再观查下SQL层级的等待分布了。psmon3.sql脚本从package cache获取SQL数据，所以这里的SQL是在脚本的监控（执行）时间区间内运行并结束了的SQL，如果你对脚本监控开始或者结束时正在执行的SQL感兴趣，你可以查看实时数据报告部分，搜" Point-in-time"可以找到。
报告根据总消耗时间按从大到小排列选出前100个SQL， 然后针对这些SQL列出不同着重点的报告，着重点比如等待时间，IO，排序等。
如果3)中已经发现了数据库层级在某方面的等待时间很突出，那么很有必要看看SQL层级的等待时间分布报告，这样可以确定数据库层级的大量等待时间是否是由某个或者某一些特定的SQL导致的，还是说是系统层级（比如不合理的配置）的问题。
小窍门：其中有一个报告列出了前100个SQL的executable_id，有了executable_id，你可以根据它的值查询mon_get_pkg_cache_stmt获取更深入的信息，也可以获取感兴趣SQL的执行计划：
db2 -tvf $HOME/sqllib/misc/explain.ddl
db2 "call explain_from_section(x'<executable id>','M',NULL,0,'<current user>',?,?,?,?,?)"
小窍门：另外一个报告列的是按PLANID汇总的数据（搜索"Top SQL statements by execution time, aggregated by PLANID"），就是把所有基本相同只是某些“参数值”（literal value）不同的SQL（这些SQL拥有相同的PLANID）看作一个SQL，然后列出他们各方面的成本。当应用发出大量这样的相似只是“参数值”（literal value）不同的SQL时，这个报告很有用。这个报告只有在V10.5或者更新版本数据库上才有。
下面这个报告列出了top SQL的 buffer pool IO信息：
小窍门：你可以根据上面的IO相关报告评估对应SQL是否使用了索引。AVG_I_LRD 是平均每次执行的索引逻辑读数量。 注意上面前四行，是同一个SQL在不同的4个member上的数据，AVG_I_LRD比较高，而且AVG_D_LRD（即平均每次执行的数据逻辑读数量）为0， 这说明该SQL的执行计划使用了索引。如果某个SQL消耗时间多，数据逻辑读数量大而索引逻辑读数量小，那么或许你有必要优化一下这个SQL，使得执行计划倾向于使用索引？
5) 一些有问题的SQL根据上面的报告可能很容易就指引出比如加索引或者调整执行计划等解决方法，有一些SQL可能就不是那么容易了。这时候就有必要跳过数据库或者SQL层级的等待时间数据，继续看看其它报告了。
这里有必要指出， 报告里的每个等待时间百分比（比如PCT_LG_DSK，即日志的磁盘等待时间百分比）是除以总消耗时间的百分比，而不是除以总等待时间的百分比。
较高的日志磁盘等待时间（PCT_LG_DSK）在OLTP系统很常见。如果你发现这种现象，就有必要检查下日志的写时间：
上面的0.4豪秒是不错的值，实际上我们要找的有问题的日志读时间往往是10倍于这个值 - 即4毫秒。 当然上面的例子不可能发现日志写的问题，因为前面的报告就没有发现PCT_LG_DSK高的现象。
高缓冲池读时间（PCT_POOL_R）也是常发现的性能瓶颈，尤其是当系统刚启动还没有‘热’起来的时候（warming up阶段）。如果发现PCT_POOL_R高的情况，就有必要检查bufferpool层级和表空间层级的平均缓冲池读时间（AVG_READ_TIME）。同样的，较高的直接IO时间（PCT_DIR_R 和 PCT_DIR_W，针对大对象数据）情况下，可以进一步查看AVG_DRCT_READ_TIME和AVG_DRCT_WRITE_TIME。
如果你发现较高的CF等待时间（PCT_CF），那么下面的报告（还有其它几个该文档没列出的报告）细化了CF各命令的数据，比如说各命令的执行次数，每次消耗的时间：
如果你发现较高的reclaim等待时间（PCT_RCLM），比如达到5%或者10%， 下面的报告可以告诉你哪些表存在reclaim的问题，是表数据的reclaim，还是其索引的reclaim:
上面图中例子显示出表ORDERS等索引的reclaim比较多，但是数据不算太难看，之前数据库层级的reclaim等待时间（PCT_RCLM）也不高嘛。
小窍门： 较高的索引reclaim比较常见，可以通过使用RANDOM索引优化，方法还有：CURRENT MEMBER列分区，分区表等。
SMP数据的高reclaim往往由于高并发的插入操作同时表空间的extent size较小，比如下面的例子：
高百分比（〉15-20%）的latch等待时间（PCT_LTCH）会导致很多问题。下面的例子展示了latch等待的细分信息：
当然，上面的例子没有看出特别显著的latch问题。解决显著的latch等待问题，或许需要DB2技术支持解决，但是这篇文章也给出了几个小窍门。
小窍门：在pureScale系统中，latch等待往往和page reclaim有很大关联性。 2~5%的reclaim等待往往会导致20~40的latch等待。所以，建议你在深入分析latch等待前，先分析reclaim等待，特别是当你发现某个/些SQL的同时有较高的latch等待和reclaim等待。 当然，这里说的只限于pureScale环境。
小窍门：在DB2 V11.1上，对latch机制有很多改进。当你发现latch SQLB_HASH_BUCKET_GROUP_HEADER的竞争比较激烈时，或许可以考虑升级到V11.1。
小窍门： SQLB_BPD__bpdLatch是我们常说的hot page相关的latch。我们可以首先找到该latch等待主要发生的SQL，然后找到对应的表。 常用的解决办法是使用分区表和分区索引。
Related Information
[{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Performance - General\/Tuning","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}],"Version":"9.7;10.1;10.5;11.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg22000397