問題タブ [shared-memory]

データを共有することになっているいくつかの fastcgi プロセスがあります。

データはセッション (一意のセッション ID 文字列) にバインドされ、サーバーの再起動後も存続できるはずです。セッションの数によっては、共有データが大きすぎてメイン メモリに収まらない場合があります。理想的には、共有データが特定のしきい値を超えた場合、最もアクティブでないセッションにバインドされたデータはディスクにのみ存在し、最もアクティブなセッション データはメイン メモリから使用できるようにする必要があります。セッションがしばらく非アクティブになった後、セッション データは破棄されます。

私の質問は（C / ++の初心者であること）です：

この非常に厄介な問題に取り組むのに役立つアプローチやライブラリはありますか?

mmap()非アクティブなセッション データを破棄する必要があることを考慮して、共有メモリを使用することは可能ですか?

私のunix/windows C ++アプリは、MPIを使用してすでに並列化されています。ジョブはN cpusに分割され、各チャンクは並列で実行され、非常に効率的で、非常に高速なスケーリングで、ジョブは正しく実行されます。

ただし、一部のデータは各プロセスで繰り返され、技術的な理由から、このデータをMPIで簡単に分割することはできません（...）。例えば：

• 5 Gbの静的データ、各プロセスにまったく同じものがロードされます
• MPIで分散できる4Gbのデータは、使用されるCPUが多いほど、このCPUあたりのRAMは小さくなります。

4 CPUジョブでは、これは少なくとも20GbのRAM負荷を意味し、メモリの大部分は「無駄」になります。これはひどいことです。

全体的な負荷を減らすために共有メモリを使用することを考えています。「静的」チャンクは、コンピューターごとに1回だけロードされます。

したがって、主な質問は次のとおりです。

• ノード上でメモリを共有するための標準的なMPIの方法はありますか？ ある種のすぐに利用できる+無料のライブラリ？

  • そうでない場合は、boost.interprocessMPI呼び出しを使用して、ローカル共有メモリ識別子を配布します。
  • 共有メモリは、各ノードの「ローカルマスター」によって読み取られ、共有読み取り専用になります。変更されないため、セマフォ/同期の種類は必要ありません。

• パフォーマンスの低下や注意すべき特定の問題はありますか？

  • （「文字列」や過度に奇妙なデータ構造はありません。すべてを配列と構造ポインターにまとめることができます）

• ジョブはPBS（またはSGE）キューイングシステムで実行されます。プロセスがクリーンでない出口の場合、それらがノード固有の共有メモリをクリーンアップするかどうか疑問に思います。

ブーストshared_memory_objectとmapped_regionに問題があります。一連のオブジェクト（構造）をメモリオブジェクトに書き込みたい。構造にcharだけが含まれている場合は、すべて問題ありません。構造体にintを追加するだけの場合、オブジェクトを多すぎると（たとえば、70とすると、ブロックの制限よりはるかに少ない）、書き込み時にセグメンテーション違反が発生します。

これまで、単純な文字が共有メモリに書き込まれる例を見てきましたが、使用できるオブジェクトの種類については何も読んでいません。オブジェクトとバイトストリームの間で変換を行う必要があるのか​​、それともそのような関数がすでに存在するのか疑問に思っています。または、コードで何か間違ったことをしているだけの場合。コメントされた行は、コメントを外したときにセグメンテーション違反を与える行です...

ヒントありがとうございます！

MacOS X10.6.2-gcc4.2-ブースト1.41.0

共有メモリを取得しようとすると、メモリshmget()を割り当てられないために失敗することがよくあります。RAM の物理的なサイズが問題になることはありません (4GB で十分だと思います)。むしろ、システム プロパティのどこかに、共有メモリ セットの割り当てに関する制限がある可能性があります。この物件がどこにあるか知っている人はいますか？

Mac OS X バージョン 10.6 を使用しています

boost::interprocess::string共有メモリに 問題があります。

を使用するshared_memory_objectと、さまざまなフィールドを持つ構造体を操作できますが、文字列 (セグメンテーション エラーが発生します)。
反対に、私が使用するときは、managed_shared_memoryすべて問題ありません。

私は何か間違ったことをしていますか？を使用するとパフォーマンスが低下するかどうか知っていますmanaged_shared_memoryか?

ありがとうございました！

2つ以上のスレッド間で共有メモリをC/C ++でJavaのように待機して通知するには、pthreadライブラリを使用します。

長々とした質問で申し訳ありませんが、回答を変更する可能性のある重要なポイントを省略していないことを確認したかったのです。

