//2019/7/31 18:41:14
掐指一算应该resore完了呀,是不是天热想罢工?不过已经差不多30个小时了
无意间一查 tail -500f /var/log/messages 发现有些“more than 120 seconds|hung_task_timeout_secs”,还有写kernel乱七八糟的,有点蒙圈。。。先分析再干活
咋一看2个帖子分析的非常有道理,那就干吧,粗体是要执行查看的

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

将缓存写入磁盘时,有一个默认120秒的超时时间。出现上面的问题的原因是IO子系统的处理速度不够快,不能在120秒将缓存中的数据全部写入磁盘。

IO系统响应缓慢,导致越来越多的请求堆积,最终系统内存全部被占用,导致系统失去响应。

系统默认
[root@dinpaydg_cc ~]# sysctl -a | grep 'vm.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
[root@dinpaydg_cc ~]#

解决方法:
根据应用程序情况,对vm.dirty_ratio,vm.dirty_background_ratio两个参数进行调优设置
root执行下看看
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5
sysctl -p

[root@dinpaydg_cc ~]# sysctl -a | grep 'vm.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
[root@dinpaydg_cc ~]#

当然我只用了上免得方法,生产暂时没法重启。

如果系统永久生效,修改/etc/sysctl.conf文件。加入如下两行:

#vi /etc/sysctl.conf

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

重启系统生效。

系统日志分析
grep 'Jul 31' messages | grep -E 'more than 120 seconds|hung_task_timeout_secs'
--发现机器restore了30个小时
[root@dinpaydg_cc log]# grep 'Jul 31' messages | grep -E 'more than 120 seconds|hung_task_timeout_secs'
Jul 31 15:11:57 dinpaydg_cc kernel: INFO: task oracle:4146 blocked for more than 120 seconds.
Jul 31 15:11:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 31 16:17:57 dinpaydg_cc kernel: INFO: task oracle:4147 blocked for more than 120 seconds.
Jul 31 16:17:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 31 16:23:57 dinpaydg_cc kernel: INFO: task oracle:4144 blocked for more than 120 seconds.
Jul 31 16:23:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 31 16:23:57 dinpaydg_cc kernel: INFO: task oracle:4146 blocked for more than 120 seconds.
Jul 31 16:23:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 31 16:25:57 dinpaydg_cc kernel: INFO: task oracle:4144 blocked for more than 120 seconds.
Jul 31 16:25:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 31 17:15:57 dinpaydg_cc kernel: INFO: task oracle:4147 blocked for more than 120 seconds.
Jul 31 17:15:57 dinpaydg_cc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[root@dinpaydg_cc log]#

资源使用分析
sar -r 查看发现这一段时间的内存使用情况,已使用内存的百分数(%memused)非常高,已使用交换空间的百分数(%swapused)比例也在个位数到40%直接,服务器在10:31重启,10:00 到10:30之间的数据没有,不清楚什么原因导致。从这些数据也可以看出内存资源非常紧张。

另外也用sar -u查看了CPU,CPU使用率不高。基本正常,当时忘记查看I/O和传送速率的统计信息(现在去查看,已经看不到昨天的数据了),另外在message日志里面看到有"ata2.00: status: { DRDY ERR }", "ata2.00: qc timeout(cmd 0xa0)"; 之类的错误信息

