银行
生产系统cpu100%
最近公司一个业务系统oltp类型的，在12月31日下午发生了几次cpu 100%故障
每次都是靠重启应用来释放系统资源
系统资源：aix5.3 7c（power6） 20g
db2 9.1
数据库在磁盘阵列上
从系统资源的使用情况来看，user部分的cpu占用接近100%，在短短的3-5分钟内从10%以下冲上100%
用topas观察到没有特别消耗cpu资源的进程，但是有大量占用百分之1点几cpu的db2sysc进程，
其实就是db2的agent进程有很多
查看db2diag日志也没有发现锁升级，死锁现象
对application做快照，看到的一些dyn sql也都是平常的业务sql，并没有什么特殊的
同时间的内存和磁盘繁忙率都很正常
之后将应用和db都重启了，并降低了一些应用的并发数，过了三天了还没有什么异常，
猜测一：业务繁忙，并发的连接多了导致
但是应用采用缓冲池和数据库连接，最大200，业务再忙，到数据库的连接始终不会高于200
猜测二：发生了很多全表扫描和排序
但是从快照中的sql语句来看，表的记录数量不大，走的也是索引，也没多少排序
求解！或者再出现时我该遵循什么样的方法去收集数据，分析问题？
望不吝赐教!
每次都是靠重启应用来释放系统资源
系统资源：aix5.3 7c（power6） 20g
db2 9.1
数据库在磁盘阵列上
从系统资源的使用情况来看，user部分的cpu占用接近100%，在短短的3-5分钟内从10%以下冲上100%
用topas观察到没有特别消耗cpu资源的进程，但是有大量占用百分之1点几cpu的db2sysc进程，
其实就是db2的agent进程有很多
查看db2diag日志也没有发现锁升级，死锁现象
对application做快照，看到的一些dyn sql也都是平常的业务sql，并没有什么特殊的
同时间的内存和磁盘繁忙率都很正常
之后将应用和db都重启了，并降低了一些应用的并发数，过了三天了还没有什么异常，
猜测一：业务繁忙，并发的连接多了导致
但是应用采用缓冲池和数据库连接，最大200，业务再忙，到数据库的连接始终不会高于200
猜测二：发生了很多全表扫描和排序
但是从快照中的sql语句来看，表的记录数量不大，走的也是索引，也没多少排序
求解！或者再出现时我该遵循什么样的方法去收集数据，分析问题？
望不吝赐教!
18同行回答
感谢各位的回复：
从application的快照里面，的确可以看到uow的执行时间非常长，sql执行也消耗了很多的cpu时间。但我觉得这是因为cpu已经100%了，每个进程都拿不到足够的cpu时间导致的。
目前我们只能寄希望于压力测试能不能够找到引起异常的原因了。收起
从application的快照里面，的确可以看到uow的执行时间非常长，sql执行也消耗了很多的cpu时间。但我觉得这是因为cpu已经100%了，每个进程都拿不到足够的cpu时间导致的。
目前我们只能寄希望于压力测试能不能够找到引起异常的原因了。收起
浏览1413
浏览1469
topas看看是否有显著进程，看看是否是db2sys进程，结合db2mtrk看看当前应用CPU使用在哪块造成，如果确定ppl ...marvelyu 发表于 2013-1-8 18:39
问题发生时的确是db2sys进程有很多，每一个占用1%点几的cpu，但从application的快照来看，并没有lock-wait，只有UOW Execu...问题发生时的确是db2sys进程有很多，每一个占用1%点几的cpu，但从application的快照来看，并没有lock-wait，只有UOW Executing和UOW Waiting的，UOW Executing大概有130个左右收起
浏览1454
topas看看是否有显著进程，看看是否是db2sys进程，结合db2mtrk看看当前应用CPU使用在哪块造成，如果确定pplication的数据量猛增造成，多半是应用，而且很可能是锁问题，及时收集下数据库的运行快照信息，上面的给提到了，如果不是很有规律的话，可以在OS上部署crontab定时采集收起
浏览1456
通过tivoli数据我们发现，在事发的那个时间段application的数据量在200左右，平时这个值只有30-40。这个肯定是异常点。但苦于没收集到足够的数据，不知道为什么会突然变成这么多。收起
浏览1425
抓下相关日志看下或通过性能感觉监控下，到底是那块出现问题，不一定是数据库server的问题收起
浏览1637
这类问题，最主要首先是从OS层面来分析。AIX的话，建议收一个tprof，可能话看看splat收起
浏览1669