リソース上限制御の統計を報告するには、rcapstat を使用します。rcapstat によるリソース使用効率のモニタリング コマンドを使って報告を生成する方法については、Monitoring Resource Utilization With rcapstatを参照してください。このセクションでは、報告の列見出しについても説明します。rcapstat(1) のマニュアルページにも、この情報が含まれています。
このセクションでは、さまざまな目的の報告を生成する方法を、例を使用しながら説明します。
この例では、2 人のユーザーに関連付けられた 2 つのプロジェクトに、上限が定義されています。user1 の上限は 50M バイト、user2 の上限は 10M バイトです。
次のコマンドは、5 つの報告を 5 秒間のサンプリング間隔で生成します。
user1machine% rcapstat 5 5
id project cappd nproc vm rss cap at avgat pg avgpg
112270 user1 Yes 24 123M 35M 50M 50M 0K 3312K 0K
78194 user2 Yes 1 2368K 1856K 10M 0K 0K 0K 0K
id project cappd nproc vm rss cap at avgat pg avgpg
112270 user1 Yes 24 123M 35M 50M 0K 0K 0K 0K
78194 user2 Yes 1 2368K 1856K 10M 0K 0K 0K 0K
id project cappd nproc vm rss cap at avgat pg avgpg
112270 user1 Yes 24 123M 35M 50M 0K 0K 0K 0K
78194 user2 Yes 1 2368K 1928K 10M 0K 0K 0K 0K
id project cappd nproc vm rss cap at avgat pg avgpg
112270 user1 Yes 24 123M 35M 50M 0K 0K 0K 0K
78194 user2 Yes 1 2368K 1928K 10M 0K 0K 0K 0K
id project cappd nproc vm rss cap at avgat pg avgpg
112270 user1 Yes 24 123M 35M 50M 0K 0K 0K 0K
78194 user2 Yes 1 2368K 1928K 10M 0K 0K 0K 0K
出力の最初の 3 行は 1 回目の報告です。ここには、2 つのプロジェクトに関する上限とプロジェクトの情報、および rcapd 起動以降のページング統計が記載されています。at と pg の列において、user1 にはゼロより大きな値が入っており、user2 にはゼロが入っています。これは、1 回目の報告の期間中、user1 は上限を超えたが、user2 は超えなかったことを意味します。
2 回目以降の報告では、目立った活動はありません。
この例では、プロジェクト user1 を使用しています。このプロジェクトには RSS 上限を超えた RSS が 1 つあります。
次のコマンドは、5 つの報告を 5 秒間のサンプリング間隔で生成します。
user1machine% rcapstat 5 5
id project cappd nproc vm rss cap at avgat pg avgpg 376565 user1 Yes 3 6249M 6144M 6144M 690M 220M 5528K 2764K 376565 user1 Yes 3 6249M 6144M 6144M 0M 131M 4912K 1637K 376565 user1 Yes 3 6249M 6171M 6144M 27M 147M 6048K 2016K 376565 user1 Yes 3 6249M 6146M 6144M 4872M 174M 4368K 1456K 376565 user1 Yes 3 6249M 6156M 6144M 12M 161M 3376K 1125K
プロジェクト user1 は 3 つのプロセスを持っており、それぞれがアクティブに物理メモリーを使用しています。pg 列の正の値が示しているとおり、rcapd は、このプロジェクトのプロセスの物理メモリーの使用率を上限に合わせて下げようと、メモリーをページアウトし続けています。しかし、rcapd は RSS を上限値未満に保つことに成功していません。これは、rss 値が相応の減少を示していないことでわかります。作業負荷はメモリーをページアウトするとすぐにまたメモリーを使用しており、その結果、RSS の値がまた上がってしまいます。これは、プロジェクトの常駐メモリーがすべてアクティブに使用されており、かつ、作業セットサイズ (WSS) が上限よりも大きいことを意味します。そのため、rcapd は、上限に合わせて作業セットの一部をページアウトせざるを得ません。この状況では、次のうちのいずれかが起きるまで、システムのページフォルト率および関連する入出力は高いままです。
WSS が小さくなる。
上限を上げる。
アプリケーションのメモリーアクセスパターンが変わる。
この状況では、サンプリング間隔を短くすることで、RSS 値と上限値の差を小さくできる可能性があります。rcapd が作業負荷をサンプリングして上限を制限する頻度が上がるからです。
この例では、前の例と同じプロジェクトを使用します。
前の例では、プロジェクト user1 が自分に許可された上限よりも多くの物理メモリーを使用しているところを示しました。この例では、どれくらいのメモリーをプロジェクトの作業負荷が必要とするのかを示します。
user1machine% rcapstat 5 5
id project cappd nproc vm rss cap at avgat pg avgpg
376565 user1 Yes 3 6249M 6144M 6144M 690M 0K 689M 0K
376565 user1 Yes 3 6249M 6144M 6144M 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6171M 6144M 27M 0K 27M 0K
376565 user1 Yes 3 6249M 6146M 6144M 4872K 0K 4816K 0K
376565 user1 Yes 3 6249M 6156M 6144M 12M 0K 12M 0K
376565 user1 Yes 3 6249M 6150M 6144M 5848K 0K 5816K 0K
376565 user1 Yes 3 6249M 6155M 6144M 11M 0K 11M 0K
376565 user1 Yes 3 6249M 6150M 10G 32K 0K 32K 0K
376565 user1 Yes 3 6249M 6214M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 Yes 3 6249M 6247M 10G 0K 0K 0K 0K
サイクルの中ほどで、プロジェクト user1 の上限を 6G バイトから 10G バイトに上げました。値を上げることによって上限の制限が止まり、常駐セットサイズが上昇しました。常駐セットサイズを規制するのは、ほかのプロセスと、システムのメモリー容量だけになりました。rss 列が、プロジェクトの作業セットサイズ (この例では 6247M バイト) を反映して安定する場合があります。この値が、このプロジェクトのプロセスがページフォルトを頻繁に起こさずに動作できる、上限の最小値です。
user1 の上限が 6G バイトであるとき、サンプリング間隔である 5 秒ごとに、rcapd が作業負荷のメモリーの一部をページアウトするにつれて、RSS は減少して入出力は増加します。ページアウトの直後、これらのページを必要とする作業負荷は、(動作し続ける限り) メモリーをページインします。このサイクルは、例の中ほどで上限を10G バイトに上げるまで繰り返されます。その後、RSS は 6.1G バイトで安定します。作業負荷の RSS が上限より低くなったため、これ以後ページングは発生しません。また、ページングに関連する入出力は止まります。このため、観察時にプロジェクトが行なっていた作業の実行には、6.1G バイトが必要であったことがわかります。
vmstat(1M) および iostat(1M) のマニュアルページも参照してください。