共有メモリアプリケーションを使用していて、セグメントを削除するには、次のコマンドを使用します。
ipcrm -M 0x0000162e (this is the key)
ipcs
を実行すると、同じセグメントが表示されますが、キーが0x0000000であるため、正しいことを行っているかどうかはわかりません。それで、メモリセグメントは本当に削除されたのですか?アプリケーションを数回実行すると、次のようにキー0x000000の異なるメモリセグメントが表示されます。
key shmid owner perms bytes nattch status
0x00000000 65538 me 666 27 2 dest
0x00000000 98307 me 666 5 2 dest
0x00000000 131076 me 666 5 1 dest
0x00000000 163845 me 666 5 0
実際に何が起こっていますか?メモリセグメントは本当に削除されていますか?
編集:問題は-承認された回答で後述するように-共有メモリを使用する2つのプロセスがあり、すべてのプロセスが閉じられるまで、メモリセグメントが消えないことです。
UNIX(AIXとHPUX、Linuxでは共有メモリを使用したことはないことを認めます)の時代から、削除によってブロックが新しいクライアントからアタッチできなくなったというマークが付けられたことを漠然と覚えています。
アタッチされているプロセスがなくなった後のある時点でのみ、物理的に削除されます。
これは、削除された通常のファイルと同じです。ディレクトリ情報は削除されますが、ファイルの内容は、最後のプロセスがファイルを閉じた後にのみ消えます。これにより、プロセスがまだ書き込みを行っているために削除された後でも、ファイルシステム上でますます多くのスペースを占めるログファイルが生成されることがあります。これは、ファイルポインター(0個以上のディレクトリエントリがポイントしている)間の「切り離し」の結果です。 iノード)とファイルの内容(iノード自体)。
ipcs
の出力から、4つのうち3つにプロセスがアタッチされていることがわかるので、それらのプロセスが共有メモリブロックから切り離されるまで、プロセスはどこにも移動しません。もう一方はおそらく、「スイープ」機能がクリーンアップするのを待っていますが、それはもちろん、共有メモリの実装に依存します。
共有メモリの適切に作成されたクライアント(または、ログファイル)は定期的に再接続(またはロールオーバー)して、この状況が一時的なものであり、ソフトウェアの動作に影響を与えないようにする必要があります。
次のコマンドを使用したと言いました
ipcrm -M 0x0000162e (this is the key)
Ipcrmのmanページから
-M shmkey Mark the shared memory segment associated with key shmkey for removal. This marked segment will be destroyed after the last detach.
したがって、-Mオプションの動作は、観察したとおりに動作します。つまり、最後の切り離しの後でのみセグメントが破棄されるように設定します。