プロジェクトの作業セットサイズの決定
この例では、前の例と同じプロジェクトを使用します。
前の例では、プロジェクト user1 が自分に許可された上限よりも多くの物理メモリーを使用しているところを示しました。この例では、どれくらいのメモリーをプロジェクトの作業負荷が必要とするのかを示します。
user1machine% rcapstat 5 5
id project nproc vm rss cap at avgat pg avgpg
376565 user1 3 6249M 6144M 6144M 690M 0K 689M 0K
376565 user1 3 6249M 6144M 6144M 0K 0K 0K 0K
376565 user1 3 6249M 6171M 6144M 27M 0K 27M 0K
376565 user1 3 6249M 6146M 6144M 4872K 0K 4816K 0K
376565 user1 3 6249M 6156M 6144M 12M 0K 12M 0K
376565 user1 3 6249M 6150M 6144M 5848K 0K 5816K 0K
376565 user1 3 6249M 6155M 6144M 11M 0K 11M 0K
376565 user1 3 6249M 6150M 10G 32K 0K 32K 0K
376565 user1 3 6249M 6214M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
376565 user1 3 6249M 6247M 10G 0K 0K 0K 0K
|
サイクルの中ほどで、プロジェクト user1 の上限を 6G バイトから 10G バイトに上げました。値を上げることによって上限の制限が止まり、常駐セットサイズが上昇しました。常駐セットサイズを規制するのは、ほかのプロセスと、マシンのメモリー容量だけになりました。rss 列が、プロジェクトの作業セットサイズ (この例では 6247M バイト) を反映して安定する場合があります。この値が、このプロジェクトのプロセスがページフォルトを頻繁に起こさずに動作できる、上限の最小値です。
次の 2 つの図は、上限が 6G バイトと 10G バイトのときに、rcapd が user1 に与える影響を示しています。 サンプリング間隔である 5 秒ごとに、rcapd が作業負荷のメモリーの一部をページアウトすることによって、RSS が減り、入出力が増えます。ページアウトの直後、これらのページを必要とする作業負荷は、(動作し続ける限り) メモリーをページインします。このサイクルは、例の中ほどで上限を 10G バイトに上げるまで繰り返され、その後、RSS は 6.1G バイトで安定します。作業負荷の RSS が上限より低くなったため、これ以後ページングは発生しません。同様に、ページングに関連する入出力も止まります。このことは、vmstat (vmstat(1M)のマニュアルページを参照) コマンドまたは iostat ( iostat(1M)のマニュアルページ参照) コマンドで確認できます。以上のようにして、観察時にプロジェクトが行なっていた作業の実行には、6.1G バイトが必要であったと推論できます。
図 9–1 user1 の上限を WSS よりも大きくしたあとに RSS 値が安定する様子
図 9–2 ページインとページアウトの関係、および user1 の上限を上げたあとに入出力が安定する様子
- © 2010, Oracle Corporation and/or its affiliates