查看: 893|回复: 0

[原创] linux 内存参数优化思路

[复制链接]
论坛徽章:
21
娜美
日期:2017-06-26 15:18:15火眼金睛
日期:2018-04-30 22:00:00目光如炬
日期:2018-07-29 22:00:00火眼金睛
日期:2018-08-31 22:00:00目光如炬
日期:2018-09-02 22:00:00目光如炬
日期:2018-09-16 22:00:01火眼金睛
日期:2018-09-30 22:00:00目光如炬
日期:2018-10-14 22:00:00火眼金睛
日期:2018-11-30 22:00:01目光如炬
日期:2018-04-29 22:00:00
发表于 2018-12-6 11:15 | 显示全部楼层 |阅读模式

   linux 内存参数优化思路

作者简介:
----------------------------------------------------------------------
@ 孙显鹏,海天起点oracle技术专家,十年从业经验
@ 精通oracle内部原理,擅长调优和解决疑难问题
@ 致力于帮助客户解决生产中的问题,提高生产效率。
@ 爱好:书法,周易,中医。微信:sunyunyi_sun
@ 易曰:精义入神,以致用也!
@ 调优乃燮理阴阳何其难也!
----------------------------------------------------------------------

重要的参数如下:


dirty vm.dirty_background_ratio = 5
vm.dirty_background_bytes = 0
vm.dirty_ratio = 10
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000


查看vm 统计信息:
cd /proc/sys/vm
[root@piamarydb vm]# more dirty_background_ratio
10
[root@piamarydb vm]# more dirty_bytes
0
[root@piamarydb vm]# more dirty_ratio
20
[root@piamarydb vm]# more min_free_kbytes
5746
表示强制Linux VM最低保留多少空闲内存(Kbytes),依据系统内存大小有所不同。




参数理解:
free 命令的cache 表示对于文件操作的缓存,这里分为读缓存区和写缓冲区,
dirty_ratio:表示写缓冲区脏页占物理总内存的百分比,当达到该条件时,
后面所有的IO写请求暂停,系统同步写脏页到磁盘,至于写多少不清楚,可能只写默认30s以前的脏页。
为什么这么说呢?从很多资料看,free 中的buffer 主要用来缓存目录inode
的metadata信息,数据量一般不会太大,但是也有例外情况,我遇到的问题
是:系统1TB内存,500GB大页内存,系统出现故障时buffer 130GB,cache 160GB,
故障前和故障后平均buffer 70GB,cache 100GB 很稳定。故障时间段存在大量的buffer和cache。
故障时间触发了dirty_ratio条件,依据message:
task java:290269 blocked for more than 120 seconds. --dirty_ratio 的写超时时间为120s
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
信息确定触发了dirty_ratio条件,但是1TB的20%是200GB,难道系统此时cache 200GB全部为脏块,
也是有这个可能,160GB的值也许被瞬间增大到200GB。可惜没有办法确定当时系统的脏页大小。
另外有一个系统:
总内存:529178360KB
buffers: 7508976KB
cache: 379159316KB
cache 占总内存几乎71%,系统也没有触发dirty_ratio条件,那么证明脏块很少,从/proc/meminfo的dirty为18476KB确定存在很少的脏页。
那么到底dirty_ratio比例应该设置为低呢,还是高呢?
低:频繁触发dirty_ratio条件,内存极大时也不安全
高:很少触发dirty_ratio条件,一旦触发很危险!




dirty_background_ratio :表示脏页占用的百分比,达到该百分比后台进程pdflush/flush/kdmflush刷新脏页到磁盘,该操作为异步,不会阻塞后面的IO。


dirty_background_ratio 值很低会延缓达到dirty_ratio条件。


但是百分比要依据系统内存的中大小设置,比如100GB和1TB同样是5%那差别是很大的。


我觉得系统写5GB的数据还是很合理的,写太大数据不合理。


所以建议使用vm.dirty_background_bytes参数明确指定脏页的阀值。


以1TB内存为例:


vm.dirty_background_ratio = 1
vm.dirty_background_bytes = 5000000000
vm.dirty_ratio = 80
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000




测试 vm.dirty_background_bytes 参数:


