Db2由于取sequence 的 next value 导致的性能问题案例分析

环境：

DB2 v9.5.0.7（虽然版本比较低，但问题性质具有普遍性）

Linux

问题现象：

Db2系统遇到性能问题，每隔固定的间隔（两小时），Db2中几乎所有的应用都会HANG住，持续时间为1~3分钟，之后恢复正常，出问题期间观察到大量的latch现象。

数据抓取：

这是一个数据库整体的性能问题，而非单条SQL语句，由于持续时间比较长(1~3分钟)，有足够的时间抓取数据，收集了两次下面的轻量数据:

$ db2 get snapshot for applications on SAMPLE >> app.snap.out

$ db2pd -latch >> latch.out

$ db2pd -stack all

由于操作系统层面的CPU/内存/IO都正常，所以没有抓取操作系统层面的数据。

数据分析：

/*以下数据中的敏感信息均已经过处理*/
1. db2pd -latch 显示大量的latch wait on SQLO_LT_SQLD_CHAIN__fastChainLatch 和 SQLO_LT_SQLD_SEQ__seqLatch，这俩latch都和sequence相关，只有latch waiter，没有holer:

latches：

Database Partition 0 -- Active -- Up 135 days 12:12:12 -- Date 09/25/2017 08:00:00

Latches:

Address Holder Waiter Filename LOC LatchType

No latch holders.

0x00002AAFC2C3FD00 0 38 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FD00 0 333 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FD00 0 442 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FD00 0 434 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FD00 0 448 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2F072E8 0 466 sqldsequence.C 388 SQLO_LT_SQLD_SEQ__seqLatch

0x00002AAFC2C3FD00 0 589 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FD00 0 592 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FC80 0 8022 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

0x00002AAFC2C3FC80 0 8537 sqldsequence.C 375 SQLO_LT_SQLD_CHAIN__fastChainLatch

..<略>..

2. 查看wait latch的应用的stack，显示的也卡在是取sequence的next value函数上(SeqGenerate, SeqNextval):

XXX.YY.000.stack.txt

<StackTrace>

...

0x0000003532ABB5A7 __sched_yield + 0x0007

(/lib64/libc.so.6)

0x00002AAAABF85F55 sqloSpinLockConflict + 0x0159

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAADE27F19 address: 0x00002AAAADE27F19 ; dladdress: 0x00002AAAAAAC4000 ; offset in lib: 0x0000000003363F19 ;

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAC576441 address: 0x00002AAAAC576441 ; dladdress: 0x00002AAAAAAC4000 ; offset in lib: 0x0000000001AB2441 ;

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAC578FD6 _Z15sqldSeqGenerateP8sqeAgentP8SQLD_SEQ + 0x00a4

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAD62B79B _Z15sqlriSeqNextvalP8sqlrr_cb + 0x0213

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

...

</StackTrace>

XXX.ZZ.000.stack.txt：

0x00002AAAABF85F55 sqloSpinLockConflict + 0x0159

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAADE27F19 address: 0x00002AAAADE27F19 ; dladdress: 0x00002AAAAAAC4000 ; offset in lib: 0x0000000003363F19 ;

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAC5764FF address: 0x00002AAAAC5764FF ; dladdress: 0x00002AAAAAAC4000 ; offset in lib: 0x0000000001AB24FF ;

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAC578FD6 _Z15sqldSeqGenerateP8sqeAgentP8SQLD_SEQ + 0x00a4

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

0x00002AAAAD62B79B _Z15sqlriSeqNextvalP8sqlrr_cb + 0x0213

(/opt/ibm/db2/V9.5/lib64/libdb2e.so.1)

3. db2pd_eve.log显示了应用正在执行的语句，大部分(483个中的459个)确实是在取sequence Next VALUE，主要集中在 NPQ_ZYY_SEQ 和 QUYSeq 上:

qingsong@db2a:~$ grep -i "Statement :" db2pd_eve.log | wc -l

483

qingsong@db2a:~$ grep -i "Statement :" db2pd_eve.log | grep "VALUES NEXTVAL" | wc -l

459

qingsong@db2a:~$ grep -i "Statement :" db2pd_eve.log -A 1| grep -v '^--' | tr -s '\n' | more

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR QUYSeq

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

..

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : insert into

empINFO(id,name, ..

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR QUYSeq

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR QUYSeq

Statement : VALUES NEXTVAL FOR QUYSeq

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

Statement : VALUES NEXTVAL FOR

NPQ_ZYY_SEQ

..<略>..

4. 综上，问题的原因在于取sequence nextval 时出的问题，之前有处理类似问题的经验，原来的sequence cache是400，并且是order的。改为1000，no order之后，没有明显缓解。把sequence cache增加到5000之后，问题得以解决。

解决方案：

sequence本来就是no order的了，将sequence cache从1000调整到5000之后，问题解决。

补充：对于整体的性能问题而言，如果有latch现象，很多情况下都可以通过分析latch和stack找到问题的根源。如果没有latch现象，一般处理的方式可以先看系统资源，比如CPU/IO/内存。再看lock/缓冲池命中率，需要抓出来执行时间较长的SQL/看时间花到什么地方了，可以借助DB2TOP/MON_CURRENT_SQL/MON_GET_PKG_CACHE_STMT等工具和表函数。

http://blog.csdn.net/qingsong3333/article/details/53104171