Db2性能：操作系统CPU高问题分析的一些思路

最新推荐文章于 2023-11-08 17:30:02 发布

匿_名_用_户

最新推荐文章于 2023-11-08 17:30:02 发布

阅读量3.8k

点赞数

分类专栏： DB2 文章标签： Db2 CPU高

本文链接：https://blog.csdn.net/qingsong3333/article/details/78379911

版权

DB2 专栏收录该内容

181 篇文章 9 订阅

订阅专栏

Db2性能：系统CPU高问题分析的一些思路

1. 如何判断CPU高?

有很多操作系统的命令可以看出来，比如ps -elf，iostat， vmstat, top/topas,

2. 收集数据

CPU高分为usr高和sys高，前者表示系统在执行应用代码，一般需要应用（比如Db2）来查原因。后者表示系统在执行kernal code，一般需要OS工程师协助分析。

A. sys CPU高

如果是%sys CPU高，这意味着系统在执行kernel code，这种情况下需要操作系统工程师一块支持，来从操作系统层面收集数据，例如:

AIX:
1) OS trace -- perfpmr.sh

Solaris:
1) dtrace script

Linux:
1) systemTap 工具
2) 如果能确定是Db2进程导致的，则收集db2sysc进程的strace -c 数据。

Db2:

Db2层面也可以收集一些数据，Db2导致的sys CPU高时，往往伴随着很多的latch，所以建议收集db2pd -latch和db2pd -stack的数据。

B. usr CPU高

如果是%usr CPU高，一般意味着系统正在执行应用的代码，很大可能是Db2执行的SQL语句导致的。需要找到占用CPU较多的SQL语句，看看在执行什么操作：

B1. 可以通过mon_get_pkg_cache_stmt找到占用CPU较多的动态SQL语句
db2 "select TOTAL_CPU_TIME/NUM_EXEC_WITH_METRICS as AVG_CPU_TIME, NUM_EXEC_WITH_METRICS, substr(STMT_TEXT,1,100) as STMT_TEXT from table( mon_get_pkg_cache_stmt (null, null,null,null)) as T where T.NUM_EXEC_WITH_METRICS <> 0 order by AVG_CPU_TIME DESC"

如果是routine占用了较多的CPU，比如存储过程，可以参考下面的链接：
调查routine的高 CPU 占用率
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_10.5.0/com.ibm.db2.luw.admin.mon.doc/doc/t0060667.html

B2. 可以通过db2pd -edus interval=120 来收集120秒之内每个edu占用的CPU时间，结合其他的信息，比如db2pd -eve、application snapshot的输出，来看一下edu对应的应用，以及应用执行的SQL语句是什么，针对这些SQL语句来优化。

SQL语句使用CPU较多的原因，简单说几个
--频繁地扫描环境池中的表、join操作、排序操作都会使用较多的CPU。
--获取锁和释放锁的过程，也要用较多的CPU。

对于如何解决，一般就是调优SQL了，比如通过建立适当的索引来避免表扫描、当需要锁较多时而对并发性要求不高时，直接在整个表上加锁、不需要那么多数据的时候使用fetch first xxx rows only等。这里不做阐述（因为我也不擅长），有兴趣的可以看参考资料。

3. 一个示例

环境: db2 10.5.0.5, suse linux 11

问题：%usr CPU高，大约95%，db2sysc进程使用的最多

数据收集：
在问题出现期间，收集了以下数据：

vmstat 1 10 > vmstat.1
ps -elf > pself.1
ps aux > psaux.1
iostat 1 10 > iostat.1

db2pd -eve > db2pd_eve.out
db2pd -edus interval=120 > db2pd_edu_120.out
db2pd -stack all

db2 GET SNAPSHOT FOR APPLICATIONS ON <db_name> GLOBAL > applications.log
db2 GET SNAPSHOT FOR DATABASE ON <db_name> GLOBAL > DB.log
db2 get snapshot for all on <db_name> > dbsnap

数据分析：

3.1

iostat 输出显示 user CPU 很高.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          89.42    0.01    4.55    1.89    0.00    4.12
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          94.41    0.00    5.59    0.00    0.00    0.00
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          95.42    0.00    4.58    0.00    0.00    0.00
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          94.67    0.00    5.33    0.00    0.00    0.00

