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

16.4. カーネルリソースの管理

大規模なPostgreSQLインストレーションでは、すぐに各種オペレーティングシステムのリソース制限を超えてしまうことがあります (システムによっては、実際に"大規模"なインストレーションでなくても、出荷時のデフォルトでは低過ぎるものもあります)。 この種の問題が発生したら、これらを読んでください。

16.4.1. 共有メモリとセマフォ

共有メモリとセマフォはひとまとめに"System V IPC"と呼ばれます。 (メッセージキューも一緒ですが、これはPostgreSQLとは関係ありません)。 ほとんど全ての最近のオペレーティングシステムはこれらの機能を提供していますが、これらの全て、特にBSD由来で有効にされているとは限りませんし、デフォルトで十分なサイズがあるとも限りません (WindowsQNXおよびBeOS版では、PostgreSQLは独自の代替的な実装でこれらの機能を提供しています)。

これらの機能の完全な欠落は、サーバ起動時のIllegal system callエラーによって判明します。 その場合はカーネルを設定し直すしかありません。 PostgreSQLはこれらの機能なしでは動きません。

PostgreSQLが様々なIPCのハードリミットの1つを超えると、サーバは起動を拒否し、発生した問題および何をすべきかを説明するエラーメッセージを残します (項16.3.1 も参照してください)。 関係するカーネルパラメータは別々のシステム上でも統一して名付けられています (表16-1で概略がわかります)。 しかしこれらを設定するための方法は異なります。 以下に、いくつかのプラットフォームへの提案を挙げます。 これらの設定を変えるには、しばしばマシンを再起動することが必要になり、カーネルをコンパイルし直す必要がある場合さえあるので注意してください。

表 16-1. System V IPCパラメータ

名前説明適切な値
SHMMAX共有メモリセグメントの最大サイズ(バイト)最小でも数メガバイト(本文を参照してください)
SHMMIN共有メモリセグメントの最小サイズ(バイト)1
SHMALL使用可能な共有メモリの総量(バイトまたはページ)バイト指定の場合SHMMAXと同じです。 ページ指定の場合はceil(SHMMAX/PAGE_SIZE)です。
SHMSEGプロセスごとの共有メモリセグメントの最大数必要なのは1セグメントだけですが、デフォルトではもっと多くなっています
SHMMNIシステム全体の共有メモリセグメントの最大数SHMSEGと同様 + 他のアプリケーション用の空間
SEMMNIセマフォ識別子の最大数(つまりセット)最低 ceil(max_connections / 16)
SEMMNSシステム全体のセマフォの最大数ceil(max_connections / 16)×17 + 他のアプリケーション用の空間
SEMMSLセットごとのセマフォの最大数最低17
SEMMAPセマフォマップの中の項目の数本文を参照
SEMVMXセマフォの最大値最低1000(デフォルトはしばしば32767ですが、強制されない限り変えないでください)

共有メモリに関する一番重要なパラメータは、共有メモリセグメントの最大サイズのバイト数SHMMAXです。 もしshmgetからInvalid argumentのようなエラーメッセージを受けた場合、おそらくこの上限を超えています。 必要な共有メモリセグメントのサイズは、表16-2に示す各種のPostgreSQL設定パラメータによって変わります。 エラーをなくすための一時的な策として、これらの設定を低くすることもできます。 大雑把には、必要とされるセグメントサイズは500キロバイト+上記表に記載された変数の量と見積もることができます。 (エラー時に表示されるメッセージには、割り当てに失敗したサイズが正確に記載されています。) SHMMAXを1メガバイトとしてPostgreSQLを稼動させることができますが、受容できる性能を確保するためには少なくとも4メガバイト必要です。 10メガバイト単位の設定を推奨します。

また、システムの中には、システムにおける共有メモリの総量(SHMALL)に対する制限があるものがあります。 この値を確実に、PostgreSQLと共有メモリセグメントを使用する他のアプリケーションの合計よりも十分に大きくしてください (警告: 多くのシステムで、SHMALLはバイト単位ではなくページ単位です)。

問題が少ないのは共有メモリセグメントの最小サイズ(SHMMIN)で、PostgreSQLでは最大でもおよそ500キロバイトのはずです(通常では1です)。 システム全体のセグメントの最大数(SHMMNI)もしくはプロセスごとのセグメントの最大数(SHMSEG)に関して、使用しているシステムで0に設定されていない限り、問題が起きることはほぼありません。 また、システムによっては、システム内の共有メモリの合計値にも制限を設定しています。 下記のプラットフォーム固有の指示を参照してください。

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

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

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

SEMMNUSEMUMEのような、その他の様々な"semaphore undo"に関する設定はPostgreSQLでは問題にする必要がありません。

BSD/OS

共有メモリ. デフォルトでは、4メガバイトの共有メモリしかサポートされていません。 共有メモリはページングできないことを覚えておいてください。 RAMの中にロックされているのです。 システムでサポートされる共有バッファ数を増加するには、カーネル設定ファイルに以下を追加してください。

