★Linuxの場合

#cat > /proc/sys/kernel/shmmax
#cat > /proc/sys/kernel/shmall

shmmaxは、このファイルは、(System V IPC) 共有メモリセグメントを作成するときの最大サイズの制限を取得または設定できる。 現在は 1Gb までの共有メモリセグメントがカーネルでサポートされている。この値のデフォルトは SHMMAX である。

shmallとは、このファイルには System V 共有メモリの総ページ数のシステム全体での制限が書かれている。

★FreeBSDの場合

オプションSYSVSHMとSYSVSEMはカーネルの コンパイル時に動作可能にする必要があります。(デフォルトでは 動作可能になっています。)共有メモリの最大サイズはオプション SHMMAXPGSで(ページ数で)決定されます。下記は 様々なパラメータの設定方法の例です。

options SYSVSHM
options SHMMAXPGS=4096
options SHMSEG=256

options SYSVSEM
options SEMMNI=256
options SEMMNS=512
options SEMMNU=256
options SEMMAP=256

上記の設定で、システムとしてのメモリ上限を決めて、postgres
に割り当てる共有メモリ（shared_buffers）を決めます。

システムとしてもメモリ算出方法とshared_buffersの算出方法は、下記の通りです。

--------------------------------------------------------
システムメモリ）
1024*1024*（割り当てたいメモリ）=（記述する数値）

shared_buffers)
（shared_buffersに記述する数値）*8192=(確保するメモリ量）
--------------------------------------------------------

shared_buffersの確保するメモリ量が、システムメモリの記述
する数値よりも少なくないとエラーになります。


★postgresql.confの設定変更

今回設定を行った値を記載します。

checkpoint_segments = 6
-----------------------------------------------------------
WALログは1個16Mバイトの「セグメントファイル」に分かれています。デフォルトでは、5分に一度、あるいはセグメントファイル数が3個を超えたときにチェックポイント処理が実行されます。通常は、このデフォルトの設定で問題ないのですが、大量の更新処理を実行すると、次のようなメッセージが表示されることがあります。


LOG: checkpoints are occurring too frequently (11 seconds apart)
HINT: Consider increasing the configuration parameter "checkpoint_segments".


チェックポイントが頻発する（この例では、11秒間隔）ことについての警告が出されています。チェックポイントは同期書き込みを伴う比較的負荷の高い処理であり、あまりチェックポイントが頻発するとパフォーマンスが低下します。ディスク容量に十分余裕がある場合は、checkpoint_segmentsの値を増やしてチェックポイント頻度を低減するとよいでしょう。上記のメッセージが表示されるときは、checkpoint_segmentsの値を増やしてください。
-----------------------------------------------------------
commit_delay = 15
-----------------------------------------------------------
通常はトランザクションがコミットされるタイミングで WAL にコミットレコードが書き込まれますが, 同時に実行されるトランザクション数が多い場合は書き込み処理が頻繁に行われ, 効率が良くありません。
commit_delay を設定すると, コミットしてから commit_delay(ms) だけ待って WAL に書き込み処理が行われます。

同時トランザクション数が多いサイトの場合, 0以上の値を設定すると書き込み効率が上がります。
ただし, アクティブなトランザクションが commit_siblings よりも少ない場合は遅延処理は行われず, すぐにログに書き込まれます。
-----------------------------------------------------------
shared_buffers = 10000
-----------------------------------------------------------
系 では, 性能のピークは 8000〜10000(約80M) の範囲にあります。
shared_buffers を多く取りすぎると, バッファ管理のオーバーヘッドが生じて, 逆に性能が低下してしまいます。

8系では shared_buffers の性能が改善され, 150000程度までは性能が低下しないようです。
性能のピークは 100000(約800M)付近にあるようです。

8系ではメモリをたくさん積んで shared_buufers を多めに確保したほうが良いでしょう。
-----------------------------------------------------------
sort_mem = 25600
-----------------------------------------------------------
一時ディスクファイルへの切替えを行う前に、内部ソート操作とハッシュテーブルで使われるメモリの量を指定します。 この値は K バイト単位で指定し、そのデフォルトは 1024 K バイトです (1 MB)。複雑な問い合わせでは、いくつかのソート操作やハッシュ操作が並行して実行される可能性があり、その場合それぞれがデータを一時ファイルに書き出す前にこの値が指定した量のメモリを使うことが許されます。また、それぞれの稼働中のセッションが並行して 1 つ以上のソートをしている可能性があります。従って、使用されるメモリの合計は sort_mem の値の何倍にもなり得ます。 ソート操作は、ORDER BY、マージ結合、および CREATE INDEX で使用されます。ハッシュテーブルはハッシュ結合、ハッシュを基にした集約、ハッシュを基に処理するIN副問い合わせで使用されます。データベースのリストア時にCREATE INDEX は使用されますので、巨大なリストア操作を行なう前にsort_memを増加させることで性能が向上します。
-----------------------------------------------------------
vacuum_mem = 51200
----------------------------------------------------------
VACUUM が再回収すべき行の追跡を保持するために使用するメモリの最大量を指定します。この値はkバイト単位で指定し、そのデフォルトは 8192 kバイトです。より大きな値を設定することで、多くの削除された行を持つ巨大なテーブルのバキューム処理は高速になる可能性があります。
-----------------------------------------------------------
effective_cache_size = 32768
-----------------------------------------------------------
カーネルや PostgeSQL の共有バッファなど, PostgreSQL が使用するバッファ領域の大きさの推定値です。
effective_cache_size * 8192 がバイトに換算した値になります（デフォルト値は8MB）。
参照するテーブルが effective_cache_size の範囲内に収まっていると, オプティマイザは積極的にインデックスを使うようになります。


数G のメモリを積んだマシンでは, 1/4〜1/2程度に設定しておきましょう。


-----------------------------------------------------------
random_page_cost = 4
--------------------------------------------------------

問い合わせプランナの順不同に取りだされたディスクページのコストの概算を設定します。これは順ページ取り出しコストの倍数で評価されます。より高い値を設定すると、順スキャンがより使用されるようになります。より低い値を設定すると、インデックススキャンがより使用されるようになります。デフォルトは4です。
-----------------------------------------------------------
enable_sort = true
-----------------------------------------------------------
問い合わせプランナが明示的なソート段階を選択することを有効、あるいは、無効にします。完全に明示的なソートを抑制することはできません。しかし、この変数を無効にすることで、もし他の方法が利用できるのであれば、プランナはその使用を行なわないようになります。デフォルトは有効です。これは、問い合わせプランナのデバッグのために使用されます。
-----------------------------------------------------------
enable_mergejoin = true
--------------------------------------------------------
い合わせプランナのマージ結合型の計画の使用を 有効または無効にします
-----------------------------------------------------------