Slonyの初期サブスクリプションにより、メモリ不足のカーネルパニックが発生しています。どうして？
コンテキスト：
2つのCentOS6サーバー（1つはマスター、もう1つはスレーブ）でSlony2.0とPostgres8.4を実行します。私たちのデータベースのサイズは約30GBで、これは珍しいことではありませんが、それぞれ5GBを超えるテーブルがいくつかあります。
最近、Slonyクラスターを再構築する必要がありました。 Slonyをオフにし、マスターとスレーブで同一のデータベーススナップショットを復元し、slony.confとslon_tools.confをセットアップし、slonを開始し、slonik_init_cluster | slonik、次にslonik_create_set 1 | slonikを実行しました（レプリケーションは1つだけです）セット）、そして最後にslonik_subscribe_set 1 2 | slonik。すべてが良さそうだったし、ログでサブスクリプションの進行状況を見ることができた。
その後、サーバーは応答を停止しました。再起動すると、可能な限りすべてを強制終了した後、「カーネルパニック-同期していません：メモリ不足で強制終了可能なプロセスがありません」と表示されました。
私が試したこと：
最初にデータベースを完全に吹き飛ばし、initdbを再実行してから、同じスナップショットを再度復元しました。同じカーネルパニック。それから私はそれを吹き飛ばし、PostgresとSlonyをアンインストールし、それらを再インストールしました。 postgresql.confですべてのメモリベースの設定を再確認しましたが、それらはすべて在庫/推奨レベルです（つまり、shared_buffersはRAMなど）の1/4です。 ）。Slonyクラスターを初期化する前にデータベースでVACUUM ANALYZE FULLを実行しました。毎回同じ結果：カーネルパニック、メモリ不足。
ランダム/手動の構成変更がこれを引き起こしている可能性はありません。PostgresとSlonyの構成はすべて Puppet によって管理されており、何ヶ月も変更されていません。
質問：
なんでこんなことが起こっているの？
私たちのデータベースは過去数か月でかなり直線的に成長し（年初は約23GBでしたが、現在は30です）、これらの同じサーバーでSlonyクラスターを再初期化する必要があるたびに機能しました。大丈夫。
問題は無関係であることが判明しました：in /etc/sysctl.conf、システムのshmmax値が使用可能なRAMよりも大きい量に設定されました。
RAM（DBコンサルタントの推奨）の60％に設定すると、問題が解決しました。
なぜこの問題が以前に発生しなかったのかは私には謎です。