他のバージョンの文書9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

18.4. 資源の消費

18.4.1. メモリ

shared_buffers (integer)

データベースサーバが使用する共有メモリバッファのために使用するメモリ量を設定します。 デフォルトは一般的に32メガバイト(32MB)です。しかし、稼働中のカーネルの設定が(initdbの過程で決定されます)この値をサポートしていない場合、より少なくなることがあります。 この設定は最低限128キロバイトなければなりません。(デフォルト値以外のBLCKSZでこの最小値は変化します。)しかし、良い性能を引き出すためには、最小値よりかなり高い値の設定が通例必要です。このパラメータはサーバ起動時にのみ設定可能です。

1GBまたはそれより多いRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersに対し大きな値が有効であってもなんらかの作業負荷は存在します。 しかし、PostgreSQLは同時にオペレーティングシステムキャッシュを信頼しますので、shared_buffersにRAMの40%以上を割り当てても、より少ない量より動きがより良くなると言う見込みはありません。 shared_buffersをより大きく設定するは、通常対応するcheckpoint_segmentsを増やす必要があります。より長い期間にわたっての新規、または変更された多量のデータを書き出すプロセスを展開するためです。

1GB以下のRAMのシステムでは、オペレーティングシステムに十分な余裕を残せるため、より少ない比率のRAMが適切です。同時に、Windowsではshared_buffersに対し大きな値は有効でありません。設定を比較的少なく保ち、その代わりオペレーティングシステムのキャッシュを使用するとより良い結果が見つかります。Windowsシステムでのshared_buffersの範囲は一般的に64MBから512MBです。

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

temp_buffers (integer)

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

多くの一時バッファを実際に必要としないセッションで大きな値を設定するコストとは、temp_buffersの増分毎に、バッファ記述子分、バイトで言うと64バイトです。 しかし、バッファが実際に使用されると、それに対して追加の8192バイト(または、通常BLCKSZバイト)が消費されます。

max_prepared_transactions (integer)

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

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

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

スタンバイサーバを運用している場合、このパラメータはマスターサーバ上の設定よりも同等かもしくはより高水準に設定しなければなりません。そうしないと問い合わせがスタンバイサーバ内で受け入れられません。

work_mem (integer)

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

maintenance_work_mem (integer)

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

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

max_stack_depth (integer)

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

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

18.4.2. ディスク

temp_file_limit (integer)

あるセッションが暫定ファイルとして使用できるディスクの最大容量を設定します。 例えば、ソートやハッシュの一時ファイルであったり、カーソルを保持する格納ファイルです。 この値を超えようとするトランザクションは無視されます。値はキロバイト単位で指定され、(デフォルトである) -1 の場合は制限がありません。この設定はスーパユーザのみ可能です。

この設定により、ある与えられた PostgreSQL セッションにより使用される暫定ファイルの容量がいかなる場合にも制約されます。 問い合わせの実行に裏舞台で使用される暫定ファイルとは対抗するように、明示的暫定テーブルに使用されるディスク容量はこの制限に不利に作用することはありません

18.4.3. カーネル資源使用

max_files_per_process (integer)

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

shared_preload_libraries (string)

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

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

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

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

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

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

18.4.4. コストに基づくVacuum遅延

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

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

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

vacuum_cost_delay (integer)

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

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

vacuum_cost_page_hit (integer)

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

vacuum_cost_page_miss (integer)

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

vacuum_cost_page_dirty (integer)

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

vacuum_cost_limit (integer)

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

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

18.4.5. バックグラウンドライタ

バックグラウンドライタと呼ばれる個別のサーバプロセスがあり、その機能は(新規または更新された)"ダーティ"な共有バッファの書き込みを行うことです。 それは共有バッファを書き込むため、ユーザの問い合わせを処理するサーバプロセスは書き込みが発生するまでごくたまに、あるいは決して待ち状態になりません。 しかし、バックグラウンドライタはI/O読み込みに対し正味の全体的増加の原因になります。その理由は、繰り返しダーティ化されるページはチェックポイント間隔で一度だけ書き出される可能性がある一方、バックグラウンドライタは同じ間隔内でダーティ化されるごとにそれを複数回書き出します。 本節で説明したこのパラメータはサイト独自の必要に応じて動作を調整することに使用できます。

bgwriter_delay (integer)

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

bgwriter_lru_maxpages (integer)

それぞれの周期で、この数以上のバッファはバックグラウンドライタにより書き込まれません。 ゼロに設定することでバックグラウンド書き込みは無効になります。 (分離し、そして専用の補助プロセスにより管理されるチェックポイントは影響を受けません。) デフォルト値は100バッファです。 このパラメータはpostgresql.confファイル内、または、サーバのコマンドラインでのみで設定可能です。

bgwriter_lru_multiplier (floating point)

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

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

18.4.6. 非同期動作

effective_io_concurrency (integer)

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)では存在するけれども、実際何も行わないものもあります。