資源の消費

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 18章サーバの構成 | 早送り | 次のページ

# 18.4. 資源の消費

## 18.4.1. メモリ

`shared_buffers`（`整数`）

  データベースサーバが使用する共有メモリバッファのために使用するメモリ量を設定します。 デフォルトは典型的には32メガバイト(`32MB`)ですが、使用するカーネルの設定が（initdbの過程で）そこまでをサポートしていなければより少なくなることがあります。この設定は最低限128キロバイトなければなりません。（デフォルト以外の`BLCKSZ`ではこの最小値は変わります。）しかし、良い性能を引き出すためには、最小値よりかなり高い値の設定が通常必要です。実運用のインストレーションでは数十メガバイト程度の値を推奨します。このパラメータはサーバ起動時のみ設定可能です。

  このパラメータを増加させると、PostgreSQLは使用しているオペレーティングシステムのデフォルト構成が許容するSystem V共有メモリの限界を越えた要求を行う要因となることがあります。必要であれば、どの様にしてこのパラメータを調整するかについて項17.4.1を参照ください。

`temp_buffers`（`整数`）

  それぞれのデータベースセッションが使用する一時バッファの最大数を設定します。 これらは一時テーブルにアクセスする時にのみ使用されるセッション局所バッファです。 デフォルトは8メガバイト（`8MB`）です。 設定はそれぞれのセッション内で変更できますが、セッション内の一時テーブルが最初に使用するまでになります。 引き続いて値の変更を試みても、そのセッションでは効果がありません。

  セッションは`temp_buffers`で与えられた限度まで、必要とする分一時バッファを割り当てます。実際には多くの一時バッファを必要としないセッションで、大きな値を設定する代償は`temp_buffers`での増分毎に、バッファ記述子用の分、もしくは約64バイトです。とは言っても、バッファが実際に使用されると、それに対して追加の8192バイト（もしくは、通常`BLCKSZ`バイト）が消費されます。

`max_prepared_transactions`（`整数`）

  同時に"プリペアド"状態におけるトランザクションの最大数を設定します。 （PREPARE TRANSACTIONを参照してください。） このパラメータをゼロ（これがデフォルトです）に設定すると、プリペアドトランザクション機能を無効にします。 デフォルトは5トランザクションです。 このパラメータはサーバ起動時のみに設定可能です。

  プリペアドトランザクションを使用しないのであれば、このパラメータはプリペアドトランザクションが偶然に作成されないようゼロに設定されなければなりません。プリペアドトランザクションを使用する場合、全てのセッションがプリペアドトランザクションを保留できるように、`max_prepared_transactions`を最低max_connectionsと同じ大きさに設定しても構いません。

  このパラメータを増加させると、使用しているオペレーティングシステムのデフォルト構成が許容するSystem V共有メモリの限界を越えた要求を PostgreSQLが行う原因となることがあります。必要であれば、どの様にしてこのパラメータを調整するかについて項17.4.1を参照ください。

`work_mem`（`整数`）

  一時ディスクファイルに切替える前に、内部並べ替えとハッシュテーブル操作が使用するメモリ容量を指定します。 デフォルト値は1メガバイト（`1MB`）です。 複雑な問い合わせの場合、いくつかの並び替えもしくはハッシュ操作が並行して実行されることに注意してください。それぞれは、データを一時メモリに置く以前にこの値が指定したと同じ大きさのメモリ使用が認められます。さらに、いくつかの実行中のセッションはこれらの動作を同時に行います。したがって、使用されるメモリの合計は、`work_mem`の数倍になります。値を選択する時には、この事実に留意することが必要です。並び替え操作は`ORDER BY`、`DISTINCT`、およびマージ結合に対して使われます。ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、および`IN`副問い合わせのハッシュに基づいた処理で使用されます。

