一条关于swap争用的报警邮件分析(二)(r8笔记第4天)

最近收到报警,某一个服务器的swap空间有些紧张,查看这台服务器上有两个备库数据库实例,当然负载还是很低的。但是目前来看,内存已经所剩无几,所以自然而然会用到swap,而且swap也看起来紧张了,从设计的角度来看,这种方式还是有很大的隐患,一旦需要切换,这台服务器还是很有可能出现oom-killer的情况,也就意味着宕机。所以从小从大来看这个报警都不能掉以轻心。 使用top查看的情况如下,可以看到swap已经很紧张了,剩余内存不到300M了。

top - 13:46:44 up 973 days,  3:00,  1 user,  load average: 0.23, 0.16, 0.10
Tasks: 884 total,   1 running, 880 sleeping,   0 stopped,   3 zombie
Cpu(s):  0.9%us,  0.6%sy,  0.0%ni, 98.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65923168k total, 65624684k used,   298484k free,  1256944k buffers
Swap: 33554424k total, 23177916k used, 10376508k free, 60284668k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
 6821 oracle    20   0 16.2g  57m  53m S  9.9  0.1   3618:47 ora_rsm0_megdb                                                         
 4768 oracle    20   0 40.9g 109m  94m S  1.3  0.2  18619:36 ora_dia0_tebdb2    

查看当前服务器的数据库实例情况,如下,可以结合上面的情况可以看到SGA应该一个是40G,一个是16G. [oracle@stepay2 ~]$ ps -ef|grep smon oracle 4784 1 0 2013 ? 00:24:15 ora_smon_tebdb2 oracle 6738 1 0 2014 ? 00:13:26 ora_smon_megdb oracle 20793 20706 0 13:47 pts/2 00:00:00 grep smon 进一步查看进行验证,tebdb2的SGA看似没有启用SGA的自动管理。 SQL> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ lock_sga boolean FALSE pre_page_sga boolean FALSE sga_max_size big integer 41472M sga_target big integer 0 查看megdb的SGA的情况,是使用了SGA的自动管理的。 SQL> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ lock_sga boolean FALSE pre_page_sga boolean FALSE sga_max_size big integer 16G sga_target big integer 16G 当然PGA也会消耗一些内存,但是这些消耗应该不会成为瓶颈,但是swap的消耗却很高。 为什么SGA+PGA的设置都在范围之内,但是swap却总是不够用呢。 这个时候查看共享内存段的情况,发现其中一个数据库实例40G的SGA貌似没有体现出来。 [oracle@stepay2 trace]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 294912 oracle 640 4096 0 0x00000000 327681 oracle 640 4096 0 0x4ab8364c 360450 oracle 640 4096 0 0x00000000 1769475 oracle 640 100663296 67 0x00000000 1802244 oracle 640 17079205888 67 0xf6d1ab84 1835013 oracle 640 2097152 67 所以对于这种情况,一种改善思路就是开大页,从目前经历的绝大多数Linux系统来说,大页的设置应该是一个标配.当然Oracle官方也提供了相应的脚本。 我简单来说一下,脚本的思路首先是根据内核版本,目前支持2.4,2.6 [oracle@stepay2 trace]$ uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }' 2.6 然后得到一个page size的大小,也可以使用root权限通过getconf PAGESIZE来得到。 [oracle@stepay2 trace]$ grep Hugepagesize /proc/meminfo | awk {'print $2'} 2048 然后通过ipcs –m得到共享内存段的情况,然后根据共享内存段的数据来计算需要设置的大页内核参数设置。 [oracle@stepay2 trace]$ ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*" 4096 4096 4096 100663296 17079205888 2097152 因为我们的环境是多实例,我们可以设定一个统一的值,比如我们需要设置50G左右的大页,就可以使用下面的公式进行计算。 MIN_PG=`echo "51200000000/(2048*1024)" | bc -q` 通过上面的公式就会输出最终建议的大页设置 [oracle@stepay2 trace]$ echo "51200000000/(2048*1024)" | bc -q 24414 对应的内核参数在内核2.6就是 vm.nr_hugepages=24414 简单的环境设置交代完毕,然后准备重启备库数据库实例,同时考虑到资源的使用情况,把原来40G的SGA调整为32G,然后把两个实例都停了之后,swap的使用率一下子降下来了。 Tasks: 821 total, 1 running, 817 sleeping, 0 stopped, 3 zombie Cpu(s): 0.9%us, 0.4%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 65923168k total, 53194676k used, 12728492k free, 63904k buffers Swap: 33554424k total, 32812k used, 33521612k free, 1694992k cached 然后我们重启,这个时候发现有一个数据库实例怎么都启动不了。 SQL> startup nomount ORA-27102: out of memory Linux-x86_64 Error: 28: No space left on device 一般根据经验这个错误主要都是因为内核参数设置的过小导致。 但是查看了下面的配置,没有发现问题。 kernel.shmmax = 68719476736 kernel.shmall=16777216 fs.aio-max-nr = 1048576 fs.file-max = 6815744 vm.nr_hugepages= 24414 对于这个问题着实感到奇怪,同时查看alert日志也没有看到任何大页开启的信息。为什么大页没有开启呢,而且数据库实例还启动不了。 这个可以从共享内存段的设置情况来做一个简单的佐证。 [oracle@stepay2 ~]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 2260995 oracle 640 201326592 0 0x00000000 2293764 oracle 640 32010928128 0 发现其中一个设置为32G的共享内存空间已经被使用了,而且更加奇怪的是切换profile使用sqlplus还连接不到这个实例,可见这部分内存空间还没有通过ORACLE_SID和SGA建立映射关系。那么对于这部分缓存空间,可以手工进行清理。 [oracle@stepay2 ~]$ ipcrm -m 2293764 而为什么大页没有开启呢,这个时候反复验证,发现是启用了自动内存管理,明白了这点再来看这个问题一下子就有些恍然大悟了。把这台服务器上相关的服务都停了,然后手工清空了剩余的共享内存段。 [oracle@stepay2 ~]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 2260995 oracle 640 201326592 0 [oracle@stepay2 ~]$ ipcrm -m 2260995 当然如果条件允许,最好重启一下,如果不能重启还是使用sysctl –p来设置内核参数生效。 然后再次重启就没有任何问题了。 [oracle@stepay2 trace]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 3506176 oracle 640 100663296 67 0x00000000 3538945 oracle 640 16005464064 67 0xf6d1ab84 3571714 oracle 640 2097152 67 0x00000000 3637251 oracle 640 201326592 66 0x00000000 3670020 oracle 640 32010928128 66 0x4ab8364c 3702789 oracle 640 2097152 66 通过这个细小的案例,我们可以看到其实有些看似细小的警告,如果不加以重视,会逐渐演变为一个大问题。需要提前预警,提前处理。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2016-02-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏社区的朋友们