options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"

SHMALLは4キロバイトページ単位ですので、1024という値は、共有メモリが4メガバイトであることを示します。 したがって、上記では、最大の共有メモリ領域を32メガバイトまで増加しています。 4.3以降では、おそらくKERNEL_VIRTUAL_MBをデフォルトの248より増やさなければなりません。 全ての変更を行った後、カーネルを再コンパイルし、リブートしてください。

4.0以前のリリースでは、bpatchを使用して現在のカーネルからsysptsizeを検索してください。 これは起動時に自動的に計算されます。

$ bpatch -r sysptsize
0x9 = 9

そして、SYSPTSIZEをカーネル設定ファイル内にハードコードした値として追加してください。 この値をbpatchを使用して見つけた値に増やしてください。 希望共有メモリを4メガバイト増やすごとに1増加してください。

options "SYSPTSIZE=16"

sysptsizesysctlでは変更できません。

セマフォ. セマフォの数についても増やしたい場合があるかもしれません。 デフォルトのシステム合計である60という値では、およそ50個のPostgreSQL接続しかできません。 希望する値をカーネル設定ファイルに設定してください。例えば、

options "SEMMNI=40"
options "SEMMNS=240"

FreeBSD

デフォルトの設定は、小規模なインストレーションでのみ適しています(例えば、デフォルトのSHMMAXは32メガバイトです)。 sysctlまたはloaderインタフェースを使用して変更を行うことができます。 以下ではsysctlを使用してパラメータを変更しています。

$ sysctl -w kern.ipc.shmall=32768
$ sysctl -w kern.ipc.shmmax=134217728
$ sysctl -w kern.ipc.semmap=256

これらの設定をリブートしても永続化するには、/etc/sysctl.confを変更します。

残りのセマフォ設定はsysctlでは読み取りのみとみなされていますが、起動前にloaderプロンプトを使用して変更することができます。

(loader) set kern.ipc.semmni=256
(loader) set kern.ipc.semmns=512
(loader) set kern.ipc.semmnu=256

同様に、これらの設定をリブートしても永続化させるには/boot/loader.confに保存します。

また、共有メモリをRAM上に残し、スワップへのページアウトを行わせないようにさせたいかもしれません。 これはsysctlkern.ipc.shm_use_phys設定を使用して実現できます。

sysctlsecurity.jail.sysvipc_allowedを有効にしたFreeBSD jail上で実行している場合、 異なるjailで稼動させるpostmasterを異なるオペレーティングシステムユーザで実行させなければなりません。 非特権ユーザによる異なるjailで共有メモリやセマフォの干渉を防止することができ、セキュリティが向上します。 また、PostgreSQLのIPC整理コードが適切に機能するようになります。 (FreeBSD 6.0以降では、IPC整理コードは他のjailのプロセスを適切に検出しません。このため、異なるjailで同一ポートのpostmasterを実効させることができません。)

FreeBSDバージョン4.0以前では、(後述の)NetBSDOpenBSDと同様に動作します。

NetBSD
OpenBSD

SYSVSHMオプションとSYSVSEMオプションはカーネルのコンパイル時に有効にする必要があります(デフォルトでは有効になっています)。 共有メモリの最大サイズはSHMMAXPGSオプション(ページ数)で決定されます。 以下に、様々なパラメータの設定方法の例を示します(OpenBSDでは代わりにoptionが使用されています)。

options        SYSVSHM
options        SHMMAXPGS=4096
options        SHMSEG=256

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

また、共有メモリをRAMの中にロックするようにカーネルを設定することで、スワップにページアウトしないようにもできます。 sysctlを使用してkern.ipc.shm_use_physを設定することができます。

HP-UX

デフォルトの設定は通常のインストールではほぼ十分です。 HP-UX 10ではSEMMNSの出荷時のデフォルトは128ですが、これは大規模なデータベースサイトには低過ぎるかもしれません。

IPCパラメータはシステム管理マネージャSAM)からKernel Configuration->Configurable Parametersの下で、設定することができます。 終わったらCreate A New Kernelを押してください。

Linux

デフォルトの設定では、小規模なインストレーションのみに適しています。 (デフォルトの最大セグメントサイズは32MBです。) しかし、この他のデフォルトはかなり豊富に割り当てられており、通常は変更する必要はありません。 sysctlインタフェースを使用して、最大セグメントサイズを変更することができます。 例えば、これを128MBとし、また、明示的に最大総共有メモリサイズを2097152ページ(デフォルト)に設定するには以下のようにします。

$ sysctl -w kernel.shmmax=134217728
$ sysctl -w kernel.shmall=2097152

更にこれらの設定をリブート時に/etc/sysctl.confに保存することができます。

古めのディストリビューションではsysctlプログラムが存在しない可能性があります。 この場合、/procファイルシステムに対する操作で同等の変更を行うことができます。

$ echo 134217728 >/proc/sys/kernel/shmmax
$ echo 2097152 >/proc/sys/kernel/shmall

