背景描述:某日,在秒杀场景下,某系统出现大量的活动连接数堆积。查看当时的app快照,活动连接数为:1700多个分析快照得到如下结果:Total_Connections: 2020 Total_Active_Connections: 17921506 653131681 223486 5995551 0 1474013 0 20664955 0 MPUSER 34bfd0cf04d6d2e6看到SQL:34bfd0cf04d6d2e6 堆积了1506个,而且是Executing状态。SQLMD5:34bfd0cf04d6d2e6 的SQL语句执行了接近10分钟没有完成,但是用的CPU时间和逻辑读很少(没有物理读)。因此时间肯定是花费在等待上。从执行状态和指标:Total time UOW waited on locks (ms) = 0可以看出时间并没有花费在锁等待上,因此有可能是花费在latch上。根据获取的latch信息可以看到有大量的Memlatch:请问我们如何避免MemLatch等待,有什么优化建议或者经验分享。
附件:
log.txt (16.39 KB)
看检查情况来看,是很多app在等待数据库的latch锁‘SQLO_LT_SMemPool__MemLatchType__latch’从字面上来看是在等待分配内部内存空间。要检查是什么导致了大量应用在等待这个latch锁,可以执行db2pd -stack all来获取数据库app的函数调用情况,通过检查这些app的函数调用来确定哪些app占用了latch,哪些app在等待latch.数据库等待latch的情况很多,也比较复杂,不是一时半会可能看情况的,需要根据检查数据来一步一步找出原因。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30