Description of the problem
A recently built linux minimum system when running the automatic printing below 241 seconds in the console, and after every 120 seconds to print again.
Carefully read the information found in print key information is " hung_task_timeout_secs ", first encountered such a problem, first of all Baidu ...
Look through multiple users blog, found this to be a bug linux kernel of. Explain on this issue are also more consistent, paragraph excerpt:
By default Linux uses up to 40% of the available memory for file system caching.
After this mark has been reached the file system flushes all outstanding data to disk causing all following IOs going synchronous.
For flushing out this data to disk this there is a time limit of 120 seconds by default.
In the case here the IO subsystem is not fast enough to flush the data withing 120 seconds.
This especially happens on systems with a lot of memory.
The problem is solved in later kernels。
Translation: Under normal circumstances, linux 40% of the space will be used as a cache memory of the file system. When the buffer is almost full, the file system will synchronize the entire data cache to disk. However, the system has the maximum limit of 120 seconds synchronization time. If the file system data synchronization can not be completed within the time limit, the above-described error occurs. This usually occurs on a large memory system. Large system memory, the buffer is large, the longer the time required for data synchronization, the greater the probability of a timeout.
2 solution
Solutions provided by users who are basically three kinds, namely, the effect of three kinds of programs to verify the test.
2.1 shrink the file system cache size
Such a scheme is to reduce the proportion of total memory cache , for example, from 40% to 10%, so needs to be synchronized to the amount of data on the disk will be smaller, IO write time is shortened, it will be relatively stable.
The file system cache size by kernel parameters vm.dirty_ratio and vm.dirty_backgroud_ratio decision control.
vm.dirty_background_ratio specify what percentage of the time when the number of dirty pages to reach the file system cache memory systems (such as 5%) will trigger pdflush / flush / kdmflush and other written background processes running back, a certain cache dirty pages asynchronously brush into the outer deposit.
vm.dirty_ratio specify when the number of dirty pages to the file system cache memory system to achieve what percentage of time (eg 10%), the system had to start processing the cache dirty pages (because the number of dirty pages have more, in order to avoid data loss page needs to be some dirty brush into the external memory), in the process many application process because the system might turn to deal with file IO blocked.
Typically, a value greater than the value vm.dirty_ratio of vm.dirty_background_ratio.
Below that the modification process and the effect of these two parameters.
The current value of the vm.dirty_ratio and vm.dirty_ background_ratio of (1) First check system.
在shell命令行中输入如下指令：
sysctl -a | grep dirty- 1
由上图可知，当前环境下，vm.dirty_ratio=20 ，vm.dirty_ background_ratio=10。在此情况下，会出现上述问题。
（2）修改vm.dirty_ratio和vm.dirty_ background_ratio的值。
把vm.dirty_ratio修改为10 ，vm.dirty_background_ratio修改为5。在命令行输入如下命令：
./sbin/sysctl -w vm.dirty_ratio=10
./sbin/sysctl -w vm.dirty_background_ratio=5- 1
- 2
（3）查看修改是否成功。
在命令行输入（1）中的指令即可。 
由上图可知，参数修改成功。
（4）使参数修改立即生效。
在命令行输入如下指令即可。
sysctl -p- 1
（5）观察测试结果。
经过以上操作，缩减文件系统缓存之后，上述问题成功解决。
2.2 修改系统IO调度策略
Linux的IO共有三种调度器：CFQ、noop、deadline。每个调度器都有其优点。
CFQ （Completely Fair Scheduler（完全公平调度器））（cfq）：它是许多Linux 发行版的默认调度器；它将由进程提交的同步请求放到多个进程队列中，然后为每个队列分配时间片以访问磁盘。
Noop调度器（noop）：基于先入先出（FIFO）队列概念的Linux内核里最简单的I/O调度器。此调度程序最适合于SSD。
截止时间调度器（deadline）：尝试保证请求的开始服务时间。
Linux发行版的默认采用的是cfq调度器。此方案就是把cfq调度器修改为最简单的noop调度器。
下面说一下修改调度器的流程。
（1）查看当前采用的调度器。
在命令行中输入如下指令：
cat /sys/block/sda/queue/scheduler- 1
由内核返回信息可知，当前采用的是cfq调度器。
（2）修改调度器。
在命令行中输入如下指令：
echo noop >/sys/block/sda/queue/scheduler- 1
（3）查看修改是否成功。
在命令行中输入如（1）的指令。 
由内核返回信息可知，调度器修改成功。
调度器的修改是立即生效的，不必重启内核。
（4）观察测试结果。
修改完成后，让系统继续运行一段时间。上述问题依然存在。所以此方案对本文的案例不起作用。对于其他案例是否起作用需要自己按照上述方式测试才能得知。
2.3 取消120秒时间限制
此方案就是不让系统有那个120秒的时间限制。文件系统把数据从缓存转到外存慢点就慢点，应用程序对此延时不敏感。就是慢点就慢点，我等着。实际上操作系统是将这个变量设为长整形的最大值。
下面说一下内核hung task检测机制由来。我们知道进程等待IO时，经常处于D状态，即TASK_UNINTERRUPTIBLE状态，处于这种状态的进程不处理信号，所以kill不掉，如果进程长期处于D状态，那么肯定不正常，原因可能有二：
1）IO路径上的硬件出问题了，比如硬盘坏了(只有少数情况会导致长期D，通常会返回错误)；
2）内核自己出问题了。
这种问题不好定位，而且一旦出现就通常不可恢复，kill不掉，通常只能重启恢复了。
内核针对此种情况开发了一种hung task的检测机制，基本原理是：定时检测系统中处于D状态的进程，如果其处于D状态的时间超过了指定时间(默认120s，可以配置)，则打印相关堆栈信息，也可以通过proc参数配置使其直接panic。
如何修改或者取消120秒的时间限值呢。120秒的时间限值由内存参数kernel.hung_task_timeout_secs决定的。直接像方案一那样修改此内核参数的值就可。如果kernel.hung_task_timeout_secs的值设置为0，那就是把此种设置为长整型的最大值。
下面说一下修改调度器的流程。
（1）查看当前hung_task_timeout_secs值。
在命令行中输入如下指令：
sysctl -a | grep hung_task_timeout_secs- 1
有内核返回信息，可知当前设置的hung_task超时时间为120秒。
（2）修改hung_task_timeout_secs值。
把hung_task_timeout_secs的值修改为0，在命令行中输入如下指令：
./sbin/sysctl -w kernel.hung_task_timeout_secs=0- 1
- 2
（3）查看修改是否成功。
在命令行输入（1）中的指令即可。
（4）使参数修改立即生效。
在命令行输入如下指令即可。
sysctl -p- 1
（5）观察测试结果。
经过以上操作，取消120秒时间限值之后，上述问题成功解决。
2.4 总结
经过上边的测试，可知对与本案例缩减文件系统缓冲大小和取消120秒时间限值均可以解决问题。但是取消120秒的时间限值会允许系统不可切换任务的出现。综合考虑决定采用方案1，即缩减文件系统的缓冲区大小。
3 永久修改内核参数
在上述方案中采用sysctl可以修改内核参数，但是这只是临时修改，上电重启后又会恢复回之前的参数。那么如何才能够永久修改内核参数呢？
可以修改系统信息配置文件sysctl.conf，此配置文件在/etc目录下。打开配置文件在最后添加如下两行代码：
vm.dirty_background_ratio=5
vm.dirty_ratio=10- 1
- 2
保存后重启系统，查看配置是否成功。
如果系统没有sysctl.conf文件，就像我的最小linux系统一样，则可以自己创建sysctl.conf。
在/etc目录下，采用vi指令：vi sysctl.conf新建sysctl.conf文件，然后输入如下代码后保存退出。
重启之后查看vm.dirty_ratio和vm.dirty_background_ratio的值，发现又恢复成之前的了。
这是因为开机启动时系统没有读取sysctl.conf文件进行配置。可以通过修改启动文件来解决。
以我使用的linux系统为例，启动文件是/etc/init.d/rcS。采用指令vi /etc/init.d/rcS打开rcS文件，在最末尾添加如下代码：./sbin/sysctl -p
保存后退出。reboot重启可以看到内核打印信息中有如下信息： 
进入控制台后，查看vm.dirty_ratio和vm.dirty_background_ratio的值，可知内核参数永久修改成功。
[Reference]
1, Linux Kernel Crash-hung_task_timeout_secs Author: plums inaction
http://blog.csdn.net/napolunyishi/article/details/17576739
2, How to FIX hung_task_timeout_secs and blocked More Within last for 120 seconds The problem of: Skate
HTTP: //blog.csdn.net/wyzxg/article/details/44236263
3, to amend sysctl.conf, how to make the entry into force of the document after a system reboot: dagebudagegeda
http://blog.csdn.net/u010616985/article/details / 44,563,931
4, the file system cache dirty_ratio and dirty_background_ratio difference of two parameters: Vincent
http://blog.sina.com.cn/s/blog_448574810101k1va.html
5, once the kernel hung task analysis: humjb_1983
HTTP: // Blog. chinaunix.net/uid-14528823-id-4406510.html