この問題に対する私の見解は開発者側からのものです。私は、エンタープライズ システム内の多数の仮想マシンの 1 つとして実行される RHEL 仮想マシンに配置されるコードを作成します。使用されているファイル システムは、リモートのネットワーク接続ストレージ デバイスです。
バッチ処理中に単純なコマンドに大きなばらつきがありました。そのため、より多くの情報を取得するためにテストを設定しましたが、今のところ何がわかったのかわかりません。
次のコマンドを 30 分ごとに実行し、出力を記録しました。これは 6 GB のファイルのコピーです。システムが多数のジョブを実行していてビジー状態であり、このテスト コマンドの CPU 時間が低い場合、経過時間が 11 秒から 190 秒に跳ね上がっていることがわかります。
私が確認できたのは、列「I」(ファイルシステム入力) は CPU が低いときには入力されますが、高いときには入力されないということです。列「w」(不本意なスワップ) もかなり高くなっています。
私の質問は、CPU 時間が減ったときにこのジョブ/コマンドを非常に長く実行させる原因となっているのは何かということです。スワップイン/スワップアウトは、そのデータをすべて、はるかに遅い他のデバイスに保存しますか? 一般的に、スワップイン/スワップアウト中に何が起きますか?
実行中のコマンド:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| 日付 | 時間 | e | ス | あなた | ポ | c | わ | 私 | お |
|---|---|---|---|---|---|---|---|---|---|
| 2022年3月14日 | 5:19:02 | 64.9 | 16.23 | 1.03 | 26% | 3005 | 29210 | 12000016 | 12000000 |
| 2022年3月14日 | 5:49:02 | 12.7 | 11.63 | 0.79 | 97% | 2069 | 76 | 0 | 12000000 |
| 2022年3月14日 | 6:19:02 | 100.39 | 14.74 | 0.78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 2022年3月14日 | 6:49:24 | 191.32 | 18.86 | 0.94 | 10% | 3374 | 36164 | 12001024 | 12000000 |
| 2022年3月14日 | 7:19:02 | 71.61 | 15.61 | 0.88 | 23% | 1610 | 30316 | 12000296 | 12000000 |
| 2022年3月14日 | 7:49:02 | 70.73 | 17.5 | 0.91 | 26% | 1408 | 29540 | 12000072 | 12000000 |
| 2022年3月14日 | 8:19:02 | 10.95 | 9.89 | 0.7 | 96% | 1709 | 75 | 0 | 12000000 |
| 2022年3月14日 | 8:49:02 | 11.01 | 10.22 | 0.73 | 99% | 239 | 85 | 0 | 12000000 |
/usr/bin/timeのマニュアルページの列の説明
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
答え1
このコンテキストの P は、このジョブが経過した合計時間に対する CPU 時間の比率を意味します。100% に近いということは、ほぼすべての時間が CPU 上で行われ、そのためこれらの実行では CPU が制限されていたことを意味します。他の何かが制限要因であった他の実行とは対照的です。I/O を多用するタスクではよくあることですが、システム時間よりもシステム時間 (つまりカーネル時間) の方が長くなります。
ワークロードが 6 GB のファイルをコピーすることであったことを考えると、11 秒間の実行で平均 0.5 GB を超える書き込みが 1 秒あたり行われたと推測できます。O 列は、毎回同じ数の書き込みが行われていることを示しており、これは単純な 1 つのファイルのコピー プロセスと一致しています。
ただし、入力列には大きな変動があります。低速実行では、書き込みと読み取りがほぼ同数です。しかし、高速実行では読み取りは行われません。ファイルは、最後に読み取られたときから RAM にキャッシュされていると想定しています。DRAM は、ソリッド ステート ストレージよりもはるかに高速です。これは、メモリの負荷がかかって OS がキャッシュされたデータをドロップし、低速ストレージから再度読み取る必要があるまで、速度を大幅に向上させます。
これは 200 秒かかるタスクですが、場合によっては 12 秒かかることもあります。これは Linux ページ キャッシュが原因と考えられます。
パフォーマンスの問題の根本原因を見つけるには、多くの場合、特定のメトリックセットを超えて、システム全体をより深く理解する必要があります。
使用されているファイルシステムは、リモートのネットワーク接続ストレージ デバイスです。
コピーはネットワーク ストレージ経由で行われるため、リモート システム上またはその間のネットワーク上のものもコピーの対象になる可能性があることに注意してください。リモート ストレージのパフォーマンス。ネットワーク (おそらく IP) の速度と使用率。または、この VM のローカルで、ゲストがインフラストラクチャ上で実行されている他のすべてのものとリソースを競合している可能性もあります。
仕組みをもっと深く掘り下げることはいつでも可能です。ネットワーク ストレージ (NFS?) はまったく関係ありませんか、それともローカル ディスクでも関係しますか? ユーザーの CPU 時間が 0.7 秒というのは、実際にはかなりの作業量です。多くのシステム コールを管理するには、どれくらいの時間がかかりますか? その大部分が低速のメモリと非常に低速のストレージを待機している場合、CPU ビジーとは実際には何を意味しますか? 答えるのは簡単な質問ではありませんが、適切に機能するようになったら、あまり深く掘り下げる必要はないかもしれません。