因IXAND导致大量MemLatch等待?

背景描述:
某日,在秒杀场景下,某系统出现大量的活动连接数堆积。
查看当时的app快照,活动连接数为:1700多个
分析快照得到如下结果:
Total_Connections:            2020                         
Total_Active_Connections:     1792
1506           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)

参与10

2同行回答

tongshuaitongshuai  数据库工程师 , 北京新数科技有限公司
看检查情况来看,是很多app在等待数据库的latch锁‘SQLO_LT_SMemPool__MemLatchType__latch’从字面上来看是在等待分配内部内存空间。要检查是什么导致了大量应用在等待这个latch锁,可以执行db2pd -stack all来获取数据库app的函数调用情况,通过检查这些app的函数调用来确...显示全部

看检查情况来看,是很多app在等待数据库的latch锁‘SQLO_LT_SMemPool__MemLatchType__latch’
从字面上来看是在等待分配内部内存空间。要检查是什么导致了大量应用在等待这个latch锁,可以执行
db2pd -stack all
来获取数据库app的函数调用情况,通过检查这些app的函数调用来确定哪些app占用了latch,哪些app在等待latch.
数据库等待latch的情况很多,也比较复杂,不是一时半会可能看情况的,需要根据检查数据来一步一步找出原因。

收起
互联网服务 · 2019-09-10
atpeace331atpeace331  数据库管理员 , 银行
您最好把问题时段的 db2diag.log 日志截出来给我们看看,还有等待应用正在执行的 SQL 。从你给的日志判断,有很大可能是 “秒杀” 高并发应用同时发出大批量SQL,导致 stmm自动调节内存管理器分配内存速度过慢无法满足并发SQL的内存需求。具体在分配哪种内存池,应该是共...显示全部

您最好把问题时段的 db2diag.log 日志截出来给我们看看,还有等待应用正在执行的 SQL 。

从你给的日志判断,有很大可能是 “秒杀” 高并发应用同时发出大批量SQL,导致 stmm自动调节内存管理器分配内存速度过慢无法满足并发SQL的内存需求。
具体在分配哪种内存池,应该是共享排序堆,你可以去查看当时的db2diag.log 和 stmm日志去确认是否出现问题,应该会有问题的原因。

建议:将相应的 共享排序堆 初始值调成秒杀时 峰值的 2倍以上,一般 stmm不太适合内存需求变化极大的应用场景。

收起
银行 · 2019-09-10
浏览1899

提问者

liujiacai
其它广州大厦
擅长领域: 数据库云计算服务器

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-09-10
  • 关注会员:3 人
  • 问题浏览:3727
  • 最近回答:2019-09-10
  • X社区推广