次のようなバックアップスクリプトがあります。
これがコアスクリプトです:
Nice -n 15 tar -czvf $BKP $PATH_BKP/*.* \
| xargs -I '{}' sh -c "test -f '{}' && md5sum '{}'" \
| tee $MD5
scp -l 80000 $BKP $SCP_BKP
scp $MD5 $SCP_BKP
このルーチンは、gzipルーチンでCPUを90%にしたため、本番サーバーの速度が低下しました。 Nice -n 15
を追加しようとしましたが、サーバーがハングします。
私はすでに 1 を読みましたが、会話は私を助けませんでした。
この問題を解決するための最良のアプローチは何ですか?私は新しいアーキテクチャ/ソリューションを受け入れています:)
Niceを使用する場合は、優先度を変更しますが、これは、CPUの使用率が100%に近い場合にのみ顕著な影響を及ぼします。
あなたの場合、CPU使用率のためではなく、ストレージのI/Oのために、サーバーが遅くなります。 ionice
を使用してI/O優先度を変更し、CPU優先度としてNice
を維持します。
chrtを使用して、tarプログラムのスケジューリングポリシーをSCHED_BATCHに変更してみてください。
Manページによるsched_setscheduler(2)
SCHED_BATCH:バッチプロセスのスケジューリング(Linux 2.6.16以降)SCHED_BATCHは、静的優先度0でのみ使用できます。このポリシーは、動的優先度(Nice値に基づく)に従ってプロセスをスケジュールするという点でSCHED_OTHERに似ています。違いは、このポリシーにより、スケジューラーは常にプロセスがCPUを集中的に使用すると想定することです。その結果、スケジューラーはウェイクアップ動作に関して小さなスケジューリングペナルティを適用するため、このプロセスはスケジューリングの決定においてやや不利になります。
This policy is useful for workloads that are noninteractive, but do not want to lower their Nice value, and for workloads that want a determin‐ istic scheduling policy without interactivity causing extra preemptions (between the workload's tasks).
それでも運が悪い場合は、代わりにSCHED_IDLEを試すことができます。これにより、このプログラムは、実行するものが他にない場合にのみウェイクアップします。
これにより、バッチのタールラインが次のように変更されます。
Nice -n 15 chrt -b tar -czvf $BKP $PATH_BKP/*.* \
Gzipの代わりにpigzを使用してみましたか?