[root@piamarydb vm]# more /proc/meminfo |grep Dir
Dirty:                 4 kB   --目前系统存在4KB脏页
DirectMap4k:       10176 kB
DirectMap2M:     2086912 kB
[root@piamarydb vm]# ls
block_dump              dirty_writeback_centisecs   lowmem_reserve_ratio       mmap_min_addr            oom_kill_allocating_task  stat_interval
compact_memory          drop_caches                 max_map_count              nr_hugepages             overcommit_memory         swappiness
dirty_background_bytes  extfrag_threshold           memory_failure_early_kill  nr_hugepages_mempolicy   overcommit_ratio          vfs_cache_pressure
dirty_background_ratio  hugepages_treat_as_movable  memory_failure_recovery    nr_overcommit_hugepages  page-cluster              zone_reclaim_mode
dirty_bytes             hugetlb_shm_group           min_free_kbytes            nr_pdflush_threads       panic_on_oom
dirty_expire_centisecs  laptop_mode                 min_slab_ratio             numa_zonelist_order      percpu_pagelist_fraction
dirty_ratio             legacy_va_layout            min_unmapped_ratio         oom_dump_tasks           scan_unevictable_pages


[root@piamarydb vm]# echo 512>dirty_background_bytes  --修改该值为512byte,那么此时系统发生pdflush/flush/kdmflush刷新


[root@piamarydb vm]# more /proc/meminfo |grep Dir


Dirty:                 0 kB         --已经刷新了脏页
DirectMap4k:       10176 kB
DirectMap2M:     2086912 kB




指定了vm.dirty_background_bytes参数vm.dirty_background_ratio参数失效!


下面这个两个参数建议保持默认:
[root@piamarydb vm]# more dirty_writeback_centisecs
500
[root@piamarydb vm]# more dirty_expire_centisecs
3000


查询脏页命令:
cat /proc/vmstat | egrep "dirty|writeback"  --应该写个脚本定期检查脏页数据量,对于上面问题系统




参数含义如下:


vm.dirty_background_ratio is the percentage of system memory that can be filled with “dirty” pages
— memory pages that still need to be written to disk — before
the pdflush/flush/kdmflush background processes kick in to write it to disk.


vm.dirty_ratio is the absolute maximum amount of system memory that can be filled with dirty pages
before everything must get committed to disk. When the system gets
to this point all new I/O blocks until dirty pages have been written to disk.
This is often the source of long I/O pauses, but is a safeguard against too much data
being cached unsafely in memory.


vm.dirty_background_bytes and vm.dirty_bytes are another way to specify these parameters.
If you set the _bytes version the _ratio version will become 0, and vice-versa.


vm.dirty_expire_centisecs is how long something can be in cache before it needs to be written.
In this case it’s 30 seconds. When the pdflush/flush/kdmflush processes
kick in they will check to see how old a dirty page is, and if it’s older than this value
it’ll be written asynchronously to disk. Since holding a dirty page in
memory is unsafe this is also a safeguard against data loss.


vm.dirty_writeback_centisecs is how often the pdflush/flush/kdmflush processes wake up and check to see if work needs to be done.




注意,大页内存不会写cache,所以呀经常提醒大家开启大页内存,因为linux和其他UNIX的内存管理缺陷就在于大页内存。
而linux的大页内存只能用于共享内存段,虽然透明大页内存可以变相操作,但是bug较多不建议开启,特别是使用oracle。
既然大页内存只能用于共享内存段,所以PGA就不能使用大页,这就是为什么AMM不支持大页的原因了。
现在的服务器内存500GB以上很常见,还是基于小的页面管理大的内存是极不合理的。建议共享内存大于8GB开启大页内存,
共享内存大于250GB必须开启大页内存。另外设置大页内存必须要合理不要设置太大,这样极大的浪费内存。
开启了大页内存,也就降低了cache的几率。




总结:
其实,每个系统内存管理原理都是一样的,我们遇到集群异常大部分都是因为内存设置不合理造成的,内存故障的几率最大。
设置参数一个是要理解其含义,但是更重要的是要依据实际情况设置,比如上面说的100GB的内存和1TB的内存都设置5%,那么
计算的结果是有极大差距的。5GB和50GB的区别在极端情况下,突然写5GB是可以承受的,突然写50GB是系统承受不了的。
因为磁盘的写速度很慢,就是闪存卡,写速度最大也是1.5GB左右。那么达到强制写200GB数据可想而知。如果RAC ges,gcs,
这些重要的后太进程较长时间没有响应,那么集群触发资源踢出操作,资源踢出失败升级为实例踢出,导致节点重启!









您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表