【内存有瓶颈】一直99%以上
[root@dinpaydg_cc log]# sar -r
Linux 2.6.32-573.12.1.el6.x86_64 (dinpaydg_cc) 07/31/2019 _x86_64_ (16 CPU)
10:50:02 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
11:00:01 AM 355288 65617760 99.46 150040 63419688 2689968 3.27
11:10:01 AM 354528 65618520 99.46 150088 63423884 2690020 3.27
11:20:01 AM 367640 65605408 99.44 150136 63412012 2689880 3.27
11:30:01 AM 362712 65610336 99.45 150088 63419560 2689976 3.27
11:40:01 AM 368524 65604524 99.44 150084 63411952 2690108 3.27
11:50:01 AM 347320 65625728 99.47 149712 63434068 2689940 3.27
12:00:01 PM 351676 65621372 99.47 149792 63426180 2689956 3.27
12:10:01 PM 356232 65616816 99.46 149924 63415948 2689944 3.27
12:20:01 PM 355240 65617808 99.46 150068 63416388 2689804 3.27
12:30:01 PM 368880 65604168 99.44 150048 63401996 2690048 3.27
12:40:01 PM 359596 65613452 99.45 150104 63413688 2690104 3.27
12:50:01 PM 350048 65623000 99.47 150172 63427012 2689940 3.27
01:00:01 PM 349784 65623264 99.47 150080 63417960 2690072 3.27
01:10:01 PM 362572 65610476 99.45 149996 63401240 2690092 3.27
01:20:01 PM 351272 65621776 99.47 150068 63414564 2689928 3.27
01:30:01 PM 350668 65622380 99.47 150272 63422528 2690012 3.27
01:40:01 PM 352900 65620148 99.47 150252 63412152 2690120 3.27
01:50:01 PM 366284 65606764 99.44 150116 63384588 2690016 3.27
02:00:01 PM 363068 65609980 99.45 150276 63397584 2690048 3.27
02:10:01 PM 368648 65604400 99.44 149992 63376084 2690120 3.27
02:20:01 PM 369268 65603780 99.44 149928 63373840 2690008 3.27
02:30:01 PM 362060 65610988 99.45 149820 63376720 2690012 3.27
02:40:01 PM 367160 65605888 99.44 149712 63383124 2690120 3.27
02:50:01 PM 360448 65612600 99.45 149276 63370696 2689952 3.27
03:00:01 PM 358000 65615048 99.46 149408 63372396 2690012 3.27
03:10:01 PM 359588 65613460 99.45 147528 63255224 2689944 3.27
03:20:01 PM 351660 65621388 99.47 147348 63241720 2690072 3.27
03:30:01 PM 355504 65617544 99.46 146716 63225352 2689952 3.27
03:40:01 PM 369560 65603488 99.44 147140 63211492 2682996 3.26
03:50:02 PM 365856 65607192 99.45 147276 63221384 2682936 3.26
04:00:01 PM 350200 65622848 99.47 147108 63235804 2685272 3.26
04:10:02 PM 359236 65613812 99.46 147284 63215036 2682936 3.26
04:20:01 PM 348992 65624056 99.47 147220 63184804 2683064 3.26
04:30:01 PM 348712 65624336 99.47 147492 63182200 2682868 3.26
04:40:01 PM 363872 65609176 99.45 147200 63189104 2683104 3.26
04:50:01 PM 355796 65617252 99.46 147840 63249792 2682868 3.26
05:00:01 PM 351828 65621220 99.47 147484 63243968 2682996 3.26
05:10:01 PM 368956 65604092 99.44 147996 63236072 2682984 3.26
05:20:01 PM 364492 65608556 99.45 147844 63237672 2683060 3.26
05:30:01 PM 350464 65622584 99.47 147632 63239828 2682912 3.26
05:40:01 PM 360896 65612152 99.45 148100 63253944 2683084 3.26
05:50:01 PM 366972 65606076 99.44 149312 63276300 2683028 3.26
06:00:01 PM 361516 65611532 99.45 150500 63310344 2682912 3.26
06:10:01 PM 355424 65617624 99.46 150628 63336856 2682980 3.26
06:20:01 PM 348836 65624212 99.47 150708 63356368 2682984 3.26
06:30:01 PM 351704 65621344 99.47 150700 63358596 2682912 3.26
06:40:01 PM 357428 65615620 99.46 151420 63355612 2687860 3.26
06:50:01 PM 350732 65622316 99.47 151608 63366176 2687856 3.26
Average: 358674 65614374 99.46 143847 63371864 2688699 3.26
[root@dinpaydg_cc log]#

参考帖子,感谢
Linux服务器宕机案例第二则
https://www.cnblogs.com/kerrycode/p/5653586.html
故障报错之/proc/sys/kernel/hung_task_timeout_secs
https://blog.csdn.net/weixin_43279032/article/details/87718804

