Linuxでshm_openを試して問題に遭遇しています。私は頻繁に共有メモリセグメントのサイズをftruncで変更し、mmapを使ってサイズ変更されたセグメントを再マップします。しかし、20メガバイトのマークのまわりで、私はmmapからENOMEMを取得します。私はこの問題を解決するために行うことを試みてきたmmapはshm_openファイルオブジェクトでENOMEMを返します。
もの：
最初、私はこれらのsysctlのパラメータを知りました。私はそれらを再構成：
kernel.shmmax = 268435456
kernel.shmall = 2097152
（SHMALLはページ単位で指定されている）
問題はまだこの後に起こりました。この問題を引き起こすサイズ変更の詳細を調べると、共有メモリオブジェクトのサイズを変更するためにftruncに呼び出されたことがわかりました（/ dev/shmの対応するファイルには新しいサイズが要求されていました）。
[ENOMEM] MAP_FIXEDが指定され、範囲[ADDR、ADDR + lenが）のアドレス空間に許可することを超えて：ここから
ドキュメントhttp://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.htmlはENOMEMのerrnoにするための3つの原因が示唆しますプロセス; MAP_FIXEDが指定されておらず、アドレス空間にマッピングを行うのに十分な空きがない場合
[EN] [ML] [オプション] mlockall（）が必要とする場合、システムが提供できるスペースよりも多くのスペースが必要になるため、マッピングをメモリにロックできませんでした。 [オプションの開始]
[TYM][TYM] [オプションの開始] lenバイトを割り当てるためにfildesによって指定された型付きのメモリオブジェクトに十分な未割り当てのメモリリソースが残っていません。 [オプション終了]
iがMAP_FIXEDまたはロックを使用していない、と/ dev/SHMの画像のサイズは、第三の理由は問題ではないことを示唆しています。私のmmapコールは、次のようになります
のmmap（MEM、長さ、PROT_READ | PROT_WRITE、MAP_SHARED、FD、0）
MEMは、最初は0で、その後に成功マッピングされた最後のアドレスはmmapを参照。
私は、ulimit設定がメモリを1つのプロセスにマップ可能に制限している可能性があることを示す情報を見つけましたが、ここに問題はないと思います。念のためには、ulimit -aは、私のマシン上で次のようになります。
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
私は、これは簡単なものであると思います:)
'shmmax'と' shmall' sysctl調整パラメータはPOSIX SHMではなくSysV SHM用です。 –