タグ付けされた質問 「ionice」

rsyncがシステムとネットワークを枯渇させないようにするために、rsyncをionice起動して--bwlimitパラメーターを設定するときに使用します。例えば： ionice -c2 -n7 rsync -aH --bwlimit=30000 /foo root@dest.com:/ これは確かに、ソースサーバーの応答性を維持するのに役立ちます。ただし、ディスクioが100％であるため、宛先atopユーティリティは非常に遅くなります（ユーティリティで確認）。 ionice宛先サーバーでも何らかの形で使用することは可能ですか？おそらくrsync -eオプション経由ですか？可能であれば、rsyncデーモンを実行しないことを希望します。

14 rsync  high-load  rate-limiting  ionice 

Linuxプロセスは、異なるCPUとIOの優先順位（niceとionice）を持つことができます。 CPUとIOの優先度を変える必要があるのはなぜですか？ それらを異なるものにするための実際の使用法はありますか？ 異なるCPUとIOの優先順位が必要な実世界のユースケースは何ですか？通常のCPU優先度よりも高いが、通常のIO優先度よりも低い、ま​​たはその逆。

9 linux  nice  ionice 

私たちは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 …

8 linux  debian  io  rrdtool  ionice 

ビジーなサイト用に非常に大きな（マルチGB）Nginxキャッシュディレクトリがあり、一度にすべてをクリアする必要がある場合があります。キャッシュフォルダーを新しいパスに移動し、古いパスに新しいキャッシュフォルダーを作成しrm -rf、古いキャッシュフォルダーを使用することで、これを以前に解決しました。 しかし、最近、忙しい朝にキャッシュをクリアする必要がある場合rm -rf、Nginxとその前にあるサーバーの両方が読み取り集中型であるため、I / O がサーバーアクセスのディスクアクセスを枯渇させています。CPUがアイドル状態にありrm -rf、ディスクIOの98〜99％を占める間に、負荷平均の上昇を観察できiotopます。 をionice -c 3呼び出すときに試しましたrmが、観測された動作にそれほど影響はないようです。 rm -rfさらにディスクを共有するために飼いならす方法はありますか？手がかりを得る別のテクニックを使用する必要がありioniceますか？ 更新： 問題のファイルシステムはAWS EC2インスタンスストアです（プライマリディスクはEBSです）。/etc/fstabエントリは次のようになります。 /dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2

8 linux  hard-drive  io  rm  ionice