私は「C」で書かれたシステム ソフトウェアの保守を担当しており、そのうちいくつかの共通の「.a」ライブラリがあります。主な仕事は、「テストジョブ」実行可能ファイルの変数リストをフォークして実行し、テストジョブプロセスが終了すると実行マネージャーに制御を戻すことです。実行マネージャーを含むすべての実行可能ファイルは、前述のライブラリに対して静的にリンクされています。実行マネージャーと、それがフォークするテストジョブ プロセスは、共有メモリを介して IPC を使用します。共通ライブラリの 1 つには、決して変更されない定義済みのキーを使用して共有メモリを作成およびアタッチするためのラッパー関数が含まれています。

数か月前、私たちはソフトウェア (テストジョブと実行マネージャー) をロックダウンし、それらを静的にコンパイルしてリリースし、テストジョブを「証明」しました。その時以来、いくつかの一般的なライブラリ関数を選択する必要がある実行マネージャーに変更を加えるといういくつかの要求がありました。ただし、経営陣は、現在所有しているテストジョブ実行可能ファイルを再検証する必要があるため、共通ライブラリの新しいバージョンに対してテストジョブを再コンパイルしたくないと決定しました。そして彼らはそれをするためにお金を使いたくないのです。

すべての実行可能ファイルは静的にコンパイルされているため、同じ共通ライブラリの異なるバージョンに対して静的にコンパイルされたテスト ジョブと実行マネージャーを混在させても問題にはなりません。しかし、共有メモリを介した IPC の組み込みは、それがまだ正しいかどうか疑問に思っています。私の直感によると、共有メモリ ラッパー関数、特にキーに変更がない限り、問題はありませんが、これについては専門家の意見を参考にすることができます。

これを読んでくれてありがとう。

一般に、C および C++ 標準は、コンパイラの作成者に多くの自由を与えていることを認識しています。しかし特に、C 構造体メンバーのような POD 型は、構造体定義にリストされているのと同じ順序でメモリに配置する必要があることが保証されます。また、ほとんどのコンパイラは、メンバーの配置を修正できる拡張機能を提供します。したがって、構造体を定義し、そのメンバーの配置を手動で指定するヘッダーがあり、そのヘッダーを使用して異なるコンパイラで 2 つのアプリをコンパイルした場合、一方のアプリが構造体のインスタンスを共有メモリに書き込み、他方のアプリが共有メモリに書き込むことができないはずです。アプリはエラーなしでそれを読むことができますか?

ただし、含まれる型のサイズは、同じアーキテクチャ上の 2 つのコンパイラ間で一貫していると想定しています (共有メモリについて話しているので、既に同じプラットフォームである必要があります)。一部の型 (GCC および MSVC 64 ビットでの long と long long など) ではこれが常に当てはまるとは限りませんが、最近では uint16_t、uint32_t などの型があり、float と double は IEEE 標準で指定されています。

特定のプロセスで使用されているすべての共有メモリ セグメントを検索したいと考えています。私は、shmctl() の呼び出しで使用できるように、shmid を理解することに特に関心があります。

Solaris では、/proc/$PID/map を読み取ってその情報 (フィールド pr_shmid) を把握します。そのファイルの内容は、sys/procfs の struct prmap_t によって定義されます。

AIX にも /proc/$PID/map ファイルがあります。struct prmap もありますが、残念ながら pr_shmid フィールドがありません。

AIX5.3+でこれを達成する方法はありますか?

私たちのアプリは、.soファイルとしてロード可能な外部のサードパーティ提供の構成（カスタムの運転/意思決定機能を含む）に依存しています。

独立して、共有メモリのチャンクを使用して外部CGIモジュールと連携し、揮発性状態のほとんどすべてが保持されるため、外部モジュールはそれを読み取り、必要に応じて変更できます。

問題は、CGIモジュールが.soからの永続的な構成データを大量に必要とし、メインアプリがデータを利用可能にするために2つのメモリ領域間でまったく不要なコピーを大量に実行することです。アイデアは、共有オブジェクト全体を共有メモリにロードし、CGIで直接利用できるようにすることです。問題は：どうやって？

• dlopenとdlsymには、SOファイルをロードする場所を割り当てるための機能はありません。
• shmat（）を試しました。一部の外部CGIが実際に共有メモリにアクセスしようとするまでしか機能しないようです。次に、ポイントされたエリアは、共有されなかったかのようにプライベートに表示されます。多分私たちは何か間違ったことをしているのですか？
• .soを必要とする各スクリプトに.soをロードすることは問題外です。構造のサイズは非常に大きく、呼び出しの頻度に関連しています（一部のスクリプトは、ライブ更新を生成するために1秒に1回呼び出されます）。これは、組み込みアプリであるため、使用できません。
• .soをshmに単純にmemcpy（）することも適切ではありません。一部の構造体とすべての関数は、ポインターを介して相互接続されています。