高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 …