カーネルリソースの管理PostgreSQLは、特に同一システム上で複数のサーバコピーを実行している場合や非常に大規模なインストレーションでは、オペレーティングシステムの様々なリソース制限を超えてしまうことがあります。本節では、PostgreSQLで使用されるカーネルリソース、およびカーネルリソース消費に関連した問題を解消する時に取ることができる手順について説明します。(メッセージキューも一緒ですが、これはPostgreSQLとは関係ありません)。これらの機能を独自の代替的な実装で提供しているWindowsを除き、PostgreSQLを実行させるためにはこれらの機能が必要です。callエラーによって判明します。その場合はカーネルを設定し直すしかありません。PostgreSQLはこれらの機能なしでは動きません。最近のオペレーティングシステムではこうした状況はまれなものです。PostgreSQLが様々なIPCのハードリミットの1つを超えると、サーバは起動を拒否し、問題および何をすべきかを説明するエラーメッセージを残します。関係するカーネルパラメータは別々のシステム上でも統一して名付けられています。IPCパラメータ」で概略がわかります。これらを設定するための方法は異なります。以下に、いくつかのプラットフォームへの提案を挙げます。V共有メモリの量は非常に大きなものでした。古いバージョンのサーバで実行しているのであれば、該当するバージョンのサーバの文書を参照してください。バイト指定の場合SHMMAXと同じです。ページ指定の場合はceil(SHMMAX/PAGE_SIZE)です。V共有メモリの数バイト(64ビットプラットフォームでは通常48バイト)を必要とします。最近のほとんどのオペレーティングシステムでは、このくらいの量は簡単に割り当てられます。V共有メモリであるSHMALLを増加させる必要があるかもしれません。多くのシステムではSHMALLをバイト単位ではなくページ単位で測ることに注意してください。問題が少ないのは共有メモリセグメントの最小サイズ(SHMMIN)で、PostgreSQLでは最大でもおよそ32バイトのはずです(通常では1です)。システム全体のセグメントの最大数(SHMMNI)もしくはプロセスごとのセグメントの最大数(SHMSEG)に関して、使用しているシステムで0に設定されていない限り、問題が起きることはほぼありません。PostgreSQLは、許可した接続(max_connections)、許可したオートバキュームワーカプロセス(autovacuum_max_workers)、許可したバックエンドプロセス(max_worker_processes)ごとに1つのセマフォを使用し、16個のセマフォをセットとして扱います。それぞれそのようなセットは、他のアプリケーションに使われているセマフォセットとの衝突を検出するための「マジックナンバー」が含まれている17個目のセマフォを持っています。IPCパラメータ」の公式を参照してください)。SEMMNIパラメータはシステム上に同時に存在できるセマフォ集合の数の上限を決定します。16)以上はなくてはいけません。device」という紛らわしい言葉がsemget関数から表示されます。場合によってはSEMMAPを少なくともSEMMNSと同程度に増やすことが必要になる場合があるかもしれません。このパラメータはセマフォリソースマップのサイズを定義し、その中では有効なセマフォのそれぞれの隣接したブロックの項目が必要です。セマフォ集合が解放されると、解放されたブロックに隣接する既に存在する項目に追加されるか、もしくは新しいマップの項目の下に登録されます。マップが一杯だった場合、解放されたセマフォは(再起動するまで)失われます。セマフォ空間の断片化により時間が経つごとに、有効なセマフォがあるべき量よりも少なくなる可能性があります。1つの集合の中にいくつのセマフォがあるかを決めるSEMMSLはPostgreSQLでは少なくとも17はなくてはいけません。undo」に関する設定はPostgreSQLには影響を与えません。AIX少なくともバージョン5.1では、すべてのメモリが共有メモリとして使用できるように設定されているようにみえますので、SHMMAXなどのパラメータに対して特別な設定は必要ありません。これはDB/2などの他のデータベースでも使用される、一般的な設定方法です。/etc/security/limits内の大域的なulimit情報は変更しなければならないかもしれません。デフォルトのファイルサイズ(fsize)とファイル数(nofiles)用のハードリミットは低過ぎるかもしれないためです。FreeBSDデフォルトの設定はsysctlまたはloaderインタフェースを使用して変更を行うことができます。以下ではsysctlを使用してパラメータを変更しています。kern.ipc.shmmax=134217728これらの設定を再起動しても永続化するには、/etc/sysctl.confを変更します。セマフォ関連の設定はsysctlでは読み取りのみとみなされていますが、/boot/loader.conf内で設定することができます。kern.ipc.semmni=256kern.ipc.semmns=512kern.ipc.semmnu=256これらの値を変更した後、新しい設定を有効にするためには再起動が必要です。SEMMAPを使用しません。新しいバージョンでは拒否します。)また、共有メモリをRAM上に固定して、スワップによってページアウトされるのを避けるために、カーネルを設定したいと考えるかもしれません。これはsysctlを使用してkern.ipc.shm_use_physを設定することで実現できます。jailを実行している場合、異なるjailで実行するpostmasterを別のオペレーティングシステムユーザで実行しなければなりません。これは、非特権ユーザが別のjailの共有メモリやセマフォに干渉することを防止できるため、セキュリティが向上します。これによりPostgreSQLのIPCを整理するコードを適切に動作させることができます。6.0以降では、IPC整理コードは他のjailにおけるプロセスを適切に検出せず、異なるjailで同一ポートでpostmasterを実行させることができません。)FreeBSDバージョン4.0以前では、(後述の)OpenBSDと同様に動作します。5.0以降では、以下の例のようにIPCパラメータをsysctlを用いて調整することができます。kern.ipc.shmmax=16777216この設定を再起動しても永続化させるためには/etc/sysctl.confを編集してください。共有メモリをRAM上に固定して、スワップによってページアウトされるのを避けるために、カーネルを設定したいと考えるかもしれません。これはsysctlを使用してkern.ipc.shm_use_physを設定することで実現できます。5.0より前のバージョンのNetBSDでは、(後述の)OpenBSDのように動作します。パラメータはoptionではなくoptionsキーワードを付けて設定する必要があります。OpenBSDSYSVSHMオプションとSYSVSEMオプションはカーネルのコンパイル時に有効にする必要があります(デフォルトでは有効になっています)。共有メモリの最大サイズはSHMMAXPGSオプション(ページ数)で決定されます。以下に様々なパラメータの設定方法の例を示します。SEMMAP=256また、共有メモリをRAM上に固定して、スワップによってページアウトされるのを避けるために、カーネルを設定したいと考えるかもしれません。これはsysctlを使用してkern.ipc.shm_use_physを設定することで実現できます。HP-UXデフォルトの設定は通常のインストールではほぼ十分です。10ではSEMMNSの出荷時のデフォルトは128ですが、これは大規模なデータベースサイトには低過ぎるかもしれません。Parametersの下で、設定することができます。Kernelを選択してください。Linuxデフォルトの最大セグメントサイズは32メガバイト、デフォルトの最大総サイズは2097152ページです。pages」を持つ通常ではないカーネル設定を除き、1ページはほとんど常に4096バイトです。PAGE_SIZEを使用してください。)共有メモリサイズの設定はsysctlインタフェースを使用して変更可能です。16ギガバイトまで許すには以下のようにします。kernel.shmall=4194304更にこれらの設定を再起動時に保持できるように/etc/sysctl.confに保存することができます。することを大いに勧めます。古めのディストリビューションではsysctlプログラムが存在しない可能性があります。この場合、/procファイルシステムに対する操作で同等の変更を行うことができます。>/proc/sys/kernel/shmall他のデフォルトはかなり豊富なサイズですので、通常は変更する必要はありません。Xにおける共有メモリの推奨設定方法は、以下のような変数代入文からなる/etc/sysctl.confという名称のファイルを作成することです。Xでは/etc/sysctl.conf内に共有メモリパラメータ5つすべてを設定しなければならないという点に注意してください。なくば値が無視されます。Xは、SHMMAXを4096の倍数以外に設定しようとすると無視しますので、注意してください。このプラットフォームではSHMALLは4キロバイトページ単位です。Xでは、共有メモリパラメータの変更を有効にするために再起動が必要になります。10.5からSHMMNI以外の変更は、sysctlを用いることにより、その場で行うことができます。いずれにせよ/etc/sysctl.conf経由で望む値に設定することが最善です。再起動を行っても値が保持されるからです。10.3.9以降でのみ使用されます。これより前の10.3.xリリースを使用しているのであれば、/etc/rcファイルを編集し、以下のコマンドで値を変更しなければなりません。Xのアップデートで上書きされることに注意してください。アップデートの度に編集し直す必要があるものと考えなければなりません。10.2以前では、代わりに/System/Library/StartupItems/SystemTuning/SystemTuningファイル内にあるこれらのコマンドを編集してください。OpenServerデフォルトの設定では、セグメント当たり512キロバイトの共有メモリが許されています。この設定を増加させるには、まず、/etc/conf/cf.dディレクトリに移動します。SHMMAXの現在値を表示させるには、以下を実行します。SHMMAXSHMMAXに新しい値を設定するには以下を実行します。SHMMAX=valueここで、valueが希望する新しい値(バイト単位)です。以下のようにカーネルを再構築し、再起動します。9)必要な設定は/etc/systemで変えることができ、例えば以下のようになります。semsys:seminfo_semmsl=32変更を反映させるには再起動する必要があります。古めのバージョンのSolarisにおける共有メモリの情報はhttp://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.htmlを参照してください。10以降とOpenSolarisでは、デフォルトの共有メモリとセマフォ設定は大抵のPostgreSQLアプリケーションで十分あります。SolarisのデフォルトのSHMMAXはシステムのRAMの1/4になりました。この設定を調整するためには、postgresユーザに関するプロジェクト設定を使用しなければなりません。以下をroot権限で実行してください。user.postgresこのコマンドはuser.postgresプロジェクトを追加し、postgresユーザの共有メモリの最大サイズを8GBに設定します。この影響は次にこのユーザがログインした時、またはPostgreSQLを再起動した時(再読み込み時ではありません)に有効になります。上ではPostgreSQLはpostgresグループに属するpostgresユーザにより実行されていることを前提としています。サーバの再起動は不要です。多くの接続を受け付けるデータベースサーバにおいて推奨するカーネル設定にはこの他に以下があります。project.max-shm-ids=(priv,32768,deny)project.max-sem-ids=(priv,4096,deny)project.max-msg-ids=(priv,4096,deny)さらに、ゾーン内でPostgreSQLを実行している場合、ゾーンのリソース使用上限も上げる必要があるかもしれません。プロジェクトとタスクを参照してください。7では、共有メモリセグメントの最大サイズはデフォルト設定で512キロバイトです。現在のSHMMAX値を表示するためには下記を実行してください。SHMMAXこれは現在値、デフォルト値、最小値、および最大値を、バイト単位で表示します。SHMMAXの新しい値を設定するためには、以下を実行します。希望する新しい値(バイト)です。SHMMAXの設定が終わったらカーネルを再構築し、再起動します。リソースの制限UnixライクなオペレーティングシステムではPostgreSQLサーバの操作と関係する可能性のある様々な種類のリソース制限があります。重要なのは、ユーザごとのプロセス数の制限、プロセスごとのオープンファイルの数、プロセスごとの利用可能なメモリの量です。これらのそれぞれが「ハード」と「ソフト」の2つの制限を持っています。ソフト制限が実際に有効な制限ですが、ユーザによってハード制限まで変えることが可能です。ハード制限はrootユーザによってのみ変えることができます。setrlimitシステムコールがこれらのパラメータの設定を行います。シェル)もしくはlimit(csh)は、コマンドラインからリソース制限を制御するために使われます。BSD派生システム上では/etc/login.confファイルが、ログイン時に設定される様々なリソース制限を制御します。詳細はオペレーティングシステムの文書を参照してください。関連するパラメータはmaxproc、openfiles、datasizeです。:openfiles-cur=256:\...(-curはソフト制限です。ハード制限を設定するためには-maxを付けてください。)カーネルはいくつかのリソースに対して、システム全体の制限も持つことができます。Linuxでは、/proc/sys/fs/file-maxが、カーネルがサポートするオープンファイル数の最大を決定します。この数を変えるためには、そのファイルに別の数を書き込むか、あるいは/etc/sysctl.confに代入式を追加します。プロセスごとのファイルの最大制限はカーネルがコンパイルされた時に固定されます。詳しい情報については/usr/src/linux/Documentation/proc.txtを参照してください。PostgreSQLサーバは接続ごとに1つのプロセスを使うので、少なくとも許可された接続の数だけのプロセスに残りのシステムで必要な分を追加したものが必要になります。通常はこれは問題ではありませんが、1つのマシン上でいくつかのサーバを起動している場合は厳しい状況になるかもしれません。オープンファイルの制限の出荷時のデフォルトは、しばしば大多数のユーザはマシン上でシステムリソースの不正使用をしないという前堤に立った「社会的に友好的な」値を設定してしまいます。1つのマシン上で複数のサーバを起動する場合はそれが必要でしょうが、専用サーバではこの制限を上げたいかもしれません。反対に、個々のプロセスが多数のファイルをオープンすることを許可するシステムもあります。そのようなプロセスが数個以上あれば、システム全体の制限は簡単に超えてしまいます。この発生を検知し、システム全体の制限の変更を望まない場合は、PostgreSQLのmax_files_per_process設定パラメータを設定し、オープンファイルの消費を制限することができます。2.4以降では、デフォルトの仮想メモリの動作はPostgreSQLには最適ではありません。(マスタサーバプロセス)を終了させる可能性があります。(こうしたメッセージを検索する場所についてはシステム文書と設定を参照してください)。(postgres).これは、postgresプロセスがメモリ不足のために終了してしまったことを示します。起動中のデータベース接続は正常に動作しますが、新しい接続は受け付けられません。復旧するには、PostgreSQLを再起動しなければなりません。この問題を防止する1つの方法として、PostgreSQLを他のプロセスがそのマシンのメモリを枯渇させないことが確実なマシンで起動するというものがあります。物理メモリとスワップ領域が消費尽くされた時のみにメモリ不足(OOM)killerが発生するため、メモリが不足する場合、オペレーティングシステムのスワップ領域を増やすことが問題解決の役にたちます。PostgreSQL自体が実行中のシステムのメモリ不足を引き起こした場合、設定を変更することで問題を防止することができます。メモリ関連の設定パラメータ、具体的にはshared_buffersおよびwork_mem、を低くすることで回避できる場合もあります。個の他にもデータベースサーバ自体への接続が多く許可しすぎることで問題が引き起こされる場合もあります。多くの場合、max_connectionsを減らし、外部のコネクションプールソフトウェアを使用することで改善されます。2.6以降では、メモリを「オーバーコミット」させないようにカーネルの動作を変更することができます。killerの発生を防ぐことはできませんが、その発生頻度をかなり軽減しますので、システム動作の堅牢性をより高めます。これは、以下のようにsysctlを使用して厳密なオーバーコミットモードを選択すること、もしくは、/etc/sysctl.confに同等の項目を記述することで実施されます。vm.overcommit_memory=2また、関連するvm.overcommit_ratio設定を変更した方が良いでしょう。詳細はDocumentation/vm/overcommit-accountingカーネル文書を参照してください。vm.overcommit_memoryの変更と関係なく使用できるその他の方法は、プロセス固有のOOMスコア調整値をpostmasterプロセス向けに-1000に設定することです。killerの対象とならないことが保証されます。このための最も簡単な方法は以下をpostmasterの起動スクリプト内でpostmasterを実行する直前に実行することです。/proc/self/oom_score_adjこの作業をrootで実行しなければならないことに注意して下さい。ないと効果がありません。このためrootが所有する起動スクリプトが、これを行うための最も簡単な場所です。その場合には、スタートアップスクリプトのpostmasterの起動前に以下の環境変数を設定することも推奨します。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であるという点を除いては同じように動作します。2.4カーネルのベンダの中には、2.6のオーバーコミットsysctl版を持つものがあることが報告されています。関係するコードを持たない2.4カーネルでvm.overcommit_memoryを2に設定することはより状況を悪化させます。2.4のインストレーションではこれを試す前に、実際のカーネルソースコードを調査し、その中でサポートしているかどうかを検証することをお勧めします(mm/mmap.cファイル内のvm_enough_memory関数を参照してください)。overcommit-accounting文書ファイルの存在は、この機能が存在するかどうかを証明するものではありません。疑わしい場合は、使用中のカーネルベンダのカーネル専門家に相談してください。pagesを使用すると、オーバーヘッドが減少します。PostgreSQLでこの機能を有効にするには、kernelのCONFIG_HUGETLBFS=yとCONFIG_HUGETLB_PAGE=yが必要です。システム設定vm.nr_hugepagesを調整しなければなりません。pagesを有効にせずに、procファイルシステムからVmPeakの値をチェックします。pagesが必要になります。pages数を割り当てることができませんので、そのコマンドを繰り返すか、再起動の必要があるかもしれません。再起動によって、この設定を永続化するために/etc/sysctl.confにエントリを追加することを忘れないでください。pagesを使用するデータベースサーバのオペレーティングシステムのユーザに権限を与える必要もあります。これは、sysctlを介してvm.hugetlb_shm_groupで設定します。-lでメモリにロック出来る権限も必要です。pagesのデフォルトの動作は、可能な場合は使用し、失敗した場合は通常のページ使用にフォールバックします。pagesの使用を強制することができます。pagesが確保できない場合、PostgreSQLの起動に失敗します。pagesの詳細はhttps://www.kernel.org/doc/Documentation/vm/hugetlbpage.txtを参照してください。サーバのシャットダウン。