`maintenance_work_mem`（`整数`）

  `VACUUM`、`CREATE INDEX`、および`ALTER TABLE ADD FOREIGN KEY`の様な保守操作で使用されるメモリの最大容量を指定します。 デフォルト値は16メガバイト（`16MB`）です。 1つのデータベースセッションでは、一度に1つしか上記操作はできませんし、通常インストレーションでこうした操作が同時に非常に多く発生することはありませんので、これを`work_mem`よりもかなり多めの値にしても安全です。 大きい値を設定することでvacuum処理と、データベースダンプのリストアの性能が向上します。

  オートバキュームを稼動させると、最大autovacuum_max_workers倍ほどこのメモリーが配分されるので、デフォルトの値をあまり高く設定しないよう注意することを覚えておいてください。

`max_stack_depth`（`整数`）

  サーバの実行スタックの最大安全深度を指定します。 このパラメータの理想的な設定はカーネルにより強要される実際のスタック容量の（`ulimit -s`もしくは局所での同等の値で設定された）限界から、1メガバイト程度の安全余地を差し引いたものです。 安全余地は、スタック深度はサーバが各ルーチンで検査をせず、数式評価などの主要な潜在的に再帰的なルーチンの場合のみのため、必要となるものです。 デフォルト設定は2メガバイト（`2MB`）で、かなり控え目で、クラッシュの危険はなさそうです。 とは言っても、複雑な関数の実行を許容するには小さ過ぎるかも知れません。 スーパーユーザのみがこの設定を変更することができます。

  `max_stack_depth`を実際のカーネルの制限よりも高い値に設定した場合、暴走した再帰関数により、個々のバックエンドプロセスがクラッシュするかもしれません。 PostgreSQLによりカーネルの制限を決定することができるプラットフォームでも、この変数を危険な値に設定させません。 しかし、すべてのプラットフォームがこの情報を提供できるわけではありません。 このため、値を選ぶ時には注意が必要です。

## 18.4.2. カーネル資源使用

`max_files_per_process`（`整数`）

  それぞれのサーバ子プロセスが同時にオープンできるファイル数の最大値をセットします。 デフォルトは1000ファイルです。 もしもカーネルがプロセス毎の安全制限を強要している場合、この設定を気にかける必要はありません。 しかし、いくつかのプラットフォーム（特にほとんどのBSDシステム）では、非常に多くのプロセス全てが多くのファイルを開こうとした時に、カーネルは個々のプロセスがシステムが実際にサポートできるファイル数より多くを開くことを許しています。 もしも"Too many open files"エラーが発生した場合、この設定を減少してみてください。 このパラメータはサーバ起動時のみ設定可能です。

`shared_preload_libraries` (`文字列`)

  この変数はサーバが稼働する時点で事前に読み込まれなければならない1つもしくはそれ以上の共有ライブラリを指定します。 複数のライブラリをロードする場合は、ライブラリ名をコンマで区切ってください。 たとえば、`'$libdir/mylib'`は`mylib.so`（一部のプラットフォームでは`mylib.sl`）をインストレーションの共有ライブラリディレクトリから事前読み込みします。 このパラメータはサーバ起動時にのみ設定可能です。

  PostgreSQLの手続き言語ライブラリはこのようにして、典型的には構文`'$libdir/plXXX'`を使用し、事前読み込みされます。 ここで、`XXX`は`pgsql`、`perl`、`tcl`、もしくは`python`です。

  共有ライブラリを事前読み込みすることで、ライブラリが最初に使用される時、ライブラリの立上り時間を省略できます。 とは言っても、それぞれの新規サーバプロセスを開始させる時間は、そのプロセスがライブラリを使用しないとしても、多少増加することがあります。 ですから、このパラメータはほとんどのセッションで使用されそうなライブラリにのみ限定することをお勧めします。

  > 注意: Windowsでは、サーバ起動時にライブラリを事前読み込みしても、新しいサーバプロセスの起動に要する時間は減りません。 各サーバプロセスは事前に読み込まれたライブラリをすべて、再度読み込みます。 しかし、`shared_preload_libraries`はWindowsホストでも有用です。 共有ライブラリの中には、postmaster起動時にのみ特定の操作を行わなければならないものがあるためです。 （例えば、共有ライブラリは、postmasterの起動が終わった後に実行することができない、軽量ロックや共有メモリの予約を行う必要があるかもしれません。）

  指定したライブラリが存在しないと、サーバの起動に失敗します。

  PostgreSQLがサポートするライブラリはすべて、互換性を保証するために検査される"マジックブロック"を持ちます。 このため、この方法でPostgresQL以外のライブラリが読み込まれることはありません。

