共有メモリとセマフォはひとまとめに「System V IPC」と呼ばれます （メッセージキューも一緒ですが、これはPostgreSQLとは関係ありません）。 これらの機能を独自の代替的な実装で提供しているWindowsを除き、PostgreSQLを実行させるためにはこれらの機能が必要です。

これらの機能の完全な欠落は、サーバ起動時のIllegal system callエラーによって判明します。 その場合はカーネルを設定し直すしかありません。 PostgreSQLはこれらの機能なしでは動きません。 しかし最近のオペレーティングシステムではこうした状況はまれなものです。

PostgreSQLが様々なIPCのハードリミットの1つを超えると、サーバは起動を拒否し、問題および何をすべきかを説明するエラーメッセージを残します。 （17.3.1. サーバ起動の失敗 も参照してください。） 関係するカーネルパラメータは別々のシステム上でも統一して名付けられています。 表17.1「System V IPCパラメータ」で概略がわかります。 しかしこれらを設定するための方法は異なります。 以下に、いくつかのプラットフォームへの提案を挙げます。

PostgreSQLは、サーバのコピー毎にSystem V共有メモリの数バイト（64ビットプラットフォームでは通常48バイト）を必要とします。 最近のほとんどのオペレーティングシステムでは、このくらいの量は簡単に割り当てられます。 しかし複数のサーバのコピーを実行している場合やSystem V共有メモリを使用する他のアプリケーションを実行している場合は、 共有メモリセグメントの最大サイズであるSHMMAXをバイト単位で、あるいは、システム全体のSystem V共有メモリであるSHMALLを増加させる必要があるかもしれません。 多くのシステムではSHMALLをバイト単位ではなくページ単位で測ることに注意してください。

問題が少ないのは共有メモリセグメントの最小サイズ（SHMMIN）で、PostgreSQLでは最大でもおよそ32バイトのはずです（通常では1です）。 システム全体のセグメントの最大数（SHMMNI）もしくはプロセスごとのセグメントの最大数（SHMSEG）に関して、使用しているシステムで0に設定されていない限り、問題が起きることはほぼありません。

PostgreSQLは、許可した接続（max_connections）、許可したオートバキュームワーカプロセス（autovacuum_max_workers）、許可したバックエンドプロセス(max_worker_processes)ごとに1つのセマフォを使用し、16個のセマフォをセットとして扱います。 それぞれそのようなセットは、他のアプリケーションに使われているセマフォセットとの衝突を検出するための「マジックナンバー」が含まれている17個目のセマフォを持っています。 システム内のセマフォの最大数はSEMMNSによって設定され、その結果としてその値は少なくともmax_connections＋autovacuum_max_workers＋max_worker_processesと同じ、ただし、許可された接続とワーカ16個ごとに余分な1個を加えた値以上はなければいけません（表17.1「System V IPCパラメータ」の公式を参照してください）。 SEMMNIパラメータはシステム上に同時に存在できるセマフォ集合の数の上限を決定します。 ですから、このパラメータは少なくともceil((max_connections + autovacuum_max_workers + max_worker_processes + 5) / 16)以上はなくてはいけません。 一時的な失敗の回避策としては許可される接続の数を下げることができますが、「No space left on device」という紛らわしい言葉がsemget関数から表示されます。

場合によってはSEMMAPを少なくともSEMMNSと同程度に増やすことが必要になる場合があるかもしれません。 このパラメータはセマフォリソースマップのサイズを定義し、その中では有効なセマフォのそれぞれの隣接したブロックの項目が必要です。 セマフォ集合が解放されると、解放されたブロックに隣接する既に存在する項目に追加されるか、もしくは新しいマップの項目の下に登録されます。 もしマップが一杯だった場合、解放されたセマフォは（再起動するまで）失われます。 セマフォ空間の断片化により時間が経つごとに、有効なセマフォがあるべき量よりも少なくなる可能性があります。

1つの集合の中にいくつのセマフォがあるかを決めるSEMMSLはPostgreSQLでは少なくとも17はなくてはいけません。

