shared_buffers
(integer
)
#
データベースサーバが共有メモリバッファのために使用するメモリ量を設定します。
デフォルトは一般的に128メガバイト(128MB
)です。
しかし、稼働中のカーネルの設定がこの値をサポートしていない場合、より少なくなることがあります(initdbの過程で決定されます)。
この設定は最低限128キロバイトなければなりません。
しかし、良い性能を引き出すためには、最小値よりかなり高い値の設定が通例必要です。
この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZ
バイト、一般的には8kBです。
(BLCKSZ
がデフォルト値と異なる場合、この最小値も異なる値になります。)
このパラメータはサーバ起動時のみ設定可能です。
1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffers
に対する妥当な初期値はシステムメモリの25%です。
shared_buffers
をこれよりも大きな値に設定することが有効なワークロードもあります。
しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffers
にRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。
shared_buffers
をより大きく設定する場合は、大抵max_wal_size
も合わせて増やす必要があります。これは、新規または変更された多量のデータを書き出す処理をより長い時間に渡って分散させるためです。
1GB未満のRAMのシステムでは、オペレーティングシステムに十分な余裕を残すために、RAMに対してより小さい割合を設定することが適切です。
huge_pages
(enum
)
#
主共有メモリ領域に対してhuge pageを要求するかどうかを管理します。
可能な値はtry
(デフォルト)、on
、off
です。
huge_pages
をtry
に設定すると、サーバはhuge pageの要求を試み、失敗したらデフォルトに戻します。
on
にすると、要求に失敗した場合にサーバの起動ができなくなることになります。
off
ならhuge pageの要求は行いません。
今のところこの機能はLinuxとWindowsでのみサポートされています。
他のシステムではtry
と設定しても無視されます。
Linuxではこの機能はshared_memory_type
がmmap
(デフォルトです)に設定されている時にのみサポートされます。
huge pageを使うと、ページテーブルが小さくなり、メモリ管理に使用されるCPU時間が少なくなり、性能が向上します。 詳細は、19.4.5を見てください。
huge pageはWindowsではlarge pageとして知られています。 それを使用するには、PostgreSQLを実行するWindowsユーザアカウントに「メモリ中のロックページ」権限を与える必要があります。 ユーザに「メモリ中のロックページ」権限を与えるには、Windowsのグループポリシーツール(gpedit.msc)を利用できます。 Windowsサービスとしてではなく、スタンドアローンプロセスとしてデータベースサーバをコマンドプロンプトで起動するには、コマンドプロンプトを管理者として実行するか、ユーザアクセス管理(UAC)を無効にしておかなければなりません。 UACが有効ならば、通常のコマンドプロンプトは起動時にユーザの「メモリ中のロックページ」権限を剥奪します。
この設定は主共有メモリ領域にのみ影響することに注意してください。
Linux、FreeBSD、Illumosのようなオペレーティングシステムでは、PostgreSQLからの明示的な要求なしにhuge page(「super」 pageあるいは「large」pageとしての知られています)が通常のメモリ獲得の際に使用できます。
Linuxでは、これは「transparent huge pages」 (THP)と呼ばれています。
この機能は、あるLinuxバージョンのあるユーザにおいてPostgreSQLの性能低下をもたらすことが知られています。
ですから、この機能の利用は(huge_pages
の明示的な利用と違って)今の所推奨されていません。
huge_page_size
(integer
)
#
huge_pagesが有効なときにhuge pageのサイズを制御します。
デフォルトはゼロ(0
)です。
0
に設定すると、システムのデフォルトのhuge pageのサイズが使われます。
このパラメータはサーバ起動時のみ設定可能です。
現代の64ビットサーバアーキテクチャにおける可能な一般的なページサイズには以下が含まれます。
2MB
と1GB
(IntelとAMD)、16MB
と16GB
(IBM POWER)、64kB
、2MB
、32MB
そして1GB
(ARM)。
使い方とサポートに関する詳細な情報に関しては19.4.5を参照してください。
今の所Linuxでサポートされるデフォルトの設定値はありません。
temp_buffers
(integer
)
#
それぞれのデータベースセッションが使用する一時バッファの最大メモリ量を設定します。
一時バッファは、一時テーブルにアクセスする時にのみ使用されるセッションローカルのバッファです。
この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZ
バイト、一般的には8kBです。
デフォルトは8メガバイト(8MB
)です。
(BLCKSZ
が8kBでなければ、それに比例して増減します。)
設定はそれぞれのセッション内で変更できますが、そのセッション内で一時テーブルが最初に使用されるまでになります。それより後に値の変更を試みても、そのセッションでは効果がありません。
セッションは、temp_buffers
を上限として、必要に応じて一時バッファを確保します。
多くの一時バッファを実際に必要としないセッションで大きな値を設定するコストとは、temp_buffers
の増分毎に、1つのバッファ記述子、約64バイトだけです。
しかし、バッファが実際に使用されると、それに対して追加の8192バイト(汎用的に言えばBLCKSZ
バイト)が消費されます。
max_prepared_transactions
(integer
)
#同時に「プリペアド」状態にできるトランザクションの最大数を設定します(PREPARE TRANSACTIONを参照してください)。 このパラメータをゼロ(これがデフォルトです)に設定すると、プリペアドトランザクション機能が無効になります。 このパラメータはサーバ起動時のみ設定可能です。
プリペアドトランザクションの使用を意図しないのであれば、このパラメータはプリペアドトランザクションが偶然に作成されないようゼロに設定すべきです。
プリペアドトランザクションを使用する場合、全てのセッションがプリペアドトランザクションを保留できるように、max_prepared_transactions
を少なくともmax_connectionsと同じ大きさに設定するのが良いでしょう。
スタンバイサーバを運用している場合、このパラメータはプライマリサーバ上の設定よりも同等かもしくはより高水準に設定しなければなりません。そうしないと問い合わせがスタンバイサーバ内で受け入れられません。
work_mem
(integer
)
#
一時ディスクファイルに書き込む前に、問い合わせ操作(ソートやハッシュなど)で使用される最大メモリ量を設定します。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルト値は4MB(4MB
)です。
複雑な問い合わせでは、同時に複数のソート操作とハッシュ操作が実行される可能性があります。
各操作は通常、データを一時ファイルに書き込む前にこの値で指定された量のメモリを使用できます。
また、複数の実行中のセッションが同時にこのような操作を実行することもあります。
したがって、使用されるメモリの合計量はwork_mem
の数倍になる可能性があります。
値を選択する時には、この事実に留意することが必要です。
ソート操作はORDER BY
、DISTINCT
、およびマージ結合に対して使われます。
ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、メモ化(memoize)ノードおよびIN
副問い合わせのハッシュに基づいた処理で使用されます。
一般的に、ハッシュに基づく操作はソートに基づく操作よりも利用可能なメモリに敏感です。
ハッシュテーブルのメモリ制限は、work_mem
にhash_mem_multiplier
を乗算することで計算されます。
これにより、ハッシュに基づく操作では通常のwork_mem
に基づく量を超える量のメモリが使用される可能性があります。
hash_mem_multiplier
(floating point
)
#
ハッシュに基づく操作が利用できる最大のメモリ量を計算するために使用します。
最終的な制限はwork_mem
にhash_mem_multiplier
を掛けて決定されます。
デフォルト値は2.0で、ハッシュに基づく操作が通常のwork_mem
に基づく値の2倍使用することになります。
問い合わせ操作によって日常的にメモリ不足になるような環境、とりわけ単にwork_mem
を増やしたことによってメモリ逼迫(メモリ逼迫が典型的には間欠的なメモリ不足エラーの発生の形で起こる)が起きる場合にはhash_mem_multiplier
を増やすことを考慮してください。
デフォルトの2.0が色々なワークロードが混在している場合には効果的かも知れません。
より大きな2.0から8.0、あるいはそれ以上の設定はwork_mem
がすでに40MB以上に増やしてあるような環境で効果的かも知れません。
maintenance_work_mem
(integer
)
#
VACUUM
、CREATE INDEX
、およびALTER TABLE ADD FOREIGN KEY
の様な保守操作で使用されるメモリの最大容量を指定します。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルト値は64メガバイト(64MB
)です。
1つのデータベースセッションでは、一度に1つしか上記操作はできませんし、通常インストレーションでこうした操作が同時に非常に多く発生することはありませんので、これをwork_mem
よりもかなり多めの値にしても安全です。
大きい値を設定することでvacuum処理と、ダンプしたデータベースのリストア性能が向上します。
自動バキュームが稼働すると、最大でこのメモリのautovacuum_max_workers倍が配分されるので、デフォルトの値をあまり高く設定しないよう注意してください。 別の設定項目autovacuum_work_memで制御するのが良いかもしれません。
無効タプル識別子の集合に対しては、VACUUM
は最大でも1GB
までしか使用することができないことに注意してください。
autovacuum_work_mem
(integer
)
#
個々の自動バキュームワーカープロセスが使用する最大のメモリ量を指定します。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルトは-1で、maintenance_work_memが代わりに使われる設定になります。
別の文脈で実行されるVACUUM
にはこの設定は影響しません。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
無効タプル識別子の集合に対しては、自動バキュームは最大でも1GB
までしか使用することができません。
ですからautovacuum_work_mem
をそれ以上に指定しても、自動バキュームがテーブルを走査して収集できる無効タプルの数には影響を与えません。
vacuum_buffer_usage_limit
(integer
)
#
VACUUM
コマンドおよびANALYZE
コマンドで使用されるバッファアクセスストラテジの大きさを指定します。
0
を設定すると、それらの操作で任意の数のshared_buffers
を使用できることになります。
それ以外の場合は、有効なサイズは128 kB
から16 GB
までの範囲です。
指定されたサイズがshared_buffers
のサイズの1/8を超える場合、サイズは黙ってその値に制限されます。
デフォルト値は256 kB
です。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
このパラメータはいつでも設定できます。
このパラメータは、BUFFER_USAGE_LIMIT
オプションを渡すことによって、VACUUMおよびANALYZEに対して上書きできます。
設定を高くすると、VACUUM
およびANALYZE
の実行速度が速くなりますが、設定を高くしすぎると、他の多くの有用なページが共有バッファから削除されてしまう可能性があります。
logical_decoding_work_mem
(integer
)
#
デコードされた更新がローカルディスクに書かれる前にロジカルデコーディングが使用する最大のメモリ量を指定します。
これにより、ロジカルストリーミングレプリケーションの接続が使用する最大メモリが制限されます。
デフォルトは64メガバイト(64MB
)です。
個々のレプリケーション接続がここで指定した単一のバッファだけを使用し、インストールは通常たくさんの接続を並行して使わないので(max_wal_senders
で制限されます)、この値をwork_mem
よりもずっと大きくしても安全で、それによってデコードされた更新がディスクに書かれる量が削減されます。
max_stack_depth
(integer
)
#
サーバの実行スタックの最大安全深度を指定します。
このパラメータの理想的な設定はカーネルにより強要される実際のスタック容量の(ulimit -s
もしくはそれと同等の機能で設定された)限界から、1メガバイト程度の安全余裕度を差し引いたものです。
この安全余裕度は、サーバがすべてのルーチンではスタック深度を検査をせず、再帰を行う可能性のある重要なルーチンでのみ検査をするために必要となるものです。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルト設定は2メガバイト(2MB
)で、かなり控え目、かつクラッシュの危険がなさそうな設定です。
しかし、複雑な関数の実行を許容するには小さ過ぎるかも知れません。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
max_stack_depth
を実際のカーネルの制限よりも高い値に設定した場合、暴走した再帰関数により、個々のバックエンドプロセスがクラッシュするかもしれません。
PostgreSQLがカーネルの制限を決定することができるプラットフォームでは、この変数を危険な値に設定させません。
しかし、すべてのプラットフォームがこの情報を提供できるわけではありません。
このため、値を選ぶ時には注意が必要です。
shared_memory_type
(enum
)
#
PostgreSQLの共有バッファおよび他の共有データを保持する主共有メモリ領域のためにサーバが使用すべき共有メモリの実装を指定します。
可能な値はmmap
(mmap
を使って獲得した無名共有メモリ)、sysv
(shmget
を使って獲得したSystem V共有メモリ)、windows
(Windows共有メモリ)です。
すべての値がすべてのプラットフォームでサポートされているわけではありません。
サポートされている最初のオプションがそのプラットフォームのデフォルトです。
どのプラットフォームでもデフォルトになっていないsysv
オプションの利用は一般に推奨されません。
通常、デフォルトではないカーネルの設定が大きなアロケーションでは必要になるからです。
(19.4.1参照。)
dynamic_shared_memory_type
(enum
)
#
サーバが使う動的共有メモリの実装を指定します。可能な値はposix
(shm_open
で獲得するPOSIX共有メモリ)、sysv
(shmget
で獲得するSystem V共有メモリ)、windows
(Windows共有メモリ)、 mmap
(データディレクトリ内のメモリマップファイルを使ってシミュレートする共有メモリ)です。
すべての値がすべてのプラットフォームでサポートされているわけではありません。
そのプラットフォームでの推奨実装が通常デフォルトになります。
どのプラットフォームでもデフォルトになっていないmmap
は、オペレーティングシステムが変更されたページをディスクに継続的に書き込み、I/O負荷を増加させるので一般的には利用が推奨されていません。
しかし、デバッグ目的のためにpg_dynshmem
ディレクトリがRAMディスク上にある場合や、他の共有メモリ機能が使えない場合は有用かもしれません。
min_dynamic_shared_memory
(integer
)
#
サーバ起動時にパラレルクエリ用に獲得するメモリの量を指定します。
このメモリ領域不足していたり並列実行される問い合わせで使い尽くされると、新しいパラレルクエリはdynamic_shared_memory_type
で設定された方法でオペレーティングシステムから一時的に共有メモリを獲得しようとします。
これはメモリ管理のオーバーヘッドにより遅くなる可能性があります。
起動時にmin_dynamic_shared_memory
で獲得するメモリは、サポートするオペレーティングシステムに対するhuge_pages
の設定に影響を受けます。
huge pageを自動管理するオペレーティングシステム上でより大きなページにより恩恵を被る可能性が大きいです。
デフォルト値は0
(none)です。
このパラメータはサーバ起動時にのみ設定可能です。
temp_file_limit
(integer
)
#
あるプロセスが一時ファイルとして使用できるディスクの最大容量を設定します。
例えば、ソートやハッシュの一時ファイルであったり、カーソルを保持する格納ファイルです。
この制限値を超えようとするトランザクションはキャンセルされます。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
-1
(デフォルトです)の場合は制限がありません。
この設定はスーパーユーザと、適切なSET
権限を持つユーザのみ変更可能です。
この設定により、ある PostgreSQL セッションによって使用される一時ファイルの合計の容量が常に制約されることになります。 なお、問い合わせの実行において暗黙的に使用される一時ファイルとは異なり、一時テーブルとして明示的に使用されるディスク容量は、この制限には含まれません。
max_files_per_process
(integer
)
#それぞれのサーバ子プロセスが同時にオープンできるファイル数の最大値をセットします。 デフォルトは1000ファイルです。 もしもカーネルがプロセス毎の安全制限を強要している場合、この設定を気にかける必要はありません。 しかし、いくつかのプラットフォーム(特にほとんどのBSDシステム)では、もし多くのプロセス全てがそれだけ多くのファイルを開くことを試みたとした場合、実際にサポートできるファイル数より多くのファイルを開くことを許しています。もしも「Too many open files」エラーが発生した場合、この設定を削減してみてください。 このパラメータはサーバ起動時のみ設定可能です。
VACUUM および ANALYZE コマンドの実行中、実行される各種I/O操作の予測コストを追跡し続ける内部カウンタをシステムが保守します。
累積されたコストが(vacuum_cost_limit
で指定された)限度に達すると、操作を実行しているプロセスはvacuum_cost_delay
で指定されたちょっとの間スリープします。その後、カウンタをリセットし、実行を継続します。
この機能の目的は、同時に実行されているデータベースの活動に対するこれらコマンドによるI/Oへの影響を、管理者が軽減できるようにすることです。
VACUUM
および ANALYZE
の様な保守用コマンドが即座に終了することが重要ではない事態が数多くあります。
しかし、他のデータベースの操作を行うに当たって、これらのコマンドがシステムの能力に多大な阻害を与えないことは通常とても重要です。
コストに基づいたvacuum遅延はこれを実現するための方法を管理者に提供します。
手動で実行したVACUUM
コマンドについては、デフォルトでこの機能は無効になっています。
有効にするには、vacuum_cost_delay
変数をゼロでない値に設定します。
vacuum_cost_delay
(floating point
)
#コストの限度を越えた場合、プロセスがスリープする時間の長さです。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は0で、コストに基づいたvacuum遅延機能を無効にします。 正の整数はコストに基づいたvacuumを有効にします。
コストに基づいたバキューム処理を使用する場合、vacuum_cost_delay
の適切な値は通常かなり小さくなり、おそらく1ミリ秒以下になります。
バキュームによるリソース消費の調整は、他のバキュームのコストパラメータを変更して行うことが最善です。
vacuum_cost_delay
を1ミリ秒以下に設定することは可能ですが、そうした遅延は古いプラットフォームでは正確には計測されないかも知れません。
そうしたプラットフォームでは、VACUUM
のリソース消費制限を1ミリ秒のときに得られる値以上にするには、他のVACUUMコストパラメータの変更が必要となるでしょう。
とは言うものの、使用するプラットフォームで常に計測できる範囲でvacuum_cost_delay
をできるだけ小さくするようにしてください。
大きな遅延は助けになりません。
vacuum_cost_page_hit
(integer
)
#共有バッファキャッシュの中のバッファにvacuumを掛ける予測コストです。バッファプールのロック、共有ハッシュテーブルの検索、およびページ内容走査のコストを示します。デフォルトの値は1です。
vacuum_cost_page_miss
(integer
)
#ディスクから読み込まれなければならないバッファにvacuumを掛ける予測コストです。これが示すものは、バッファプールロックの試み、共有ハッシュテーブルの参照、ディスクから目的ブロックの読み込み、そしてその内容走査です。デフォルトの値は2です。
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
バックグラウンドライタと呼ばれる個別のサーバプロセスがあり、その機能は(新規または更新された)「ダーティ」な共有バッファの書き込みを行うことです。 クリーンなバッファの数が足りないことが分かると、バックグラウンドライタはダーティバッファをファイルシステムに書き込み、それらのバッファにクリーンであるという印を付けます。 これにより、ユーザの問い合わせを処理するサーバプロセスがクリーンなバッファを見つけることができず、ダーティなバッファを自分で書き込まなければならなくなる可能性を減らすことができます。 しかし、バックグラウンドライタは正味の全体的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_flush_after
(integer
)
#
バックグラウンドライタがこの値より多く書く度に、OSが記憶装置に書き込むことを強制しようとします。
このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsync
が実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。
多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。
この設定が無効なプラットフォームがあります。
この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZ
バイト、一般的には8kBです。
有効な設定値は、この強制書き込み機能が無効になる0
から、2MB
までです。
デフォルト値は、Linuxでは512kB
で、それ以外は0
です。
(BLCKSZ
が8kBでなければ、この設定のデフォルト値と最大値がBLCKSZ
に比例して変更されます。)
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみで設定可能です。
bgwriter_lru_maxpages
およびbgwriter_lru_multiplier
の値がより少ないと、バックグラウンドライタで引き起こされる追加のI/O負荷を軽減しますが、サーバプロセスが自分自身で行わなければならない書き込みが増加することになり、会話型問い合わせを遅らせることになります。
backend_flush_after
(integer
)
#
この量を超えるデータが単一のバックエンドによって書き込まれたときはいつでも、OSが記憶装置に書き込むことを強制します。
このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsync
が実行される際、あるいはバックグラウンドで実行される大きなバッチの中でOSがデータを書き出す際に性能の急激な低下を招く可能性を減らします。
多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。
この設定が無効なプラットフォームがあります。
この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZ
バイト、一般的には8kBです。
有効な範囲は、この強制書き込み機能が無効になる0
から、2MB
までです。
デフォルト値は0
です(すなわち書き出し制御を行いません)。
(BLCKSZ
が8kBでなければ、最大値がBLCKSZ
に比例して変更されます。)
effective_io_concurrency
(integer
)
#PostgreSQLが同時実行可能であると想定する同時ディスクI/O操作の数を設定します。 この値を大きくすると、あらゆる個別のPostgreSQLセッションが並行して開始を試みるI/O操作の数が増加します。 設定可能な範囲は1から1000まで、または非同期I/Oリクエストの発行を無効にするゼロです。 現在、この設定はビットマップヒープスキャンのみに影響します。
磁気ディスクドライブにおいては、データベースに使用されるRAID 0ストライプ、RAID 1ミラーを構成する個々のドライブ数から始めると良いでしょう。(RAID 5ではパリティ用のドライブを数に含めません) しかし、同時実行セッションで発行される複数の問い合わせでデータベースが頻繁にビジーとなる場合、小さめの値で十分ディスクアレイがビジーになるかもしれません。 ディスクをビジーにするのに必要な値より大きな値を設定しても、余計なCPUオーバーヘッドを発生させるだけです。 SSDやそれ以外のメモリベースの記憶装置は、多くの同時リクエストをこなすことができるので、最適な値は数百になるかもしれません。
非同期I/Oは実質的にposix_fadvise
関数に依存します。
これは一部のオペレーティングシステムには存在しません。
この関数が存在しない場合、この値をゼロ以外に設定するとエラーとなります。
一部のオペレーティングシステム(例えばSolaris)では存在するけれども、実際何も行わないものもあります。
デフォルトは、サポートされているシステムでは1、そうでなければ0です。 この値は、テーブル空間パラメータの同じ名前のパラメータを設定することで、特定のテーブル空間内のテーブルに対して上書きできます。 (ALTER TABLESPACEを参照ください)。
maintenance_io_concurrency
(integer
)
#
effective_io_concurrency
と似ていますが、多くのクライアントセッションのために行われる保守作業で適用されるところが異なります。
サポートしているシステムではデフォルトは10で、それ以外は0です。 この値は同じ名前のテーブル空間パラメータを使って、特定のテーブル空間にあるテーブルのために置き換えることができます。(ALTER TABLESPACEを参照してください。)
max_worker_processes
(integer
)
#システムがサポートするバックグラウンドプロセスの最大数を指定します。 このパラメータはサーバ起動時のみ設定可能です。 デフォルトは8です。
スタンバイサーバを起動しているときは、このパラメータを、プライマリサーバの設定値と同じかそれ以上にしなければなりません。 さもなければ、スタンバイサーバで問い合わせの実行ができなくなります。
この値を変更する際は、max_parallel_workers、max_parallel_maintenance_workers、max_parallel_workers_per_gatherを変更することも考慮してください。
max_parallel_workers_per_gather
(integer
)
#
一つのGather
またはGather Merge
ノードに対して起動できるワーカー数の最大値を設定します。
パラレルワーカーは、max_parallel_workersで上限が決まるmax_worker_processesで確立されたプロセスのプールから取得されます。
実行時には、要求された数のワーカーは取得できないかもしれないことに注意してください。
そうなると、実行プランは期待していたよりも少ない数のワーカーで実行されることになり、効率は悪化するかもしれません。
デフォルト値は2です。
この設定値を0にすると、パラレルクエリの実行は行われません。
パラレルクエリの実行により、パラレルクエリではない場合に比べて非常に多くのリソースが使用されるかもしれないことに注意してください。
これは、個々のワーカープロセスは完全に別個のプロセスであり、システムに対してユーザセッションが追加されたのと大体同じくらいの影響があるからです。
この設定値を選択する際には、他のリソースの消費量を制御する他の設定値、たとえばwork_memを設定するときと同様に、この点を考慮しておく必要があります。
work_mem
のような設定値によるリソース制限は、個々のワーカーに対して個別に適用されます。
つまり、ひとつのプロセスに対するよりも、すべてのプロセスの全体のリソース消費はずっと多いかもしれないということです。
たとえば、あるパラレルクエリが4つのワーカーを使っているとすると、ワーカーを使わない場合に比べて、最大5倍のCPU時間、メモリ、I/Oバンド幅、その他を使うかもしれません。
パラレルクエリに関する更なる情報については、第15章をご覧ください。
max_parallel_maintenance_workers
(integer
)
#
単一のユーティリティコマンドで使用されるパラレルワーカーの最大数を設定します。
今の所、パラレルワーカーの利用をサポートしているパラレルユーティリティコマンドは、CREATE INDEX
がB-treeインデックスを構築するときと、FULL
オプションなしのVACUUM
です。
パラレルワーカーは、max_worker_processesで確立したプロセスのプールから取得され、max_parallel_workersによって制限されます。
要求したワーカー数は、実行時に実際には利用可能でないかも知れないことに注意してください。
この場合は、ユーティリティ操作は期待したよりも少ない数のワーカーにより実行されます。
デフォルト値は2です。
0に設定すると、ユーティリティコマンドはパラレルワーカーを使用しません。
パラレルユーティリティコマンドは同等の非パラレル操作よりもかなり多くのメモリを消費すべきでないことに留意してください。
この戦略は、一般的にワーカー毎にリソース制限を適用するパラレルクエリとは異なります。
パラレルワーカープロセスの数にかかわらず、パラレルユーティリティコマンドは、その全体でリソース制限maintenance_work_mem
が適用されるとみなします。
しかし、パラレルユーティリティコマンドは、依然としてかなり多くのCPUリソースとI/Oバンド幅を消費するかも知れません。
max_parallel_workers
(integer
)
#パラレルクエリ操作用にシステムがサポートできる最大のワーカー数を設定します。 デフォルト値は8です。 この値を増減するときは、max_parallel_maintenance_workersとmax_parallel_workers_per_gatherを調整することを考慮してください。 また、この設定値をmax_worker_processesよりも高い値にしても効果がないことに注意してください。 max_worker_processesで決まるワーカープロセスのプールから、パラレルワーカーが使われるからです。
parallel_leader_participation
(boolean
)
#
ワーカープロセスを待つ代わりに、Gather
ノードとGather Merge
ノード配下の問い合わせプランをリーダープロセスが実行できるようにします。
デフォルトはon
です。
この値をoff
にすると、リーダーがタプルを十分早く読まないためにワーカーがブロックされる可能性を減らすことができますが、リーダープロセスは最初のタプルが生成される前にワーカープロセスが起動するのを待つ必要があります。
これがリーダーの性能を助けるのか、阻害要因になるかは計画型、ワーカーの数、問い合わせの実行時間の長さによります。
old_snapshot_threshold
(integer
)
#スナップショットを使用する際に、「snapshot too old」エラーが起こるリスク無しに問い合わせスナップショットが利用できる最小の期間を設定します。 この制限値を越えてデッド状態のままになったデータはバキュームしてしまうことが許可されます。 これにより、長い間残っていたスナップショットによりデータが溢れてしまうのを防ぐことができます。 スナップショットから見えるデータが消えることによる不正な結果を防ぐため、スナップショットがこの制限値よりも古く、かつこのスナップショットが作られた以降に変更されたページを読むためにスナップショットが使用されるときはエラーが発生します。
この値が単位なしで指定された場合は、分単位であるとみなします。
-1
(デフォルトです)を設定するとこの機能が無効になり、実質的にスナップショットの寿命を無限にします。
このパラメータはサーバ起動時のみ設定可能です。
実際の環境でのおすすめの値はおそらく数時間から2, 3日の間となるでしょう。
小さな値(たとえば0
や1min
)は、テストの際に有用だということで許可されています。
60d
のような大きな値の設定もできますが、多くのワークロードにおいて、大きなデータ溢れやトランザクションIDの周回がそれよりはずっと短い期間で起こる可能性があることに注意してください。
この機能が有効であると、リレーションの終端部にあるフリースペースはオペレーティングシステムには返却されません。
そうしないと、「snapshot too old」の条件の検出に必要な情報を削除してしまうことになるからです。
明示的に解放されない限り(たとえばVACUUM FULL
によって)、リレーションに割り当てられた領域は、そのリレーションの中での再利用に限定して紐付けられます。
この設定は、どのような状況でもエラーが検出されることを保証するものではありません。 (たとえば)マテリアライズされた結果集合を持つカーソルから正しい結果を得ることができるのであれば、たとえ参照している元のテーブルからVACUUMによって行が削除されたとしてもエラーにはなりません。 ある種のテーブルでは、早期にVACUUMできないので、この設定の影響を受けません。 例としては、システムカタログが挙げられます。 このようなテーブルにおいては、この設定によってデータ溢れを防ぐことも、スキャンの際に「snapshot too old」エラーを起こす可能性を作り出すこともできません。