今天在一台备库机器上准备搭建active data guard ，在主库上做配置的时候，发现主库的反应有些慢，主要的感觉就是敲命令的时候似乎都有些停顿。
带着疑问查看了下数据库的负载情况，发现连进来的用户很少，数据库负载也很低，归档每天切换不到20次
但是使用top命令查看的时候还是能够看到kswapd1的身影，这个进程是一个性能出现问题的标志，因为在之前的一个项目中因为配置hugepage出现问题，结果导致系统出现了严重的swap现象，当时的top 进程就是kswapd这样的进程。
我按照top进程的时间简单查看了下。
Tasks: 289 total, 1 running, 282 sleeping, 0 stopped, 6 zombie
Cpu(s): 7.7%us, 7.7%sy, 0.0%ni, 84.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65804840k used, 191372k free, 2768k buffers
Swap: 16771776k total, 5473276k used, 11298500k free, 13392336k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
827 root 10 -5 0 0 0 S 0.0 0.0 393:54.67 [kswapd1]
6176 oracle 18 0 18.2g 52m 48m S 0.0 0.1 313:30.37 ora_dia0_xxxx
826 root 10 -5 0 0 0 S 0.0 0.0 262:21.47 [kswapd0]
6190 oracle 16 0 18.2g 462m 459m S 0.0 0.7 198:13.92 ora_mmon_ xxxx
3654 root 34 19 0 0 0 S 0.0 0.0 67:30.61 [kipmi0]
6180 oracle 16 0 18.3g 11g 11g S 0.0 17.7 43:07.78 ora_dbw0_ xxxx
6192 oracle 15 0 18.2g 104m 102m S 0.0 0.2 42:29.52 ora_mmnl_ xxxx
6184 oracle 16 0 18.2g 613m 613m S 0.0 1.0 30:04.32 ora_ckpt_ xxxx
6182 oracle 16 0 18.2g 75m 75m S 0.0 0.1 23:53.08 ora_lgwr_ xxxx
6186 oracle 15 0 18.2g 855m 853m S 0.0 1.3 13:33.32 ora_smon_ xxxx
6162 oracle 15 0 18.2g 29m 28m S 0.0 0.0 8:08.11 ora_pmon_ xxxx
2773 root 10 -5 0 0 0 S 0.0 0.0 5:43.35 [kjournald]
6354 oracle 15 0 18.2g 358m 352m S 0.0 0.6 4:01.47 ora_cjq0_ xxxx
3473 root 11 -4 92888 780 556 S 0.0 0.0 2:42.97 auditd
6302 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:08.43 ora_arcf_ xxxx
6276 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:08.10 ora_arc4_ xxxx
6318 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:06.25 ora_arcn_ xxxx
6290 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:05.30 ora_arca_ xxxx
6274 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:04.12 ora_arc3_ xxxx
6304 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:03.83 ora_arcg_ xxxx
6286 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.99 ora_arc9_ xxxx
6326 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.70 ora_arcp_ xxxx
6330 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.26 ora_arcq_ xxxx
6278 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.00 ora_arc5_ xxxx
对于一个内存有60多G的系统来说，只有一个数据库实例，而且实例的sga大小可以看出来大概在18G左右，反应有些慢确实有些不合理。
不过直接来看，发现这里面有一个问题比较明显就是存在很多的归档进程 arc这样的进程，一般的系统中就2~4个左右，这个似乎有些多了。
自己也暗自庆幸，好像发现问题的原因了。带着疑问查看了数据库的归档配置参数 LOG_ARCHIVE_MAX_PROCESSES竟然是30，从官方文档来看，就是最高值了。
简单确认之后就开始修改这个参数，从30改到了4个。
从top命令的情况来看，似乎swap有了一些改进，也确实腾出了一些内存空间
top - 17:12:45 up 81 days, 21:08, 3 users, load average: 0.09, 0.39, 0.49
Tasks: 287 total, 1 running, 280 sleeping, 0 stopped, 6 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65803376k used, 192836k free, 4588k buffers
Swap: 16771776k total, 5470956k used, 11300820k free, 13424524k cached
top - 17:17:39 up 81 days, 21:13, 3 users, load average: 0.01, 0.17, 0.36
Tasks: 261 total, 1 running, 254 sleeping, 0 stopped, 6 zombie
Cpu(s): 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65271068k used, 725144k free, 5768k buffers
Swap: 16771776k total, 4940324k used, 11831452k free, 13427832k cached
带着疑问查看了下数据库的负载情况，发现连进来的用户很少，数据库负载也很低，归档每天切换不到20次
但是使用top命令查看的时候还是能够看到kswapd1的身影，这个进程是一个性能出现问题的标志，因为在之前的一个项目中因为配置hugepage出现问题，结果导致系统出现了严重的swap现象，当时的top 进程就是kswapd这样的进程。
我按照top进程的时间简单查看了下。
Tasks: 289 total, 1 running, 282 sleeping, 0 stopped, 6 zombie
Cpu(s): 7.7%us, 7.7%sy, 0.0%ni, 84.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65804840k used, 191372k free, 2768k buffers
Swap: 16771776k total, 5473276k used, 11298500k free, 13392336k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
827 root 10 -5 0 0 0 S 0.0 0.0 393:54.67 [kswapd1]
6176 oracle 18 0 18.2g 52m 48m S 0.0 0.1 313:30.37 ora_dia0_xxxx
826 root 10 -5 0 0 0 S 0.0 0.0 262:21.47 [kswapd0]
6190 oracle 16 0 18.2g 462m 459m S 0.0 0.7 198:13.92 ora_mmon_ xxxx
3654 root 34 19 0 0 0 S 0.0 0.0 67:30.61 [kipmi0]
6180 oracle 16 0 18.3g 11g 11g S 0.0 17.7 43:07.78 ora_dbw0_ xxxx
6192 oracle 15 0 18.2g 104m 102m S 0.0 0.2 42:29.52 ora_mmnl_ xxxx
6184 oracle 16 0 18.2g 613m 613m S 0.0 1.0 30:04.32 ora_ckpt_ xxxx
6182 oracle 16 0 18.2g 75m 75m S 0.0 0.1 23:53.08 ora_lgwr_ xxxx
6186 oracle 15 0 18.2g 855m 853m S 0.0 1.3 13:33.32 ora_smon_ xxxx
6162 oracle 15 0 18.2g 29m 28m S 0.0 0.0 8:08.11 ora_pmon_ xxxx
2773 root 10 -5 0 0 0 S 0.0 0.0 5:43.35 [kjournald]
6354 oracle 15 0 18.2g 358m 352m S 0.0 0.6 4:01.47 ora_cjq0_ xxxx
3473 root 11 -4 92888 780 556 S 0.0 0.0 2:42.97 auditd
6302 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:08.43 ora_arcf_ xxxx
6276 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:08.10 ora_arc4_ xxxx
6318 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:06.25 ora_arcn_ xxxx
6290 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:05.30 ora_arca_ xxxx
6274 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:04.12 ora_arc3_ xxxx
6304 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:03.83 ora_arcg_ xxxx
6286 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.99 ora_arc9_ xxxx
6326 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.70 ora_arcp_ xxxx
6330 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.26 ora_arcq_ xxxx
6278 oracle 15 0 18.3g 42m 22m S 0.0 0.1 2:02.00 ora_arc5_ xxxx
对于一个内存有60多G的系统来说，只有一个数据库实例，而且实例的sga大小可以看出来大概在18G左右，反应有些慢确实有些不合理。
不过直接来看，发现这里面有一个问题比较明显就是存在很多的归档进程 arc这样的进程，一般的系统中就2~4个左右，这个似乎有些多了。
自己也暗自庆幸，好像发现问题的原因了。带着疑问查看了数据库的归档配置参数 LOG_ARCHIVE_MAX_PROCESSES竟然是30，从官方文档来看，就是最高值了。
简单确认之后就开始修改这个参数，从30改到了4个。
从top命令的情况来看，似乎swap有了一些改进，也确实腾出了一些内存空间
top - 17:12:45 up 81 days, 21:08, 3 users, load average: 0.09, 0.39, 0.49
Tasks: 287 total, 1 running, 280 sleeping, 0 stopped, 6 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65803376k used, 192836k free, 4588k buffers
Swap: 16771776k total, 5470956k used, 11300820k free, 13424524k cached
top - 17:17:39 up 81 days, 21:13, 3 users, load average: 0.01, 0.17, 0.36
Tasks: 261 total, 1 running, 254 sleeping, 0 stopped, 6 zombie
Cpu(s): 0.1%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 65996212k total, 65271068k used, 725144k free, 5768k buffers
Swap: 16771776k total, 4940324k used, 11831452k free, 13427832k cached
但是swap还是比较高，对于这样一个配置还不错的系统，swap应该很低，接近于0.
带着疑问开始尝试使用addm来分析指定时间段的数据库情况，但是从报告来看得到的信息还是比较少，报告中说系统有大量的paging现象，但是原因不明，建议调大内存，调内存在这个问题里面
还是站不住脚的。对于报告中的sql语句，也是相对的，因为这个库的使用人数极少，运行的sql语句也不多。sql带来的影响非常有限。
这个时候数据库日志是一个很好的参考，因为从v$database可以看出数据库是在5月份重启的，所以就查看当时启动以来的一些日志，所幸的是一查就有了一些收获。
在启动的时候还是抛出了一些警告。
而且从警告信息来看，应该是内核参数出了问题。
Starting ORACLE instance (normal)
Memlock limit too small: 32768 to accommodate segment size: 4194304
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 46137344
Memlock limit too small: 32768 to accommodate segment size: 67108864
Memlock limit too small: 32768 to accommodate segment size: 67108864
。。。。。
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 24576 (48 GB) (alloc incr 64 MB)
Large Pages configured system wide = 24576 (48 GB)
Large Page size = 2048 KB
RECOMMENDATION:
Total Shared Global Region size is 18 GB. For optimal performance,
prior to the next instance restart increase the number
of unused Large Pages by atleast 0 2048 KB Large Pages (0 KB)
system wide to get 100% of the Shared
Global Region allocated with Large pages
这个库没有配置huge page，large_page也没有配置，至少没有生效。
metalink中的文章1511239.1也给出了比较详细的解释，就是memlock的配置问题。
使用ulimit 来查看。
$ ulimit -l
32
这个和警告信息是一致的。
而从oracle的解释和建议来看，这个值还是应该比内存配置略小，也就是要配置的足够大。
可以在/etc/security/limits.conf 修改memlock的值。比如64G的内存，就可以这么配置
* soft memlock 60397977
* hard memlock 60397977
然后重新登录即可。这样就需要重启数据库实例，需要和开发进行协调来完成了，期待看到极大的性能改进。
带着疑问开始尝试使用addm来分析指定时间段的数据库情况，但是从报告来看得到的信息还是比较少，报告中说系统有大量的paging现象，但是原因不明，建议调大内存，调内存在这个问题里面
还是站不住脚的。对于报告中的sql语句，也是相对的，因为这个库的使用人数极少，运行的sql语句也不多。sql带来的影响非常有限。
这个时候数据库日志是一个很好的参考，因为从v$database可以看出数据库是在5月份重启的，所以就查看当时启动以来的一些日志，所幸的是一查就有了一些收获。
在启动的时候还是抛出了一些警告。
而且从警告信息来看，应该是内核参数出了问题。
Starting ORACLE instance (normal)
Memlock limit too small: 32768 to accommodate segment size: 4194304
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 46137344
Memlock limit too small: 32768 to accommodate segment size: 67108864
Memlock limit too small: 32768 to accommodate segment size: 67108864
。。。。。
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 24576 (48 GB) (alloc incr 64 MB)
Large Pages configured system wide = 24576 (48 GB)
Large Page size = 2048 KB
RECOMMENDATION:
Total Shared Global Region size is 18 GB. For optimal performance,
prior to the next instance restart increase the number
of unused Large Pages by atleast 0 2048 KB Large Pages (0 KB)
system wide to get 100% of the Shared
Global Region allocated with Large pages
这个库没有配置huge page，large_page也没有配置，至少没有生效。
metalink中的文章1511239.1也给出了比较详细的解释，就是memlock的配置问题。
使用ulimit 来查看。
$ ulimit -l
32
这个和警告信息是一致的。
而从oracle的解释和建议来看，这个值还是应该比内存配置略小，也就是要配置的足够大。
可以在/etc/security/limits.conf 修改memlock的值。比如64G的内存，就可以这么配置
* soft memlock 60397977
* hard memlock 60397977