Mac OS X

OS X 10.2以前では、/System/Library/StartupItems/SystemTuning/SystemTuningファイルを編集して以下のコマンド内の値を変更します。

sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall

OS X 10.3以降では、これらのコマンドは/etc/rcに移動されましたので、そこで編集しなければなりません。 通常/etc/rcはOS Xのアップデート(10.3.6から10.3.7など)で上書きされることに注意してください。 ですので、アップデートの度に編集し直す必要があるものと考えなければなりません。 すべてのバージョンにおいて、変更を有効にするにはリブートしなければなりません。

OS X 10.3.9以降では、/etc/sysctl.confファイルにより共有メモリの設定をオペレーティングシステムの更新を行っても保持できるようになりました。 これがこのパラメータを設定する推奨の方法です。 このファイルを使用する場合、5つすべての共有メモリの値を設定しなければなりません。さもないと変更が無視されてしまいます。

このプラットフォームでは、SHMALLは4キロバイトページ単位です。 また最近のOS Xのリリースでは、SHMALLSHMMAXの値を4096正確なの倍数以外に設定しようとすると拒絶します。

SCO OpenServer

デフォルトの設定では、セグメント当たり512キロバイトの共有メモリが許されています。 この設定を増加させるには、まず、/etc/conf/cf.dディレクトリに移動します。 SHMMAXの現在値を表示させるには、以下を実行します。

./configure -y SHMMAX

SHMMAXに新しい値を設定するには、以下を実行します。

./configure SHMMAX=value

ここで、valueが希望する新しい値(バイト単位)です。 そして、以下のようにカーネルを再構築し、リブートします。

./link_unix

AIX

少なくともバージョン5.1までは、 SHMMAXなどのパラメータに対して特別な設定は必要ありません。 全てのメモリが共有メモリとして使用できるように設定されているようにみえます。 これはDB/2などの他のデータベースでも使用される、一般的な設定方法です。

しかし、/etc/security/limits内の大域的なulimit情報は変更しなければならないかもしれません。 デフォルトのファイルサイズ(fsize)とファイル数(nofiles)用のハードリミットは低過ぎるかもしれないためです。

Solaris

少なくともバージョン2.6では、共有メモリセグメントのデフォルトの最大サイズはPostgreSQLには低過ぎる設定になっています。 必要な設定は/etc/systemで変えることができ、例えば以下のようになります。

set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256

set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32

変更を反映させるには再起動する必要があります。

Solaris環境での共有メモリに関する情報については、http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.htmlも参照してください。

UnixWare

UnixWare 7では、共有メモリセグメントの最大サイズはデフォルト設定で512キロバイトしかありません。 現在のSHMMAX値を表示するためには下記を実行してください。

/etc/conf/bin/idtune -g SHMMAX

これは現在値、デフォルト値、最小値、および最大値を、バイト単位で表示します。 SHMMAXの新しい値を設定するためには、以下を実行します。

/etc/conf/bin/idtune SHMMAX value

ここでvalue は、希望する新しい値(バイト)です。 SHMMAXの設定が終わったらカーネルを再構築し、リブートします。

/etc/conf/bin/idbuild -B

表 16-2. PostgreSQLの共有メモリ使用量に影響する設定パラメータ

名称おおよその乗数(1増やした場合のバイト数)
max_connections400 + 220 * max_locks_per_transaction
max_prepared_transactions600 + 220 * max_locks_per_transaction
shared_buffers8300 (assuming 8K BLCKSZ)
wal_buffers8200 (assuming 8K BLCKSZ)
max_fsm_relations70
max_fsm_pages6

16.4.2. リソースの制限

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

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

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

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

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

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

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

16.4.3. Linuxのメモリオーバーコミット

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

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

Out of Memory: Killed process 12345 (postmaster). 

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

この問題を防止する1つの方法として、PostgreSQLを他のプロセスがそのマシンのメモリを枯渇させないことが確実なマシンで起動するというものがあります。

Linux 2.6以降では、メモリを"オーバーコミット"させないようにカーネルの動作を変更するという、より優れた解法があります。 これは、以下のようにsysctlを使用して厳密なオーバーコミットモードを選択すること、もしくは、/etc/sysctl.confに同等の項目を記述することで実施されます。

sysctl -w vm.overcommit_memory=2

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

Linux 2.4カーネルのベンダの中には、2.6のオーバーコミットsysctl版を持つものがあることが報告されています。 しかし、関係するコードを持たないカーネルでvm.overcommit_memoryを2に設定することはより状況を悪化させます。 2.4のインストレーションではこれを試す前に、実際のカーネルソースコードを調査し、その中でサポートしているかどうかを検証することをお勧めします(mm/mmap.cファイル内のvm_enough_memory関数を参照してください)。 overcommit-accounting文書ファイルの存在は、この機能が存在するかどうかを証明するものではありません。 疑わしい場合は、使用中のカーネルベンダのカーネル専門家に相談してください。