3.2

ps aux的输出显示db2sysc进程使用了最多的CPU

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  10540   884 ?        Ss   Oct15   0:01 init [5]  
root         2  0.0  0.0      0     0 ?        S    Oct15   0:00 [kthreadd]
...
root      7065  0.0  0.2 1029412 75296 ?       Sl   Oct15   0:00 db2wdog 0 [db2inst1]                                        
db2inst1  7067 1127 69.2 29760484 22761184 ?   Sl   Oct15 13895:25 db2sysc 0                                      
root      7069  0.0  0.1 1035728 47704 ?       S    Oct15   0:02 db2ckpwd 0                                                  
root      7070  0.0  0.1 1035728 47632 ?       S    Oct15   0:02 db2ckpwd 0                                                  
root      7071  0.0  0.1 1035728 47632 ?       S    Oct15   0:02 db2ckpwd 0                                                  
db2inst1  7079  0.0  0.1 502756 41276 ?        S    Oct15   0:00 db2vend (PD Vendor Process - 1) 0                                                                              
db2inst1  7089  0.0  0.1 592156 33260 ?        Sl   Oct15   0:22 db2acd 0 ,0,0,0,1,0,0,0,0000,1,0,995bc4,14,1e014,2,0,1,41fc0,0x210000000,0x210000000,1600000,c8010,2,128021
...
root     27022 50.0  0.0   4940   972 pts/1    R+   13:59   0:00 ps aux
root     27499  0.0  0.0      0     0 ?        S    12:06   0:00 [kworker/9:0]
patrol   27604  0.0  0.0  11300  1048 ?        Ss   Oct15   0:00 /bin/bash
patrol   27605  0.0  0.0  11300  1052 ?        Ss   Oct15   0:00 /bin/bash
root     28654  0.0  0.0      0     0 ?        S    Oct15   0:01 [kworker/8:1]

3.3

db2pd_edu_120.out 输出按照对EDU按照占用的CPU时间排序

Database Member 0 -- Active -- Up 0 days 21:21:14 -- Date 2017-10-16-14.48.37.897471

List of all EDUs for database member 0

db2sysc PID: 7067
db2wdog PID: 7065
db2acd  PID: 7089

EDU ID    TID                  Kernel TID           EDU Name                               USR (s)         SYS (s)        USR DELTA    SYS DELTA
========================================================================================================================================
110       140354128963328      28988                db2agent (SAMPLE) 0                24280.590000   478.060000   42.250000     1.080000
85        140354313512704      16300                db2agent (SAMPLE) 0                23898.440000   454.140000   40.980000     0.900000
87        140354531616512      16316                db2agent (SAMPLE) 0                23530.870000   446.600000   40.830000     0.850000
122       140353910859520      348                  db2agent (SAMPLE) 0                22660.420000   430.300000   40.600000     1.000000
88        140354514839296      16324                db2agent (SAMPLE) 0                23262.550000   443.450000   40.640000     0.900000
91        140354464507648      16327                db2agent (SAMPLE) 0                22989.210000   438.320000   40.660000     0.880000
114       140354061854464      13529                db2agent (SAMPLE) 0                22994.820000   436.550000   40.540000     0.900000
79        140354900715264      8439                 db2agent (SAMPLE) 0                23656.830000   450.830000   40.540000     0.840000
108       140354162517760      21738                db2agent (SAMPLE) 0                23687.730000   450.920000   40.430000     0.920000
106       140354196072192      21722                db2agent (SAMPLE) 0                23498.360000   445.650000   40.440000     0.900000
119       140353961191168      21841                db2agent (SAMPLE) 0                22711.160000   427.530000   40.450000     0.850000
80        140354883938048      16295                db2agent (SAMPLE) 0                23338.770000   443.420000   40.270000     1.020000
115       140353776641792      15710                db2agent (SAMPLE) 0                22876.610000   435.050000   40.340000     0.920000
111       140354112186112      29588                db2agent (SAMPLE) 0                23423.810000   446.610000   40.340000     0.900000
117       140353994745600      16907                db2agent (SAMPLE) 0                22886.840000   433.260000   40.330000     0.910000
109       140354145740544      28987                db2agent (SAMPLE) 0                23631.250000   450.080000   40.220000     1.010000
84        140354816829184      16299                db2agent (SAMPLE) 0                23291.960000   443.260000   40.250000     0.980000
112       140354095408896      6654                 db2agent (SAMPLE) 0                23276.780000   445.550000   40.270000     0.920000
118       140353977968384      18404                db2agent (SAMPLE) 0                22218.640000   419.450000   39.990000     0.960000
78        140354917492480      8433                 db2agent (SAMPLE) 0                23387.590000   442.670000   39.970000     0.930000
121       140353927636736      23958                db2agent (SAMPLE) 0                22597.700000   427.340000   39.910000     0.970000
116       140354011522816      15711                db2agent (SAMPLE) 0                22962.390000   437.080000   39.990000     0.870000
81        140354867160832      16296                db2agent (SAMPLE) 0                23466.230000   448.500000   39.830000     1.020000
104       140354229626624      19731                db2agent (SAMPLE) 0                23581.980000   450.790000   39.910000     0.920000
123       140353894082304      1767                 db2agent (SAMPLE) 0                22448.450000   423.550000   39.840000     0.930000
113       140354078631680      7525                 db2agent (SAMPLE) 0                22930.950000   437.310000   39.740000     0.870000
124       140353877305088      2185                 db2agent (SAMPLE) 0                22260.260000   423.640000   39.640000     0.910000
...

