一条关于swap争用的报警邮件分析(一）

最近这些天有一台服务器总是会收到剩余swap过低的告警。
邮件内容大体如下：
############
ZABBIX-监控系统:
------------------------------------
报警内容: Lack of free swap space on ora_test_s2_yangjr@10.127.2.xxxx
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free swap space in %：21.59 %
------------------------------------
报警时间:2015.11.23-04:10:57
简单查看了一下服务器配置，发现是一个32G的服务器，swap空间为8G，目前已经使用6G多。架构如图所示

top - 11:56:03 up 152 days,  2:06,  1 user,  load average: 0.53, 0.34, 0.27
Tasks: 338 total,   1 running, 326 sleeping,   0 stopped,  11 zombie
Cpu(s):  5.6%us,  0.0%sy,  0.0%ni, 94.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32949076k total, 32846716k used,   102360k free,   237324k buffers
Swap:  8385920k total,  6427096k used,  1958824k free, 28360876k cached
对于这个，简单分析了一下，原来这台服务器上再运行两个数据库实例
oracle    5606     1  0 Jun24 ?        00:01:12 ora_smon_ctest
oracle   10533     1  0 Jun27 ?        00:01:11 ora_smon_catest
oracle   21950 21560  0 17:54 pts/0    00:00:00 grep smon
从smon初始化的时间来看，这两个数据库实例大概是在7月底启动的，时间有一些先后。
这两个库是11g的DG环境。所以平时主要是会有归档的接收和应用。
为什么会发生swap争用呢，首先想到的就是内存组件的设置问题，是不是设置过大，导致没有富裕的内存资源可用了。
查看数据库实例ctest
SQL> show parameter sga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 12032M
sga_target                           big integer 12032M
SQL> show parameter pga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4010M
所以对于ctest sga+pga=12G+4G=16G,大体如此。

对于数据库实例catest,内存组件大小为;
SQL> show parameter sg
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 20G
sga_target                           big integer 20G
SQL> show parameter pga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 8530M
所以简单相加就是20G+8G=28G
如此一来，28G+16G=44G,而内存资源只有32G,那剩下的12G是怎么来的。如果排除法，也就只有swap了。
当然数据库层面没有任何的异常，也没有限制sga无法设置成功之类的问题。听起来倒也相安无事。
查看v$dynamic_components得到的信息如下：
catest的内存组件大小为：2G+18G=20G
$sh showbuffer.sh
[oracle@scycard2 dbm_lite]$ sh showbuffer.sh
COMPONENT                       CURRENT_M      MIN_M      MAX_M SPECCIFIED_M LAST_OPER LAST_OPER_TYP  GRANULE_M
------------------------------ ---------- ---------- ---------- ------------ --------- ------------- ----------
shared pool                          2304       2304       2304            0           STATIC                64
large pool                             64         64         64            0           STATIC                64
java pool                              64         64         64            0           STATIC                64
streams pool                            0          0          0            0           STATIC                64
DEFAULT buffer cache                17920      17920      17920        15360           INITIALIZING          64
           
ctest的内存组件大小为：
$ sh showbuffer.sh
COMPONENT                       CURRENT_M      MIN_M      MAX_M SPECCIFIED_M LAST_OPER LAST_OPER_TYP  GRANULE_M
------------------------------ ---------- ---------- ---------- ------------ --------- ------------- ----------
shared pool                          1664       1664       1664            0           STATIC                32
large pool                             64         64         64            0           STATIC                32
java pool                              64         64         64            0           STATIC                32
streams pool                            0          0          0            0           STATIC                32
DEFAULT buffer cache                10176      10176      10176            0           INITIALIZING          32
内存组件大小为1.6G+10G约为12G
所以如此一算，刚好和内存的大小一致。看来尽管sga,pga会显示有一个很大的值，其实还是根据实际的内存资源来分配。
这个时候问题就来了，为什么能够设置sga,pga为一个较高的值，而且数据库中似乎能够验证通过。
这个地方也就只能用kernel层面才可以说清了。
cat /etc/sysctl.conf的配置如下，可以看到配置了shmmax为近100G的最大共享内存段，支持的共享内存段的页数也非常高。shmall还是很高的。
fs.aio-max-nr = 1048576
kernel.shmall = 33554432
kernel.shmmax = 107374182400
kernel.shmmni = 4096
查看当前的session设置的shmmax的值。
# more /proc/sys/kernel/shmmax
107374182400
如果查看共享内存段的内容如下：
# ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x74010013 2293760    root      600        4          0                       
0x740182d0 2981889    root      600        4          0                       
0x00000000 4194306    oracle    640        134217728  67                      
0x740182cf 2949123    root      600        4          0                       
0x00000000 4227076    oracle    640        21340618752 67                      
0x538bd97c 4259845    oracle    640        2097152    67                      
0x00000000 3768326    oracle    640        67108864   49                      
0x00000000 3801095    oracle    640        12549357568 49                      
0xaf0a22e4 3833864    oracle    640        2097152    49                      
0x6c0109ec 6455305    zabbix    600        995952     6  
所以内核参数的设置还是存在一定的问题，shmmax可以设置为内存的一半或者更高。一般会尝试用内存的80%等
#kernel.shmall = 33554432
#kernel.shmmax = 107374182400

kernel.shmall = 8388608
kernel.shmmax = 32212254720
比如可以设置为一个相对较大的值，使用getconf PAGE_SIZE得到的页大小一般都是4k.
那么我们来简单规范一下。
ctest数据库实例的设置为：
SQL> alter system set sga_max_size=12G scope=spfile;
System altered.
SQL> alter system set sga_target=12G scope=spfile;
System altered.
SQL> show parameter uniq
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      STEST
SQL> show parameter pga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 4G
pga适度改小一些，然后停备库，听备库还有什么方法论吗，那就是看看session的情况，是否有其它额外的session在运行。
SQL> select username,count(*)from v$session group by username;
USERNAME                         COUNT(*)
------------------------------ ----------
                                       42
PUBLIC                                  5
SYS                                     1

SQL> shutdown immediate       之后就需要使用sysctl -p或者重启服务器的方式来设置生效了。        
没有sysctl -p之前，查看shmmax的设置还是100G
$ more /proc/sys/kernel/shmmax
107374182400
设置生效之后，再来看看swap的情况。发现一下子降下来了。
top - 17:34:47 up 154 days,  7:45,  2 users,  load average: 0.33, 0.32, 0.28
Tasks: 211 total,   1 running, 204 sleeping,   0 stopped,   6 zombie
Cpu(s):  0.3%us,  0.3%sy,  0.0%ni, 99.2%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32949076k total,  3464424k used, 29484652k free,   193008k buffers
Swap:  8385920k total,     4352k used,  8381568k free,  2901552k cached
至于swap的监控，可以使用下面的脚本来做一些简单的分析，还算是比较实用的。
因为环境的swap使用很低，所以可以找一台服务器swap相对较高的，然后使用下面的脚本来分析。
#  for i in $( cd /proc;ls |grep "^[0-9]"|awk ' $0 >100') ;do awk '/Swap:/{a=a+$2}END{print '"$i"',a/1024"M"}' /proc/$i/smaps 2>/dev/null ; done | sort -k2nr | head -10
19119 1503.39M
7520 50.7617M
18216 38.6172M
18218 26.3945M
18212 22.0938M
32219 11.8242M
18174 11.2539M
18286 7.8125M
18214 6.90625M
12507 5.17578M
可以看到哪个进程占用了较高的temp资源情况。
那么这儿问题如何验证，是否内核参数shmmax,shmall设置过高，会有sga_target设置的错觉。
SQL> show parameter sga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 45G
sga_target                           big integer 45G
使用top -c查看的结果如下：
Tasks: 253 total,   1 running, 252 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16319100k total,  5582080k used, 10737020k free,   429292k buffers
Swap: 16777200k total,    12956k used, 16764244k free,  4402968k cached
ipcs的情况可以参见下面的结果。
$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 6062080    oracle     640        67108864   17                      
0x00000000 6094849    oracle     640        12515803136 17                      
0xfadedb24 6127618    oracle     640        2097152    17                      
0x00000000 6848515    oracle     640        268435456  27                      
0x00000000 6881284    oracle     640        24024973312 27                      
0x00000000 6914053    oracle     640        24024973312 27                      
0xc3655edc 6946823    oracle     640        2097152    27