机械装备
关于DB2导致系统换页空间不断上涨的问题
题目是我自己想的 我是觉得是数据库的一点小问题导致的 以下将问题详细说明:
系统aix 5.3 数据库db2 V9.1
该系统（假设为系统A）上两个实例（假设为INSTANCE1和INSTANCE2） 其中的一个实例（假设为INSTANCE1）是与另外一个系统的数据库做的HADR
我觉得问题就出在INSTANCE2上
现象：
在系统A上，如果从来不启动实例INSTANCE2（实例INSTANCE1肯定是一直启动的），那么系统的换页空间（lsps -s）肯定是为一个固定的值从来不变的（假设为23%）
以下的问题说明完全是关于INSTANCE2的。
当启动INSTANCE2并激活数据库之后，换页空间使用率会有一定的增长（假如增长到36%），问题就出在这里：即便是INSTANCE2的数据库一直保持很小的数据量处理操作，系统的换页空间还是会缓慢的增长，也许10天半个月会增长1%，总的趋势就是在涨，但一旦将该INSTANCE2停止，那么换页空间可以说永远不会涨（我观察了大半年都不涨）。启动INSTANCE2之后数据库的错误日志的报错信息是：
STMM Sort Memory Tuning cannot be activated because the Database
Manager Configuration Parameter SHEAPTHRES is not set to 0.
此时数据库的自动内存调整参数是OFF；
今天我把INSTANCE2的数据库自动内存调整参数设置为ON，然后数据库错误日志每3分钟会记录一条错误信息，很有规律，具体内容如下：
2012-03-22-14.14.04.955084+480 I352702A439 LEVEL: Warning
PID : 1691740 TID : 1 PROC : db2stmm (DBMES) 0
INSTANCE: devdbadm NODE : 000 DB : DBMES
APPHDL : 0-13 APPID: *LOCAL.devdbadm.120322061104
AUTHID : DEVDBADM
FUNCTION: DB2 UDB, Self tuning memory manager, stmmEnforceMinSizeConstraints, probe:2089
MESSAGE : Unable to find donor to satisfy minSize constraint
我不明白为什么没有启动INSTANCE2时，换页空间从来不涨，启动INSTANCE2后（此时的STMM参数是OFF），在可以说没有数据量操作的情况下分页空间的使用率还是会涨呢？
我不明白为什么我把STMM设置为ON后，在几乎没有数据处理的情况下每3分钟报一次上文所述的错误呢？
请大家给我点帮助，谢谢！
系统aix 5.3 数据库db2 V9.1
该系统（假设为系统A）上两个实例（假设为INSTANCE1和INSTANCE2） 其中的一个实例（假设为INSTANCE1）是与另外一个系统的数据库做的HADR
我觉得问题就出在INSTANCE2上
现象：
在系统A上，如果从来不启动实例INSTANCE2（实例INSTANCE1肯定是一直启动的），那么系统的换页空间（lsps -s）肯定是为一个固定的值从来不变的（假设为23%）
以下的问题说明完全是关于INSTANCE2的。
当启动INSTANCE2并激活数据库之后，换页空间使用率会有一定的增长（假如增长到36%），问题就出在这里：即便是INSTANCE2的数据库一直保持很小的数据量处理操作，系统的换页空间还是会缓慢的增长，也许10天半个月会增长1%，总的趋势就是在涨，但一旦将该INSTANCE2停止，那么换页空间可以说永远不会涨（我观察了大半年都不涨）。启动INSTANCE2之后数据库的错误日志的报错信息是：
STMM Sort Memory Tuning cannot be activated because the Database
Manager Configuration Parameter SHEAPTHRES is not set to 0.
此时数据库的自动内存调整参数是OFF；
今天我把INSTANCE2的数据库自动内存调整参数设置为ON，然后数据库错误日志每3分钟会记录一条错误信息，很有规律，具体内容如下：
2012-03-22-14.14.04.955084+480 I352702A439 LEVEL: Warning
PID : 1691740 TID : 1 PROC : db2stmm (DBMES) 0
INSTANCE: devdbadm NODE : 000 DB : DBMES
APPHDL : 0-13 APPID: *LOCAL.devdbadm.120322061104
AUTHID : DEVDBADM
FUNCTION: DB2 UDB, Self tuning memory manager, stmmEnforceMinSizeConstraints, probe:2089
MESSAGE : Unable to find donor to satisfy minSize constraint
我不明白为什么没有启动INSTANCE2时，换页空间从来不涨，启动INSTANCE2后（此时的STMM参数是OFF），在可以说没有数据量操作的情况下分页空间的使用率还是会涨呢？
我不明白为什么我把STMM设置为ON后，在几乎没有数据处理的情况下每3分钟报一次上文所述的错误呢？
请大家给我点帮助，谢谢！
11 同行回答
stmm显示没有可分配内存，所以无法自动调整，意味着内存不足，试着把测试库的bufferpool调小一些，没什么业务的话，应该不用那么大的bp。我大概计算了一下，两个数据库占了约4.5G内存，还有MQ、应用和OS要消耗内存。 收起
看了你的outputs, 简单的算了你的shared memory usage.
你的shared memory + process memory 一定是 大于了 system RAM, 才导致swap。 收起
你的shared memory + process memory 一定是 大于了 system RAM, 才导致swap。 收起
没找到问题的根本解决办法 我把测试库（INSTANCE2）停了！ 收起
回复 2# drdb2
按照你说的 收集的信息如下：
作为生产库的HADR备机的INSTANCE1的内存使用情况
mesdbadm@byq_sm2:/mesdbadm$db2mtrk -d -i
Tracking Memory on: 2012/03/23 at 12:24:16
Memory for instance
monh other fcmbp
64.0K 20.4M 39.6M
Memory for database: DBMES
utilh pckcacheh catcacheh bph (2) bph (1) bph (S32K) bph (S16K)
64.0K 192.0K 64.0K 3.1G 40.8M 704.0K 448.0K
bph (S8K) bph (S4K) shsorth lockh dbh other appctlh
320.0K 256.0K 0 104.9M 52.5M 256.0K 64.0K
appctlh agsh
320.0K 70.9M
用做测试库的INSTANCE2的内存使用情况
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$db2mtrk -i -d
Tracking Memory on: 2012/03/23 at 12:23:49
Memory for instance
monh other fcmbp
320.0K 20.4M 39.6M
Memory for database: DBMES
utilh pckcacheh catcacheh bph (2) bph (1) bph (S32K) bph (S16K)
64.0K 2.1M 832.0K 797.5M 40.8M 704.0K 448.0K
bph (S8K) bph (S4K) shsorth lockh dbh other appctlh
320.0K 256.0K 0 104.9M 5.2M 256.0K 64.0K
appctlh appctlh appctlh appctlh appctlh appctlh appctlh
64.0K 64.0K 64.0K 64.0K 64.0K 64.0K 64.0K
appctlh agsh
320.0K 63.1M
主机系统上的ipcs -mod输出
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$ipcs -mob
IPC status from /dev/mem as of Fri Mar 23 12:27:40 BEIST 2012
T ID KEY MODE OWNER GROUP NATTCH SEGSZ
Shared Memory:
m 0 0x58001193 --rw-rw-rw- root system 1 134217728
m 1048577 0x40300007 --rw-rw-rw- mqm mqm 121 1000
m 1048578 0xffffffff --rw-rw---- root system 1 65536
m 1048579 0x7800000a --rw-rw-rw- root system 2 16777216
m 4 0x670010a1 --rw-r--r-- root system 3 12
m 5 0x680010a1 --rw-r--r-- root system 3 106548
m 6 0x700010a1 --rw------- root system 3 3168
m 7 0xffffffff --rw-rw---- root haemrm 1 4096
m 8 0x00040037 --rw------- mqm mqm 10 794624
m 9 0x00040044 --rw------- mqm mqm 9 159744
m 10 0x00040045 --rw-rw-rw- mqm mqm 120 268431360
m 11 0x00040048 --rw------- mqm mqm 3 794624
m 12 0x00040030 --rw------- mqm mqm 3 876544
m 13 0x00040031 --rw-rw-rw- mqm mqm 91 3301376
m 14 0x00040033 --rw------- mqm mqm 7 552960
m 15 0x00040034 --rw------- mqm mqm 2 3301376
m 16 0x00040035 --rw-r--r-- mqm mqm 1 794624
m 17 0x00040036 --rw------- mqm mqm 1 8192
m 18 0x00040038 --rw------- mqm mqm 7 8978432
m 19 0x00040039 --rw------- mqm mqm 7 73728
m 20 0x0004003e --rw------- mqm mqm 7 3874816
m 21 0x0004003f --rw------- mqm mqm 7 11497472
m 22 0x00040041 --rw------- mqm mqm 7 7925760
m 23 0x0004004a --rw------- mqm mqm 7 290816
m 24 0x0004004b --rw------- mqm mqm 7 1273856
m 25 0x0004004e --rw------- mqm mqm 1 8192
m 26 0x0004004f --rw-rw-rw- mqm mqm 6 176128
m 27 0x00040050 --rw-rw-rw- mqm mqm 2 1155072
m 28 0x00040051 --rw-rw-rw- mqm mqm 60 331776
m 29 0x00040052 --rw------- mqm mqm 2 4096
m 30 0x00040053 --rw------- mqm mqm 2 3301376
m 31 0x00040054 --rw------- mqm mqm 1 454656
m 32 0x000400b3 --rw-rw-rw- mqm mqm 1 4096
m 33 0x000400b7 --rw-rw-rw- mqm mqm 1 4096
m 34 0x0ecc5474 --rw-rw-rw- mesdbadm mesdbgrp 62 140848008
m 35 0x0ecc5461 --rw------- mesdbadm mesdbgrp 34 64028672
m 36 0xffffffff --rw------- mesfusr mesfgrp 35 245170176
m 37 0x0ecc5462 --rw------- mesdbadm mesdbgrp 33 8589934592
m 1048614 0xffffffff --rw-rw---- root system 1 65536
m 39 0xffffffff --rw------- mesdbadm mesdbgrp 20 8589934592
m 40 0xffffffff --rw------- mesdbadm mesdbgrp 7 212402176
m 41 0x0d000d29 --rw-rw---- root system 4 1440
m 25165866 0x000401a2 --rw------- mqm mqm 6 2539520
m 735051819 0x000401d3 --rw------- mqm mqm 4 1277952
m 6291500 0x20719161 --rw------- devdbadm devdbgrp 32 64028672
m 12582957 0xffffffff --rw------- devfusr devfgrp 33 245170176
m 219152430 0x000401c1 --rw------- mqm mqm 4 638976
m 540016687 0x20719162 --rw------- devdbadm devdbgrp 31 8589934592
m 96469041 0x000401c9 --rw------- mqm mqm 4 319488
m 1048576050 0xffffffff --rw------- devdbadm devdbgrp 18 8589934592
m 697303091 0x00040196 --rw------- mqm mqm 3 163840
m 24117300 0xffffffff --rw------- devdbadm devdbgrp 2 131072
m 506462261 0x20719174 --rw-rw-rw- devdbadm devdbgrp 34 140848008
m 441450550 0xffffffff --rw------- devdbadm devdbgrp 8 189267968
m 828375095 0xffffffff --rw------- devdbadm devdbgrp 2 131072
物理内存
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$lsattr -El mem0
goodsize 7744 Amount of usable physical memory in Mbytes False
size 7744 Total amount of physical memory in Mbytes False 收起
按照你说的 收集的信息如下：
作为生产库的HADR备机的INSTANCE1的内存使用情况
mesdbadm@byq_sm2:/mesdbadm$db2mtrk -d -i
Tracking Memory on: 2012/03/23 at 12:24:16
Memory for instance
monh other fcmbp
64.0K 20.4M 39.6M
Memory for database: DBMES
utilh pckcacheh catcacheh bph (2) bph (1) bph (S32K) bph (S16K)
64.0K 192.0K 64.0K 3.1G 40.8M 704.0K 448.0K
bph (S8K) bph (S4K) shsorth lockh dbh other appctlh
320.0K 256.0K 0 104.9M 52.5M 256.0K 64.0K
appctlh agsh
320.0K 70.9M
用做测试库的INSTANCE2的内存使用情况
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$db2mtrk -i -d
Tracking Memory on: 2012/03/23 at 12:23:49
Memory for instance
monh other fcmbp
320.0K 20.4M 39.6M
Memory for database: DBMES
utilh pckcacheh catcacheh bph (2) bph (1) bph (S32K) bph (S16K)
64.0K 2.1M 832.0K 797.5M 40.8M 704.0K 448.0K
bph (S8K) bph (S4K) shsorth lockh dbh other appctlh
320.0K 256.0K 0 104.9M 5.2M 256.0K 64.0K
appctlh appctlh appctlh appctlh appctlh appctlh appctlh
64.0K 64.0K 64.0K 64.0K 64.0K 64.0K 64.0K
appctlh agsh
320.0K 63.1M
主机系统上的ipcs -mod输出
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$ipcs -mob
IPC status from /dev/mem as of Fri Mar 23 12:27:40 BEIST 2012
T ID KEY MODE OWNER GROUP NATTCH SEGSZ
Shared Memory:
m 0 0x58001193 --rw-rw-rw- root system 1 134217728
m 1048577 0x40300007 --rw-rw-rw- mqm mqm 121 1000
m 1048578 0xffffffff --rw-rw---- root system 1 65536
m 1048579 0x7800000a --rw-rw-rw- root system 2 16777216
m 4 0x670010a1 --rw-r--r-- root system 3 12
m 5 0x680010a1 --rw-r--r-- root system 3 106548
m 6 0x700010a1 --rw------- root system 3 3168
m 7 0xffffffff --rw-rw---- root haemrm 1 4096
m 8 0x00040037 --rw------- mqm mqm 10 794624
m 9 0x00040044 --rw------- mqm mqm 9 159744
m 10 0x00040045 --rw-rw-rw- mqm mqm 120 268431360
m 11 0x00040048 --rw------- mqm mqm 3 794624
m 12 0x00040030 --rw------- mqm mqm 3 876544
m 13 0x00040031 --rw-rw-rw- mqm mqm 91 3301376
m 14 0x00040033 --rw------- mqm mqm 7 552960
m 15 0x00040034 --rw------- mqm mqm 2 3301376
m 16 0x00040035 --rw-r--r-- mqm mqm 1 794624
m 17 0x00040036 --rw------- mqm mqm 1 8192
m 18 0x00040038 --rw------- mqm mqm 7 8978432
m 19 0x00040039 --rw------- mqm mqm 7 73728
m 20 0x0004003e --rw------- mqm mqm 7 3874816
m 21 0x0004003f --rw------- mqm mqm 7 11497472
m 22 0x00040041 --rw------- mqm mqm 7 7925760
m 23 0x0004004a --rw------- mqm mqm 7 290816
m 24 0x0004004b --rw------- mqm mqm 7 1273856
m 25 0x0004004e --rw------- mqm mqm 1 8192
m 26 0x0004004f --rw-rw-rw- mqm mqm 6 176128
m 27 0x00040050 --rw-rw-rw- mqm mqm 2 1155072
m 28 0x00040051 --rw-rw-rw- mqm mqm 60 331776
m 29 0x00040052 --rw------- mqm mqm 2 4096
m 30 0x00040053 --rw------- mqm mqm 2 3301376
m 31 0x00040054 --rw------- mqm mqm 1 454656
m 32 0x000400b3 --rw-rw-rw- mqm mqm 1 4096
m 33 0x000400b7 --rw-rw-rw- mqm mqm 1 4096
m 34 0x0ecc5474 --rw-rw-rw- mesdbadm mesdbgrp 62 140848008
m 35 0x0ecc5461 --rw------- mesdbadm mesdbgrp 34 64028672
m 36 0xffffffff --rw------- mesfusr mesfgrp 35 245170176
m 37 0x0ecc5462 --rw------- mesdbadm mesdbgrp 33 8589934592
m 1048614 0xffffffff --rw-rw---- root system 1 65536
m 39 0xffffffff --rw------- mesdbadm mesdbgrp 20 8589934592
m 40 0xffffffff --rw------- mesdbadm mesdbgrp 7 212402176
m 41 0x0d000d29 --rw-rw---- root system 4 1440
m 25165866 0x000401a2 --rw------- mqm mqm 6 2539520
m 735051819 0x000401d3 --rw------- mqm mqm 4 1277952
m 6291500 0x20719161 --rw------- devdbadm devdbgrp 32 64028672
m 12582957 0xffffffff --rw------- devfusr devfgrp 33 245170176
m 219152430 0x000401c1 --rw------- mqm mqm 4 638976
m 540016687 0x20719162 --rw------- devdbadm devdbgrp 31 8589934592
m 96469041 0x000401c9 --rw------- mqm mqm 4 319488
m 1048576050 0xffffffff --rw------- devdbadm devdbgrp 18 8589934592
m 697303091 0x00040196 --rw------- mqm mqm 3 163840
m 24117300 0xffffffff --rw------- devdbadm devdbgrp 2 131072
m 506462261 0x20719174 --rw-rw-rw- devdbadm devdbgrp 34 140848008
m 441450550 0xffffffff --rw------- devdbadm devdbgrp 8 189267968
m 828375095 0xffffffff --rw------- devdbadm devdbgrp 2 131072
物理内存
devdbadm@byq_sm2:/devdbadm/sqllib/db2dump$lsattr -El mem0
goodsize 7744 Amount of usable physical memory in Mbytes False
size 7744 Total amount of physical memory in Mbytes False 收起
1.你的Instance2用作HADR，从你的描述中看到，Primary和Standby在同一台机器，磁盘是否独立？各个磁盘的页交换空间是独立的。
2.“问题就出在这里：即便是INSTANCE2的数据库一直保持很小的数据量处理操作，系统的换页空间还是会缓慢的增长”，你说的INSTANCE2一直保持很小的操作，指的是读操作？如果你用于HADR的Standby，所有在Primary上的增删改操作都会赋值到Standby上，必然导致页替换，很可能导致页空间不够用。
3.至于换页空间增长的问题，在AIX中，换页空间的容量是可以动态增加的。当然，如果现有的空间够用，它就不会增加。 收起
2.“问题就出在这里：即便是INSTANCE2的数据库一直保持很小的数据量处理操作，系统的换页空间还是会缓慢的增长”，你说的INSTANCE2一直保持很小的操作，指的是读操作？如果你用于HADR的Standby，所有在Primary上的增删改操作都会赋值到Standby上，必然导致页替换，很可能导致页空间不够用。
3.至于换页空间增长的问题，在AIX中，换页空间的容量是可以动态增加的。当然，如果现有的空间够用，它就不会增加。 收起