問題の説明
最近建てられたLinuxの最小システムは、コンソールで241秒以下の自動印刷を実行し、すべての120秒後に再び印刷するとき。
慎重に情報が印刷キー情報で見つかった読みが「あるhung_task_timeout_secs」、最初の最初のすべてのBaiduの、このような問題に遭遇しました...
複数のユーザーに目を通すが、これはバグのLinuxカーネルであることが判明し、ブログ。この問題について説明し、また、段落の抜粋より一貫しています。
デフォルトでは、Linuxはファイル・システム・キャッシングのために利用可能なメモリの40％まで使用しています。
このマークに達した後のファイルシステムには、以下のすべてのIOSが同期行くの原因とディスクへのすべての未処理データをフラッシュします。
ディスクにこのデータを洗い流すために、このデフォルトで120秒の時間制限があります。
ここでの場合はIOサブシステムは、120秒をwithingデータをフラッシュするに十分な速さではありません。
これは、特に多くのメモリを搭載したシステムで発生します。
問題は、以降のカーネルで解決されます。
翻訳：通常の状況下では、スペースのLinuxの40％は、ファイルシステムのキャッシュメモリとして使用されます。バッファがほぼいっぱいになった場合、ファイルシステムは、ディスクへのデータキャッシュ全体を同期します。しかし、システムは、120秒の同期時間の最大限界を有します。ファイル・システム・データの同期が制限時間内に完了できない場合、上記のエラーが発生します。これは通常、大容量のメモリシステムで発生します。大規模なシステム・メモリ、バッファが大きい場合、より長い時間は、データ同期、大きいタイムアウトの可能性のために必要。
2溶液
基本的に3つの種類があり、ユーザーが提供するソリューションは、つまり、プログラムの3種類の効果は、テストを確認します。
2.1ファイルシステムキャッシュのサイズを縮小
そのようなスキームは、合計メモリキャッシュの割合を低減するために IO書き込み時間を短くする必要がディスク上のデータの量に同期させるように、40％から10％まで、例えば、小さくなり、それは比較的安定です。
カーネルパラメータによって、ファイルシステムのキャッシュサイズvm.dirty_ratioとvm.dirty_backgroud_ratio判定制御。
vm.dirty_background_ratio、ダーティページの数が（例えば5％など）のファイル・システム・キャッシュ・メモリ・システムに到達する時間の割合がpdflush /フラッシュ/ kdmflushとバックを実行している他の書かれたバックグラウンドプロセスをトリガするかを指定する特定のキャッシュのダーティページを非同期外側に磨きます預金。
vm.dirty_ratioダーティページの数は避けるのデータ損失のために、より多く持っているので、ファイル・システム・キャッシュ・メモリ・システムへのダーティページの数は時間の何パーセント（例えば10％）を達成したときに指定すると、システムは、（キャッシュのダーティページの処理を開始しなければなりませんでしたページには、システムがIOがブロックされたファイルを扱うためになるかもしれないので、プロセスの多くのアプリケーションプロセスでは、）外部メモリにいくつかの汚れをブラシにする必要があります。
典型的には、vm.dirty_background_ratioの値vm.dirty_ratioより値が大きくなります。
変更プロセスおよびこれら2つのパラメータの効果も低いです。
（1）最初のチェックシステムのvm.dirty_ratioとvm.dirty_ background_ratioの現在値。
在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的值，可知内核参数永久修改成功。
[参考]
1、Linuxカーネルのクラッシュ-hung_task_timeout_secs著者：不作為プラム
http://blog.csdn.net/napolunyishi/article/details/17576739
スケート：どのようにFIXのhung_task_timeout_secsへと2は、120秒の問題のために最後の中でより多くのブロックされた
HTTP： //blog.csdn.net/wyzxg/article/details/44236263
3、システムの再起動後に文書の発効を作る方法を、sysctl.confのを修正する：dagebudagegeda
http://blog.csdn.net/u010616985/article/details / 44563931
4、ファイル・システム・キャッシュdirty_ratioと2つのパラメータdirty_background_ratio違い：ヴィンセント
http://blog.sina.com.cn/s/blog_448574810101k1va.html
5、カーネルハングタスク分析に一度：humjb_1983
HTTP：//ブログ。 chinaunix.net/uid-14528823-id-4406510.html