基于 SPP 模块的优化实践

SPP 框架的微线程模式在网络密集型 Server 开发中优势明显,在使用过程中,也遇到过一些性能问题,下面跟大家分享下解决思路。

92500
来自专栏日常学python

python使用requests+re简单入门爬虫

在学习了python基础后,一心想着快速入门爬虫,因为我就是为爬虫而学的python,所以就找了这个豆瓣电影来爬取。好了,废话不多说,进入正题 1.找到网页并分...

408110
来自专栏Python专栏

Python | 开发者必备的 6 个库

链接:https://www.oschina.net/translate/6-essential-libraries-for-every-python-deve...

32630
来自专栏musazhang的专栏

畅游数据库性能优化过程简析(下)

经过周末两天的折腾,在大家的帮助下最终将用户 DB 的性能峰值由最初的不到 8W 的 QPS + TPS 提升至 17W,心情也由最初的忐忑过渡到现在的平静,现...

53700
来自专栏nnngu

通俗易懂的分析如何用Python实现一只小爬虫,爬取拉勾网的职位信息

源代码:https://github.com/nnngu/LagouSpider ---- 效果预览 ? 思路 1、首先我们打开拉勾网,并搜索“java”,显示...

38050
来自专栏非典型程序猿

Elasticsearch数据更新全方位解析

前段时间在项目的crm存储部分,为了满足大量自定义的搜索功能,选择了使用了ES作为后端存储介质。

3.9K120
来自专栏nnngu

通俗易懂的分析如何用Python实现一只小爬虫,爬取拉勾网的职位信息

源代码:https://github.com/nnngu/LagouSpider

57060
来自专栏北京马哥教育

Python 开发者的 6 个必备库

来自:开源中国 协作翻译 链接: https://www.oschina.net/translate/6-essential-libraries-for-e...

50470
来自专栏小詹同学

Python | 开发者必备的 6 个库

链接:https://www.oschina.net/translate/6-essential-libraries-for-every-python-deve...

55430
来自专栏社区的朋友们

TAF 必修课(四):过载保护

经过实习过程中,leader和导师在思维逻辑上的指导,自己再有意识的加以训练,我觉得非常受益。就如这部分的理解,目前就加深了很多。所以说,思维决定行为、行为决定...

92100

扫码关注云+社区

领取腾讯云代金券