3.4

这里以EDU ID 110为例子，可以通过db2pd_eve.out找到其执行的SQL语句（这里可能不准确，因为抓取的是当前正在执行的SQL, 推荐结合mon_get_pkg_cache_stmt的输出）

Dynamic SQL Statements:
Address            AnchID StmtUID    NumEnv     NumVar     NumRef
NumExe     Text
...
0x00007FAC67B6C640 740    1          1          1          41         41
select * from TEST1 where KPICODE like '2222|!|!|%' order
by DCTIME desc fetch first 20 rows only with ur
...

3.5

Application SNAPSHOT显示sort、rows read都非常高

            Application Snapshot

Application handle                         = 109
Application status                         = UOW Executing
..
Rows inserted                              = 12335
Rows updated                               = 0
Rows selected                              = 25680
Rows read                                  = 175961810541
Rows written                               = 12335
..
Total sorts                                = 1284
..
Total User CPU Time used by agent (s)      = 24801.492324
Total System CPU Time used by agent (s)    = 0.000000

Agent process/thread ID                    = 110

3.6

剩下的工作是：可以按照相同的方法找到其他占用CPU的SQL，并进行调优。当然，实际上可能并没有这么简单，需要多分析应用的快照，可以看到SQL语句是什么时候开始执行的？执行了多长时间？执行SQL语句之前是什么状态？同一时刻有多少SQL语句在执行？平时有那么多吗？等等，这些都可以从应用的快照中获取。所以应用的快照也是必收数据，而且要多收几次。

http://blog.sina.com.cn/s/blog_60eacf330100dq94.html
https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/potentially_lower_performance_on_aix_with_shared_processors_and_cpu_intensive_applications?lang=en
https://www.ibm.com/developerworks/community/blogs/DB2PerfTips/entry/what_to_do_when_cpu_spikes_up?lang=en
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_9.7.0/com.ibm.db2.luw.admin.trb.doc/doc/t0055242.html
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_9.7.0/com.ibm.db2.luw.admin.trb.doc/doc/t0055243.html
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_10.5.0/com.ibm.db2.luw.sql.rtn.doc/doc/r0055017.html

匿_名_用_户

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
Db2性能：操作系统CPU高问题分析的一些思路

Db2性能：系统CPU高问题分析的一些思路1. 如何判断CPU高?有很多操作系统的命令可以看出来，比如ps -elf，iostat， vmstat, top/topas, 2. 收集数据CPU高分为usr高和sys高，前者表示系统在执行应用代码，一般需要应用（比如Db2）来查原因。后者表示系统在执行kernal code，一般需要OS工程师协助分析。A. sys C
复制链接

扫一扫