软件开发aix系统运维Db2

aix一直磁盘100%繁忙?

AIX磁盘一直100%disk100.png目录情况$ lspvhdisk0 00cb36a169514959 rootvg activehdisk1 00cb36a11a470b12 rootvg activehdisk2 none None ...显示全部

AIX磁盘一直100%
disk100.png

disk100.png

目录情况
$ lspv
hdisk0 00cb36a169514959 rootvg active
hdisk1 00cb36a11a470b12 rootvg active
hdisk2 none None
hdisk3 none None
hdisk4 00cb36b14a6226e3 db2vg
hdisk5 00cb36b14a6f4558 appfilevg active
hdisk6 00cb36a105af9ed3 appfilevg active
hdisk7 00cb36a157e9b7ea None
hdisk8 00cb3651fe38d85f None
hdisk10 00cb36a109c23641 db2vgtmp active
$ lsvg -l db2vgtmp
db2vgtmp:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
db2lvtmp jfs2 598 598 1 open/syncd /db2data
db2lvtmp_log jfs2log 1 1 1 open/syncd N/A
$ lslv db2lvtmp
LOGICAL VOLUME: db2lvtmp VOLUME GROUP: db2vgtmp
LV IDENTIFIER: 00cb36a100004c000000015d09c416e6.1 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 2048 PP SIZE: 512 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 598 PPs: 598
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: maximum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 32
MOUNT POINT: /db2data LABEL: /db2data
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO
$

通过fuser看到
$
$ fuser -c /db2data
/db2data: 303712
$ ps -ef|grep 303712

root 327692 303712   0   Sep 22      - 42:06 db2ckpwd 0 
root 373130 303712   0   Sep 22      - 42:05 db2ckpwd 0 

db2inst1 397716 291556 0 15:46:59 pts/3 0:00 grep 303712
db2inst1 303712 148228 107 Sep 22 - 11901:37 db2sysc 0

root  74686 303712   0   Sep 22      - 42:25 db2ckpwd 0 

$

是因为 db2sysc进程导致的,
该怎么往下查呢?

收起
参与33

查看其它 5 个回答topzgm的回答

topzgmtopzgm  软件架构设计师 , People's Bank of China

以上信息表明进程ID=303712对逻辑卷db2vgtmp产生了大量读操作。
建议如下操作:
1)topas看看PgspIn、PgspOut等是否持续高?
2)topas看看CPU Wait%等是否持续高?
3)db2top -d xxx看看哪些表在进行大量read/write?
根据以上操作来判断是否内存资源小导致频繁磁盘交换,还是每个SQL的access plan存在问题导致持续的read/write IO。

根据问题反馈,基本可以判断为“某个或者某些SQL慢”导致繁忙的I/O从而CPU Wait较大。进一步处理方法建议为:
1)使用db2top或者db2 snapshot找到问题SQL。
2)使用db2expln或者db2exfmt对定位的问题SQL进行抽取access plan。
3)分析其access plan,看看是否存在table scan还是nested loop join。
4)最后优化问题SQL。

银行 · 2017-11-15
浏览5245
王磊磊 邀答
  • 303712,就是db2sysc进程,应该是数据库在做大量的读取;PgspIn、PgspOut有数值,但是不太大;CPU Wait%一直在70%左右;db2top 不能执行;内存换页空间使用了20%,我猜可能是某些sql效率慢导致的恶性循环,不知道该怎么下手了
    2017-11-15
  • 重启
    2017-11-17
  • topzgm  topzgm回复 wade666
    基本可以判断为“某个或者某些SQL慢”导致繁忙的I/O从而CPU Wait较大。进一步处理方法建议为: 1)使用db2top或者db2 snapshot找到问题SQL。 2)使用db2expln或者db2exfmt对定位的问题SQL进行抽取access plan。 3)分析其access plan,看看是否存在table scan还是nested loop join。 4)最后优化问题SQL。
    2017-11-17

回答者

topzgm
topzgm0112
软件架构设计师People's Bank of China
擅长领域: 数据库服务器存储

topzgm 最近回答过的问题

回答状态

  • 发布时间:2017-11-15
  • 关注会员:8 人
  • 回答浏览:5245
  • X社区推广