他のバージョンの文書10 | 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

17.4. 資源の消費

17.4.1. メモリ

shared_buffersinteger

データベースサーバが使用する共有メモリバッファの数を設定します。デフォルトは典型的には1000ですが、使用するカーネルの設定が(initdbの過程で)そこまでをサポートしていなければより少なくなることがあります。サーバを構築する際に異なったBLCKSZの値を選択しなかった限りでは、それぞれのバッファは8192バイトです。最低限の設定は16でなければならず、また max_connectionsの値の2倍以上が必要です。とは言っても、良い性能を引き出すためには、最小値よりかなり高い値の設定が通常必要です。実運用のインストレーションでは数千程度の値を推奨します。このオプションはサーバ起動時のみ設定可能です。

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

temp_buffersinteger

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

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

max_prepared_transactionsinteger

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

準備されたトランザクションを使用しないのであれば、このパラメータも同様にゼロに設定されます。使用する場合、準備段階での無駄な支障を回避するためmax_prepared_transactionsを少なくともmax_connectionsと同じ大きさにしても構いません。

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

work_meminteger

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

maintenance_work_meminteger

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

max_stack_depthinteger

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

17.4.2. 開放領域マップ

これらパラメータは、データベースの未使用領域の場所を追跡し、共有開放領域マップの大きさを管理します。マップに記載の無い開放領域は再使用されないため、通常より小さくされた開放領域は、時間の経過につれ、データベースが増加するディスク領域容量を消費する原因になります。PostgreSQLは、そうはしないで、新規データの格納が必要になった場合、オペレーティングシステムに大きなディスク領域を要求します。データベースに渡るVACUUM VERBOSEコマンドが表示する最後の数行は、現在の設定が適切でない時の助けになります。現在の設定が著しく小さい場合、NOTICEメッセージが、この操作の実行中同様に表示されます。

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

max_fsm_pagesinteger

開放領域が共有開放領域マップ内でで追跡されるディスクページの最大数を設定します。6バイトの共有メモリがそれぞれのページスロットで消費されます。この設定は、16 * max_fsm_relationsより大きくなければなりません。デフォルトは20000です。このオプションはサーバ起動時のみ設定可能です。

max_fsm_relationsinteger

開放領域が共有開放領域マップ内で追跡されるリレーション(テーブルとインデックス)の最大数を設定します。おおよそ、70バイトの共有メモリがそれぞれのスロットに対して消費されます。デフォルトは1000です。このオプションはサーバ起動時のみ設定可能です。

17.4.3. カーネル資源使用

max_files_per_processinteger

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

preload_librariesstring

この変数はサーバが稼働する時点で事前に読み込まれなければならない1つもしくはそれ以上の共有ライブラリを指定します。各ライブラリについて、オプションとしてパラメータのない初期化関数を呼び出すことができます。これを指定するために、ライブラリ名の後にコロンと、初期化関数の名前を付け加えます。例えば、'$libdir/mylib:mylib_init'は、 mylibが事前に読み込まれるようにし、そしてmylib_initが実行されるようにします。もし複数のライブラリを読み込ませるのであれば、それらの名前をコンマで区切ってください。

もし指定されたライブラリ、もしくは初期化関数が見つからない場合、サーバは稼働に失敗します。

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

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

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

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

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

デフォルトでこの機能は無効になっています。有効にするには、vacuum_cost_delay変数をゼロでない値に設定します。

vacuum_cost_delayinteger

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

vacuum_cost_page_hitinteger

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

vacuum_cost_page_missinteger

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

vacuum_cost_page_dirtyinteger

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

vacuum_cost_limitinteger

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

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

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

PostgreSQL 8.0から、バックグラウンドライタと呼ばれる分離したサーバプロセスがあり、その唯一の機能は"ダーティ"共有バッファの書き込み処理を行うことです。その目的は、ユーザの問い合わせに対応しているサーバプロセスは発生する書き込みを、バックグラウンドライタが受け持つことにより、ほぼ待状態にならないようにすることです。また、これを設置することで、チェックポイントに関する性能への束縛を低減させることができます。各チェックポイントにてそれまでのダーティバッファをまとめて扱うのではなく、チェックポイント時刻に達した時に強制的に書き出さなければならないページが数個程度になるように、バックグラウンドライタは断続的にダーティページをディスクに書き出します。しかし、繰り返し変更されるページでは、これまではチェックポイント間隔に一度書き出されていましたが、バックグラウンドライタは同じ間隔内で複数回書き出しますので、全体としてのI/O負荷は多くなります。ほとんどの場合、定期的にピークがある負荷よりも継続的に低い負荷の方が好まれます。しかし、本節で説明したこのパラメータはサイト独自の必要に応じて動作を変更することに使用できます。

bgwriter_delayinteger

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

bgwriter_lru_percentfloating point

サーバプロセスがそれ自身の書き込みを行わなければならない頻度を減少させるため、バックグラウンドライタは、遅かれ早かれ再利用されると思われるバッファの書き込みを試みます。それぞれの周期内で、再利用されるのに最も近いバッファのbgwriter_lru_percentまで試験し、全てのダーティバッファを書き込みます。デフォルトの値は10です(これは共有バッファの総数の百分比です)。このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。

bgwriter_lru_maxpagesinteger

それぞれの周期で、間もなく再利用されるバッファの走査の結果、この数のバッファ以上は書き込まれません。デフォルトの値は5です。このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。

bgwriter_all_percentfloating point

チェックポイント時に必要な仕事量を削減するため、バックグラウンドライタは同時に、バッファプール全体に周回走査を行い、ダーティと認められたバッファを書き込みます。それぞれの周期で、この目的のためバッファのbgwriter_all_percentまで試験をします。デフォルトの値は 0.333 です(これは共有バッファの総数の百分比です)。デフォルトのbgwriter_delay設定で、約1分に一度共有バッファ全体が走査されることになります。このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。

bgwriter_all_maxpagesinteger

それぞれの周期において、バッファプール全体の走査の結果として、これ以上多いバッファは書き込まれません。(この限度に到達すると、走査は中止され、そして次の周期の間の次のバッファで再び開始されます。)デフォルトの値は5です。このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。

bgwriter_all_percentbgwriter_all_maxpagesの値がより少ないと、バックグラウンドライタで引き起こされる追加のI/O負荷を軽減しますが、チェックポイント時に行われるべき仕事をより多く残します。チェックポイント時の負荷による妨害を削減するには、この2つの値を増加させます。同様にしてbgwriter_lru_percentおよびbgwriter_lru_maxpagesの値がより少ないと、バックグラウンドライタで引き起こされる追加のI/O負荷を軽減しますが、おそらく、サーバプロセスは自分自身に対して書き込みを行わざるを得ず、会話型問い合わせを送らせることになります。バックグラウンド書き込みを完全に無効にするには、maxpagespercentの両方の値をゼロに設定します。