解決策 1:
ipcs -l を使用 実際に有効な制限を確認し、ipcs -a と ipcs -m 何が使用されているかを確認して、出力を比較できます。 nattch を見てください 列:プロセスが終了した (通常はプログラムがクラッシュしたことを意味する) ときに削除されなかった、プロセスが接続されていないセグメントはありますか? ipcrm それらをクリアすることもできますが、これがテスト マシンの場合は、再起動の方が速くなります (また、制限に対する変更が確実に反映されます)。
カーネル パラメータがおかしいようです。特に、shmall はバイト数ではなくページ数であり、4kB がデフォルトのページ サイズです (実行 getconf PAGESIZE 使用しているものを確認します）。何テラバイトの RAM を搭載していますか?
ここで、約 32771 の共有メモリ セグメントを取得すると言いますが、これは約 32768 (または 15 の 2) であり、符号付き 16 ビット int が制限要因であることを示唆しています。そして、どのカーネルを実行していますか (これには独自の制限があるため)。この 2 つは関連している可能性があります。
解決策 2:
カーネルで shmmni が 32768 に制限されていることがわかりました:
#define IPCMNI 32768 /* <= MAX_INT limit for ipc arrays (including sysctl changes) */
ファイル ...version.../include/linux/ipc.h 内 .
カーネルを再コンパイルしないと、共有メモリ セグメント数のハード リミットになります。