## 18.4.3. コストに基づくVacuum遅延

VACUUM および ANALYZE コマンドの実行中、実行される各種I/O操作の予測コストを追跡し続ける内部加算器をシステムが保守します。累積されたコストが（`vacuum_cost_limit`で指定された）限度に達すると、操作を実行しているプロセスは（`vacuum_cost_delay`で指定された）ちょっとの間スリープします。その後、加算器をリセットし、実行を継続します。

この機能の目的は、同時的データベース活動に対するこれらのコマンドのI/Oに対する影響を管理者から軽減させます。`VACUUM` および `ANALYZE`の様な保守用コマンドが、即座に終了することが対して重要でない情況が多くあります。とは言っても、他のデータベースの操作を行うに当たってこれらのコマンドがシステムの能力に多大な阻害を与えないことは通常とても重要です。コストに基づいたvacuum遅延はこれを実現するための方法を管理者に提供します。

手動で`VACUUM`コマンドを実行することができるように、デフォルトでこの機能は無効になっています。 有効にするには、`vacuum_cost_delay`変数をゼロでない値に設定します。

`vacuum_cost_delay`（`整数`）

  コストの限度を越えた場合、プロセスがスリープするミリ秒単位の時間の長さです。 デフォルトの値は0で、コストに基づいたvacuum遅延機能を無効にします。 正の整数はコストに基づいたvacuumを有効にします。 多くのシステムで、スリープ遅延の有効な分解能は10ミリ秒です。 `vacuum_cost_delay`の値の設定を10の倍数としない場合、次に大きい10の倍数に設定した結果と同一になるかもしれないことを覚えておいてください。

  コストに基づいたバキューム処理を使用する場合、`vacuum_cost_delay`の適切な値は通常かなり小さくなり、たいていは10または20ミリ秒になります。 バキュームによるリソース消費の調整は、他のバキュームのコストパラメータを変更して行うことが最善です。

`vacuum_cost_page_hit`（`整数`）

  共有バッファキャッシュの中のバッファにvacuumを掛ける予測コストです。バッファプールのロック、共有ハッシュテーブルの検索、およびページ内容走査のコストを示します。デフォルトの値は1です。

`vacuum_cost_page_miss`（`整数`）

  ディスクから読み込まれなければならないバッファにvacuumを掛ける予測コストです。これが示すものは、バッファプールロックの試み、共有ハッシュテーブルの参照、ディスクから目的ブロックの読み込み、そしてその内容走査です。デフォルトの値は10です。

`vacuum_cost_page_dirty`（`整数`）

  vacuumが、先だって掃除したブロックを変更する時に果たされた予測コストです。ダーティブロックを再度ディスクに吐き出すのに必要な余分なI/Oを表します。デフォルトの値は20です。

`vacuum_cost_limit`（`整数`）

  vacuumを掛けるプロセスをスリープさせることになる累計されたコストです。デフォルトの値は200です。

> 注意: 重要なロックを保有し可能なかぎり早急に完了しなければならないある種の操作があります。コストに基づいたvacuum遅延はこの様な操作では起こりません。したがって、コストの累計が指定された限度をかなり高く越える可能性があります。このような場合無駄な長い遅延を防止するため、実際の遅延は以下の様にして計算されます。 `vacuum_cost_delay` * `accumulated_balance` / `vacuum_cost_delay` * 4 の最大値を所有する `vacuum_cost_limit`

## 18.4.4. バックグラウンドライタ

バックグラウンドライタと呼ばれる分離したサーバプロセスがあり、その機能は"ダーティ"共有バッファの書き込み処理を行うことです。 その目的は、ユーザの問い合わせに対応しているサーバプロセスは発生する書き込みを、バックグラウンドライタが受け持つことにより、ほぼ待状態にならないようにすることです。 しかし、繰り返し変更されるページでは、これがないとチェックポイント間隔に一度だけ書き出される可能性がありましたが、バックグラウンドライタは同じ間隔内で複数回書き出しますので、全体としてのI/O負荷は多くなります。 本節で説明したこのパラメータはサイト独自の必要に応じて動作を変更することに使用できます。