SEMMNUとSEMUMEのような、その他の様々な「semaphore undo」に関する設定はPostgreSQLには影響を与えません。

UnixライクなオペレーティングシステムではPostgreSQLサーバの操作と関係する可能性のある様々な種類のリソース制限があります。 特に重要なのは、ユーザごとのプロセス数の制限、プロセスごとのオープンファイルの数、プロセスごとの利用可能なメモリの量です。 これらのそれぞれが「ハード」と「ソフト」の2つの制限を持っています。 ソフト制限が実際に有効な制限ですが、ユーザによってハード制限まで変えることが可能です。 ハード制限はrootユーザによってのみ変えることができます。 setrlimitシステムコールがこれらのパラメータの設定を行います。 シェルの組み込みコマンドulimit（Bourne シェル）もしくはlimit（csh）は、コマンドラインからリソース制限を制御するために使われます。 BSD派生システム上では/etc/login.confファイルが、ログイン時に設定される様々なリソース制限を制御します。 詳細はオペレーティングシステムの文書を参照してください。 関連するパラメータはmaxproc、openfiles、datasizeです。 以下に例を示します。

default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...

（-curはソフト制限です。 ハード制限を設定するためには-maxを付けてください。）

カーネルはいくつかのリソースに対して、システム全体の制限も持つことができます。

PostgreSQLサーバは接続ごとに1つのプロセスを使うので、少なくとも許可された接続の数だけのプロセスに残りのシステムで必要な分を追加したものが必要になります。 通常はこれは問題ではありませんが、1つのマシン上でいくつかのサーバを起動している場合は厳しい状況になるかもしれません。

オープンファイルの制限の出荷時のデフォルトは、しばしば大多数のユーザはマシン上でシステムリソースの不正使用をしないという前堤に立った「社会的に友好的な」値を設定してしまいます。 もし1つのマシン上で複数のサーバを起動する場合はそれが必要でしょうが、専用サーバではこの制限を上げたいかもしれません。

反対に、個々のプロセスが多数のファイルをオープンすることを許可するシステムもあります。 そのようなプロセスが数個以上あれば、システム全体の制限は簡単に超えてしまいます。 この発生を検知し、システム全体の制限の変更を望まない場合は、PostgreSQLのmax_files_per_process設定パラメータを設定し、オープンファイルの消費を制限することができます。

Linux 2.4以降では、デフォルトの仮想メモリの動作はPostgreSQLには最適ではありません。 カーネルがメモリオーバーコミットを実装する方法のため、カーネルは、PostgreSQLや他のプロセスのメモリ要求がシステムの仮想メモリを枯渇させた場合、PostgreSQL postmaster （マスタサーバプロセス）を終了させる可能性があります。

これが発生した場合、以下のようなカーネルメッセージが現れます （こうしたメッセージを検索する場所についてはシステム文書と設定を参照してください）。

Out of Memory: Killed process 12345 (postgres).

これは、postgresプロセスがメモリ不足のために終了してしまったことを示します。 起動中のデータベース接続は正常に動作しますが、新しい接続は受け付けられません。 復旧するには、PostgreSQLを再起動しなければなりません。

この問題を防止する1つの方法として、PostgreSQLを他のプロセスがそのマシンのメモリを枯渇させないことが確実なマシンで起動するというものがあります。 物理メモリとスワップ領域が消費尽くされた時のみにメモリ不足（OOM）killerが発生するため、メモリが不足する場合、オペレーティングシステムのスワップ領域を増やすことが問題解決の役にたちます。

PostgreSQL自体が実行中のシステムのメモリ不足を引き起こした場合、設定を変更することで問題を防止することができます。 メモリ関連の設定パラメータ、具体的にはshared_buffersおよびwork_mem、を低くすることで回避できる場合もあります。 個の他にもデータベースサーバ自体への接続が多く許可しすぎることで問題が引き起こされる場合もあります。 多くの場合、max_connectionsを減らし、外部のコネクションプールソフトウェアを使用することで改善されます。

