この問題の私の視点は開発者の視点です。私が書いたコードは、エンタープライズシステムの複数の仮想マシンの1つとして実行されているRHEL仮想マシンに配置されました。使用されるファイルシステムはリモートネットワーク接続ストレージデバイスです。
バッチ処理中、単純なコマンドには多くの可変性があります。だから私たちはより多くの情報を得るためにテストを準備しましたが、今は私たちが何を見つけたのかわかりません。
30分ごとに次のコマンドを実行し、出力を記録します。 6GBファイルのコピーです。システムが多くのジョブを実行していて、このテストコマンドのCPU時間が低いときに、実行時間が11秒から190秒にジャンプするのを見ました。
CPUが低いときは「I」列(ファイルシステム入力)が満たされ、CPUが高いときは満たされないことがわかります。 「w」列(非自発的な交換)もはるかに高いです。
私の質問は、CPU時間が短くなり、長すぎるように実行すると、このタスク/コマンドに何が起こるのかということです。スワップイン/スワップアウトすると、はるかに遅い他のデバイスにすべてのデータが保存されますか?通常、スワップイン/アウト中に何が起こりますか?
実行コマンド:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
日付 | 時間 | 金利 | S | ゆう | 人 | 氏 | 勝つ | 私 | 酸素 |
---|---|---|---|---|---|---|---|---|---|
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
これはあなたの例に限定されないかもしれませんが、質問に対するより一般的な答えです。Generally, what happens during a swap in/out?
これらのいくつかは一般的なものなので、メモリ管理に関する博士論文を書くのを避けるために、多くの部分を混乱させました。
簡単に言えば、メモリ管理についてです。容器の内側と容器の外側に分けられます。まず、ディスクからデータを読み取る非常に簡単なケースを見てみましょう。まず、システムはデータを読み取っている変数を調べて、カーネルにその分のメモリスペースを要求します。新しく起動したシステムにあるため、カーネルは簡単にメモリを割り当ててプロセスに渡し、ディスクからメモリに値をコピーできます。シンプルで簡単で高速です。
それでは、いくつかの複雑さを追加しましょう。システムがますます多くの作業を開始するほど、CPUは忙しくなります(明らかに!)。これは、メモリ管理と直接的な関係はありませんが、どのプロセスがCPUタイムスライスを取得するかに関するものです。最も理解しやすいスケジューラはラウンドロビンスケジューラです。カーネルは、CPUサイクルを要求するプロセスのリストを調べ、リストに表示される順序で各プロセスに同じサイクル数を提供します。これは通常、リストに自分自身を追加する順序です。次に、プロセス優先順位の概念を追加します。これは、いくつかの特別なプロセスが他のプロセスよりも早くリストの一番上に到達することを意味します。一般に、このタイプのコマンド(cp
)は優先順位が非常に低く、ほとんどの時間がディスクの応答を待つのに費やされるため、CPU時間をあまり頻繁に必要としません。
しかし、ネットワークストレージからデータを読み取るときにディスクデバイスにデータの提供を要求するだけでなく、ネットワークインターフェイスに代わりにタスクを実行するように要求するため、待ち時間が長くなります。繰り返しますが、メモリ管理の議論と直接的な関係はありませんが、ネットワークディスクはローカルディスクよりも遅いため、I / O要求が完了するのを待つプロセスに時間がかかります。
今しばらく運営されてきたシステムを見てみましょう。ほとんどの場合、「空き」メモリ値が予期せず非常に低いことがわかります。これは、LinuxがRAMを無駄にするという意味ですか?別言します。メモリ消費の一部はディスクキャッシュです。Linuxは私のメモリをすべて占めています!これに関する背景知識を得る。
メモリ使用量が高いもう一つの理由は、Linuxが怠惰であるということです。 Linux は不要な作業を行いません。その1つは、メモリページを「使用可能」リストに戻すことです。プロセスがメモリページの使用を終了すると、カーネルはページを「clean」としてマークしますが、「used」リストには残ります。これは、ページが他のプロセスですぐに再利用できることを意味するだけです。ページは「ダーティー」と表示されることもあります。これは、そのメモリを使用するプロセスがそのメモリの使用を終了し、ディスクに書き換えるように要求しましたが、他のプロセスはその特定のページを必要としないため、Linuxは待機します。実際、他の人がそれをディスクにフラッシュしてページを利用可能としてマークするには、この情報が必要です。これはディスクキャッシュで最も一般的ですが、ファイルの書き込みでも表示できます。
したがって、私たちのシステムには「free」リストには何もありませんが、「clean」と「dirty」リストには多くのページがあります。少しメモリを必要とする新しいプロセスが登場し、Linuxは「clean」または「dirty」リストから十分に大きなスペースブロックを見つける必要があります。汚れた場合は、そのページをディスクに強制的にフラッシュする必要があります。人間の観点からは、これは「フリー」リストからページを割り当てるのと同様にすぐに発生しますが、コンピュータの観点からは実際にははるかに長くかかります。
あなたの場合、コンテナ自体は新しいものであり、コンテナ内のすべてのメモリは「利用可能」ですが、コンテナを実行しているオペレーティングシステムには「利用可能」メモリがほとんど残っていない可能性があり、代わりに「クリーン」「ダーティ」ページ割り当てリストがあります。 。システムの使用量が多いと、ダーティページのリフレッシュがより頻繁に発生し、IOレイテンシが増加し、メモリ割り当て時間も増加します。
最も重要なことは、システムが正常に動作することです。実行中の他のすべてのプロセス、特に所有している優先順位の高いプロセスを心配している間に時間がかかるcp
(システムとユーザーの時間スライスの増加)など、重要ではないプロセスを作成する必要があります。time
はい、実際にはLinuxメモリ管理に関する博士論文を書くことが可能です。それほど複雑です。