Db2由于取sequence 的 next value 导致的性能问题案例分析
来源:互联网 发布:博士论文数据造假 编辑:程序博客网 时间:2024/05/18 15:50
环境:
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
阅读全文
0 0
- Db2由于取sequence 的 next value 导致的性能问题案例分析
- 由于程序栈 导致GDB退出问题的分析
- DB2问题诊断与解决: 一个由于历史文件过大,导致LOAD慢的问题
- Spring取Sequence的下一个value
- DB2的性能问题
- 由于JDK版本问题导致的错误
- 由于ADT升级后导致的问题
- 一个由于位数导致的问题
- 由于图片链接问题导致Web性能的严重的下降(转贴)
- 由于图片链接问题导致Web性能的严重的下降(转贴)
- 由于图片链接问题导致Web性能的严重的下降(转贴)
- 一个rac问题分析过程由于进程资源不足导致的问题
- Db2性能:操作系统CPU高问题分析的一些思路
- 频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- 频繁分配释放内存导致的性能问题的分析
- JSP基础知识(AJax)
- #leetcode编程日记#554. Brick Wall
- C++输入正整数n, 输出将1~n*n顺时针排列矩阵之数组
- 136. Single Number
- SDUT 1252 进制转换
- Db2由于取sequence 的 next value 导致的性能问题案例分析
- [LeetCode-Algorithms-42] "Trapping Rain Water" (2017.9.28-WEEK4)
- 编程思想之多线程与多进程(1)——以操作系统的角度述说线程与进程
- Linux SWAP 交换分区配置说明
- 测试
- The 2014 ACM-ICPC Asia Shanghai Regional Contest
- qt显示视频大小和位置
- JSP基础知识(设计模式)
- kotlin 委托