高IO負荷でrrdgraph生成が失敗する

私たちは4コアのCPUプロダクションシステムを使用しており、多くのcronジョブを実行します。一定のprocキューと通常の負荷は〜1.5です。

夜間は、postgresでIOを集中的に使用します。負荷/メモリ使用量を示すグラフを生成します（rrd-updates.sh）。これは、高IO負荷の状況で時々「失敗」します。ほぼ毎晩発生していますが、すべての高IO状況では発生しません。

私の "通常の"解決策は、postgresを適切にイオン化し、グラフ生成のプリオを増やすことです。しかし、これはまだ失敗します。グラフ生成は、flockを使用したセミスレッドプルーフです。私は実行時間をログに記録します。グラフ生成では、高IO負荷時に最大5分であり、結果として最大4分間グラフが失われるようです。
タイムフレームはpostgresアクティビティと正確に一致します（これは1日中に発生することもありますが、それほど頻繁ではありません）。 ）は問題を解決しませんでした。

データが収集されないと仮定すると、追加の問題は、どういうわけかまだ機能していないiceice / niceです。
90％のIOwaitと100のロードがあっても、5秒以上の遅延なしで（少なくともテストでは）、データ生成コマンドを無料で使用できました。

悲しいことに、テストでこれを正確に再現できませんでした（仮想化された開発システムのみ）

バージョン：

カーネル2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3 ハードウェア：ハードウェアRAID1
マウントオプションのLVMを備えたSAS 15K RPM HDD ：ext3とrw、errors = remount-ro
スケジューラー：CFQ
crontab：

* * * * *               root    flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh

RetcacheのgithubにOetiker氏からのsomhowに関連している可能性のあるバグがあるようです：https :
//github.com/oetiker/rrdtool-1.x/issues/326

これは実際には私の問題（同時書き込み）である可能性がありますが、cronジョブが失敗しないことを説明していません。仮定では、実際に2つの同時書き込みflock -nがあると、終了コード1が返されます（テストで確認されたmanページごと）。出力も電子メールで届かず、cronjobが他の時間に実際に正常に実行されるという観察どういうわけか失われました。

出力例：

コメントに基づいて、更新スクリプトの重要なソースを追加しました。

rrdtool update /var/rrd/cpu.rrd $(vmstat 5 2 | tail -n 1 | awk '{print "N:"$14":"$13}')
rrdtool update /var/rrd/mem.rrd $(free | grep Mem: | awk '{print "N:"$2":"$3":"$4}')
rrdtool update /var/rrd/mem_bfcach.rrd $(free | grep buffers/cache: | awk '{print "N:"$3+$4":"$3":"$4}')

何を見逃すか、どこでさらに確認できますか？

覚えておいてください：生産的なシステムなので、開発、スタックトレース、または同様のものが利用可能またはインストール可能ではありません。

グラフを更新できないのはrrdtoolではなく、この時点ではデータを測定できないためです。ちなみに、CPUとメモリの統計情報を測定する方法は、すぐに結果が得られるため、間違っています。CPUとメモリの負荷は60秒間隔で大幅に変化する可能性がありますが、1つの値しか取得しません。間隔での平均データを提供するSNMPデータを取得することを検討する必要があります。さらに、パイプ全体がsnmpget呼び出しよりも高価で遅くなるようです。ギャップの主な理由である可能性があります。