more than 120 seconds|hung_task_timeout_secs 什么鬼?的更多相关文章

  1. hung_task_timeout_secs 和 blocked for more than 120 seconds

    https://help.aliyun.com/knowledge_detail/41544.html 问题现象 云服务器 ECS Linux 系统出现系统没有响应. 在/var/log/messag ...

  2. hung_task_timeout_secs和blocked for more than 120 seconds的解决方法

    Linux系统出现hung_task_timeout_secs和blocked for more than 120 seconds的解决方法 Linux系统出现系统没有响应. 在/var/log/me ...

  3. Linux系统出现hung_task_timeout_secs和blocked for more than 120 seconds的解决方法

    Linux系统出现系统没有响应. 在/var/log/message日志中出现大量的 “echo 0 > /proc/sys/kernel/hung_task_timeout_secs" ...

  4. Linux 日志报错 xxx blocked for more than 120 seconds

    监控作业发现一台服务器(Red Hat Enterprise Linux Server release 5.7)从凌晨1:32开始,有一小段时间无法响应,数据库也连接不上,后面又正常了.早上检查了监听 ...

  5. INFO: task java:27465 blocked for more than 120 seconds不一定是cache太大的问题

    这几天,老有几个环境在中午收盘后者下午收盘后那一会儿,系统打不开,然后过了一会儿,进程就消失不见了,查看了下/var/log/message,有如下信息: Dec 12 11:35:38 iZ23nn ...

  6. task mysqld:26208 blocked for more than 120 seconds

    早上10点左右,某台线上ECS服务器突然没响应. 查看日志,发现如下信息: Aug 14 03:26:01 localhost rsyslogd: [origin software="rsy ...

  7. kernel: INFO: task sadc:14833 blocked for more than 120 seconds.

    早上一到,发现oracle连不上. 到主机上,发现只有oracleora11g一个进程,其他进程全没了. Nov 14 23:33:30 hs-test-10-20-30-15 kernel: INF ...

  8. linux 出错 “INFO: task xxxxxx: 634 blocked for more than 120 seconds.”的3种解决方案(转)

    linux 出错 “INFO: task xxxxxx: 634 blocked for more than 120 seconds.”的3种解决方案 1 问题描述 服务器内存满了,ssh登录失败 , ...

  9. linux 出错 “INFO: task java: xxx blocked for more than 120 seconds.” 的3种解决方案

    1 问题描述 最近搭建的一个linux最小系统在运行到241秒时在控制台自动打印如下图信息,并且以后每隔120秒打印一次. 仔细阅读打印信息发现关键信息是“hung_task_timeout_secs ...

随机推荐

  1. 【转】浅谈命令查询职责分离(CQRS)模式

    原文链接:https://www.cnblogs.com/yangecnu/p/Introduction-CQRS.html 在常用的三层架构中,通常都是通过数据访问层来修改或者查询数据,一般修改和查 ...

  2. spinand之data buffer

    data buffer简介 spinand一般会有一个内置的data buffer. 以W25N01GV为例,一个page是2048bytes外加64bytes的spare数据,其data buffe ...

  3. Java DAO 模式

    转载自https://www.runoob.com/note/27029 DAO 模式 DAO (DataAccessobjects 数据存取对象)是指位于业务逻辑和持久化数据之间实现对持久化数据的访 ...

  4. 数据库索引的优化及SQL处理过程

    想要设计出好的索引,首先必须了解SQL语句在数据库服务器中的处理过程,本文介绍数据库索引设计与优化中几个对索引优化非常重要的概念. 谓词 谓词就是条件表达式. SQL语句的where子句由一个或者多个 ...

  5. R的获取和安装

    一.下载 R可以在CRAN(Comprehensive r archive network)http://cran.r-project.org上免费下载,可供选择的有Linux.Mac OS X和wi ...

  6. Image 缩略图

    方法一:通过调用Image对象的自带方法GetThumbnailImage()进行图片转换. /// <summary> /// 生成缩略图重载方法,返回缩略图的Image对象 /// & ...

  7. C# 使用System.Media.SoundPlayer播放wav格式的声音文件

    using System.Media; string szPath = Application.StartupPath + “\\SoundFile\\sound.wav”; SoundPlayer ...

  8. 对python函数后面有多个括号的理解?

    一般而言,函数后面只有一个括号.如果看见括号后还有一个括号,说明第一个函数返回了一个函数,如果后面还有括号,说明前面那个也返回了一个函数.以此类推. 比如fun()() def fun(): prin ...

  9. 一分钟理解Java公平锁与非公平锁

    本人免费整理了Java高级资料,涵盖了Java.Redis.MongoDB.MySQL.Zookeeper.Spring Cloud.Dubbo高并发分布式等教程,一共30G,需要自己领取.传送门:h ...

  10. django-channels的部署(supervisor+daphne+nginx)

    项目中需要一个聊天室的功能,所以需要websocket通信,选择了使用channels模块,主要记录下channels部署的配置和一些坑. 原项目是通过nginx+uwsgi部署的,这里我没做任何改动 ...