`bgwriter_delay`（`整数`）

  バックグラウンドライタの動作周期間の遅延を指定します。 それぞれの周期でライタは、（以下のパラメータで管理される）一部のダーティバッファの書き込みを行います。 そして`bgwriter_delay`ミリ秒スリープした後、これを繰りかえします。 デフォルトの値は200ミリ秒（`200ms`）です。 多くのシステムで、スリープ遅延の実精度は10ミリ秒です。 `bgwriter_delay`の値の設定を10の倍数としない場合、次に大きい10の倍数に設定した結果と同一になるかもしれないことを覚えておいてください。 このパラメータは`postgresql.conf`ファイル内、または、サーバのコマンドラインで設定可能です。

`bgwriter_lru_maxpages`（`整数`）

  それぞれの周期で、この数以上のバッファはバックグランドライタにより書き込まれません。 ゼロに設定することで（チェックポイント活動を除く）バックグランド書き込みは無効になります。 デフォルト値は100バッファです。 このパラメータは`postgresql.conf`ファイル内、または、サーバのコマンドラインでのみで設定可能です。

`bgwriter_lru_multiplier` (`浮動小数点`)

  各周期で書き出されるダーティバッファ数は、最近の周期でサーバプロセスが必要とした新しいバッファ数を基にします。 次の周期で必要となるバッファ数を推定するために、最近必要とされた平均が`bgwriter_lru_multiplier`と掛け合わせられます。 ダーティバッファの書き出しは、同数の整理済み、再利用可能なバッファが利用できるようになるまで行われます。 （しかし1周期に`bgwriter_lru_maxpages`を越えるバッファ数を書き出しません。） したがって、1.0と設定することは、必要と予想されるバッファ数の書き込みについて"必要なときに必要なだけ"というポリシーを表します。 より大きな値は突発的な要求に対する多少の緩衝材を提供します。 より小さな値はサーバプロセスでなされる書き込みを意図的に残します。 デフォルトは1.0です。 このパラメータは`postgresql.conf`ファイル内、または、サーバのコマンドラインでのみで設定可能です。

`bgwriter_lru_maxpages`および`bgwriter_lru_multiplier`の値がより少ないと、バックグラウンドライタで引き起こされる追加のI/O負荷を軽減しますが、サーバプロセスが自分自身で行わなければならない書き込みが増加することになり、会話型問い合わせを遅らせることになります。

## 18.4.5. 非同期動作

`effective_io_concurrency` (`整数`)

  PostgreSQLが同時処理を予定している同時実行ディスクI/O作業の数を設定します。この値を大きくすると、あらゆる個別のPostgreSQLセッションが平行して開始を試みるI/O作業数が増加します。許容範囲は1から1000まで、または非同期I/Oリクエストの発行を無効にするゼロです。

  この設定の開始点として優れた値は、データベースに使用されるRAID 0ストライプ、RAID 1ミラーを構成する個々のドライブ数です。 RAID 5ではパリティ用のドライブを数に含めてはなりません。） しかし、同時実行セッションで発行される複数の問い合わせでデータベースが頻繁にビジーとなる場合、ディスクアレイのビジー率を抑えるために、より小さな値で十分であるかもしれません。 ディスクビジー率を抑えるために必要な値より大きな値を設定しても、余計なCPUオーバーヘッドを発生させるだけです。

  メモリベースのストレージやバス帯域幅で制限されたRAIDアレイなどの、より斬新なシステムにおける正しい値は利用できるI/Oパスの数となるかもしれません。 最善の値を見つけ出すには、何らかの実験が必要かもしれません。

  非同期I/Oは実質的に`posix_fadvise`関数に依存します。 これは一部のオペレーティングシステムには存在しません。 この関数が存在しない場合、この値をゼロ以外に設定するとエラーとなります。 一部のオペレーティングシステム（例えばSolaris）では存在するけれども、実際何も行わないものもあります。

前のページ | ホーム | 次のページ
接続と認証 | 上に戻る | ログ先行書き込み（WAL）