Linux 2.6以降では、メモリを「オーバーコミット」させないようにカーネルの動作を変更することができます。 この設定は完全にOOM killerの発生を防ぐことはできませんが、その発生頻度をかなり軽減しますので、システム動作の堅牢性をより高めます。 これは、以下のようにsysctlを使用して厳密なオーバーコミットモードを選択すること、もしくは、/etc/sysctl.confに同等の項目を記述することで実施されます。

sysctl -w vm.overcommit_memory=2

また、関連するvm.overcommit_ratio設定を変更した方が良いでしょう。 詳細はDocumentation/vm/overcommit-accountingカーネル文書を参照してください。

vm.overcommit_memoryの変更と関係なく使用できるその他の方法は、プロセス固有のOOMスコア調整値をpostmasterプロセス向けに-1000に設定することです。 これによりOOM killerの対象とならないことが保証されます。 このための最も簡単な方法は以下をpostmasterの起動スクリプト内でpostmasterを実行する直前に実行することです。

echo -1000 > /proc/self/oom_score_adj

この作業をrootで実行しなければならないことに注意して下さい。 さもないと効果がありません。 このためrootが所有する起動スクリプトが、これを行うための最も簡単な場所です。 その場合には、スタートアップスクリプトのpostmasterの起動前に以下の環境変数を設定することも推奨します。

export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
export PG_OOM_ADJUST_VALUE=0

これらの設定は、いざという時にpostmasterの子プロセスをOOM killerのターゲットに出来るようにOOMスコア調整を通常のゼロで実行します。 子プロセスを他のOOMスコア調整で実行したい場合には、PG_OOM_ADJUST_VALUEにより別の値にすることが出来ます。 （PG_OOM_ADJUST_VALUEは省略することが出来て、その場合はデフォルトのゼロになります。） PG_OOM_ADJUST_FILEを設定しない場合、子プロセスはpostmasterと同じOOMスコア調整で実行されますが、postmasterが優先される設定にすることが肝心なので、それは賢明とは言えません。

古いLinuxカーネルは/proc/self/oom_score_adjを提供していませんが、同様の機能を持つ/proc/self/oom_adjがあるでしょう。 これは、無効にするための設定値が-1000ではなく-17であるという点を除いては同じように動作します。

PostgreSQLメモリの大きな連続チャンクを使用するときにhuge pagesを使用すると、オーバーヘッドが減少します。 PostgreSQLでこの機能を有効にするには、kernelのCONFIG_HUGETLBFS=yとCONFIG_HUGETLB_PAGE=yが必要です。 またシステム設定vm.nr_hugepagesを調整しなければなりません。 PostgreSQLに必要なhuge pages数を見積もるには、huge pagesを有効にせずに、procファイルシステムからVmPeakの値をチェックします。

$ head -1 /path/to/data/directory/postmaster.pid
4170
$ grep ^VmPeak /proc/4170/status
VmPeak:  6490428 kB

6490428 / 2048 （PAGE_SIZE はこのケースでは 2MB ) は、おおよそ3169.154huge pagesなので、少なくとも 3170のhuge pagesが必要になります。

$ sysctl -w vm.nr_hugepages=3170

時には、カーネルは望ましいhuge pages数を割り当てることができませんので、そのコマンドを繰り返すか、再起動の必要があるかもしれません。 再起動によって、この設定を永続化するために/etc/sysctl.confにエントリを追加することを忘れないでください。

huge pagesを使用するデータベースサーバのオペレーティングシステムのユーザに権限を与える必要もあります。 これは、sysctlを介してvm.hugetlb_shm_groupで設定します。 またulimit -lでメモリにロック出来る権限も必要です。

PostgreSQLのhuge pagesのデフォルトの動作は、可能な場合は使用し、失敗した場合は通常のページ使用にフォールバックします。 huge_pagesをon に設定することでhuge pagesの使用を強制することができます。 この場合、十分なhuge pagesが確保できない場合、PostgreSQLの起動に失敗します。

Linuxのhuge pagesの詳細はhttps://www.kernel.org/doc/Documentation/vm/hugetlbpage.txtを参照してください。