专栏首页杨建荣的学习笔记memlock过低导致的数据库性能问题(r6笔记第10天)

memlock过低导致的数据库性能问题(r6笔记第10天)

今天在一台备库机器上准备搭建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

但是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 然后重新登录即可。这样就需要重启数据库实例,需要和开发进行协调来完成了,期待看到极大的性能改进。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:r6笔记第10天

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2015-07-27

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一条关于swap争用的报警邮件分析(一)(r7笔记第28天)

    最近这些天有一台服务器总是会收到剩余swap过低的告警。 邮件内容大体如下: ############ ZABBIX-监控系统: --------------...

    jeanron100
  • MySQL反连接的优化总结(r10笔记第51天)

    今天同事有一个环境发现一条语句执行时间很长,感到非常奇怪。刚好有些时间,就抽空琢磨了下这个问题。 总体来看这个环境还是相对比较繁忙的,线程大概是200多个。 #...

    jeanron100
  • 启用ODM极速调优IO (r2笔记66天)

    在平时的工作中,数据库所处的文件系统是vxfs的话,可以考虑启用veritas的odm特性。 ODM(Oracle Dsk Manager)是在oracle 9...

    jeanron100
  • 《机器学习实战(Scala实现)》(五)——Logistic回归

    z=w0x0+w1x1+...+wnxn\large z = w_0x_0 + w_1x_1 + ... + w_nx_n

    用户1621453
  • Oracle数据库诊断案例-redo log日志组处于高激活状态

    作者:eygle 出处:http://www.eygle.com/blog 日期:June 26, 2005 本文链接:http://www.eygle.co...

    数据和云01
  • python 让cpu满载

    搞zabbix监控的时候,linux服务器的负载很低,如何写一个python脚本,让它满载呢?

    用户2398817
  • 用MTR诊断网络问题

    MTR是一个功能强大的工具,使管理员能够诊断和隔离网络错误,并向上游提供商提供网络状态报告。MTR表示的演进traceroute通过提供更大的数据样本,好像增强...

    魔法少女伊莉雅
  • SceneKit - 提供三种方法解决全景图画面内部透射颠倒的问题

    我们在将一张图渲染在球体上制作全景图的时候,会发现图片上的文字从球体内部来看是反的,我们举例说明一下

    酷走天涯
  • AWR 报告深度解读:Redo Nowait指标的算法和诊断泄露二十多万名用户数据

    AWR知识体系:https://www.modb.pro/topic/6165(复制到浏览器打开或者点击“阅读原文”)

    数据和云
  • R语言数据分析与挖掘(第一章):数据预处理(1)——缺失值处理

    今天开始新的R教程:R语言数据分析与挖掘,本教程是在掌握R基础语法和基本绘图的情况下学习,没有R基础的可先在网上找相关教程进行学习。当然,本公众号(bioinf...

    DoubleHelix

扫码关注云+社区

领取腾讯云代金券