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

时间:2022-05-04
本文章向大家介绍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 然后重新登录即可。这样就需要重启数据库实例，需要和开发进行协调来完成了，期待看到极大的性能改进。

随机文章
本站知识点必读
最近更新