最近这些天有一台服务器总是会收到剩余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
