• 记一次dirty_ratio引起的线上事故


    故障时间轴

    • 发生时间:2020-09-14 06:40
    • 发现时间:2020-09-14 06:41
    • 响应时间:2020-09-14 07:42

    故障表现

    1. 磁盘>75% ,最终累计到100%

    2. Load1 远远>8

    3. CPU & MEM > 85%

    故障根因

    Kernel报错如下:

    默认情况下, Linux会最多使用40%的可用内存作为文件系统缓存。当超过这个阈值后,文件系统会把将缓存中的内存全部写入磁盘, 导致后续的IO请求都是同步的。

    将缓存写入磁盘时,有一个默认120秒的超时时间。 出现此次问题的原因是IO子系统的处理速度不够快,不能在120秒将缓存中的数据全部写入磁盘。IO系统响应缓慢,导致越来越多的请求堆积,最终系统内存全部被占用,导致系统失去响应。

    改进措施

    此次异常报错出的问题以及改进措施

    问题 改进措施 负责人 完成时间
    磁盘100%,没有自动清理 补充自动清理脚本或者机制 xx
    内核参数调整 vm.dirty_ratio=5 vm.dirty_background_ratio=10 xx

    内核参数说明:

    • vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如5%)就会触发pdflush/flush/kdmflush等后台回写进程运行,将一定缓存的脏页异步地刷入外存;
    • vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如10%),系统不得不开始处理缓存脏页(因为此时脏页数量已经比较多,为了避免数据丢失需要将一定脏页刷入外存);在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。

    系统当前值:

    #sysctl -a| grep dirty
    vm.dirty_background_ratio = 10
    vm.dirty_background_bytes = 0
    vm.dirty_ratio = 20
    vm.dirty_bytes = 0
    vm.dirty_writeback_centisecs = 500
    vm.dirty_expire_centisecs = 3000
    
  • 相关阅读:
    rsync
    zabbix一键部署
    MYSQL高可用——MHA(概述与安装)
    正向代理的简单概括和应用
    kvm的简介与安装桥接
    linux下常用的五个查找命令
    简述MVC框架模式以及在你(Android)项目中的应用
    ThreadLocal源码分析
    Handler、Looper、MessageQueue、Thread源码分析
    HashMap总结
  • 原文地址:https://www.cnblogs.com/vinsent/p/13666097.html
Copyright © 2020-2023  润新知