.png)
集中的なディスク、ネットワーク I/O、さらには CPU 計算が発生する C++ プログラムでは、メモリ マップ領域を配列として使用しています。
非常に小さなデータでは問題なく動作します。しかし、非常に大きなデータでプログラムを実行すると、アプリケーションがクラッシュします。(OS がすべての I/O とバッファリングを処理するため、mmap 領域のサイズは問題にならないことは完全に理解しています)
Linux のせいにしたくはないのですが、「mmap」が不安定になり、OS がクラッシュするケースがあるかどうか知りたいです。
OS がクラッシュすると、画面に「write_back」などに関連するカーネル パニック メッセージが表示されます... (問題を再現したらすぐにここにメッセージを追加します)
// プログラムは、メモリマップ領域 (Infiniband の RDMA が有効になっている Intel MPI) 上で MPI ネットワーク操作を使用します。RDMA は OS カーネルをバイパスし、一部のデータを直接メモリに書き込む可能性があります。
コールスタックを調査したところ、いくつかのカーネルコードが見つかりました:(http://lxr.free-electrons.com/source/fs/ext4/inode.c#L2313）
エラーは、#L2386 BUG_ON(PageWriteback(page)) の 'BUG_ON' トラップから発生していると思われます。カーネルのバージョンは 3.19.0 (https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.tar.xz）
答え1
あなたはできません原因あらゆるシステム コールの不適切な使用によるカーネル パニックもmmap含まれます。syscall インターフェイスは、呼び出し元にカーネルのデータ構造を破壊する手段を提供しません。
ハードウェアの問題を探し、システム ログ内の手がかりに注意を払います/var/log/kernel.log。たとえば、ディスクが最も障害が発生する可能性が高いコンポーネントであるため、実験として、同じサイズのファイルを別のファイル システムにマッピングしてみます。
その可能カーネルのバグをくすぐった。返事を書くそしてパニック[この古いバグ]が見つかりました。1 非常に古いカーネルを実行している場合は、おそらくアップグレードする時期でしょう。
答え2
コメントの説明によると、これはカーネルクラッシュ（パニック）です。間違いなく一度もない起こる。
これは何のディストリビューションですか? カーネルのバージョンは何ですか? アーキテクチャは何ですか?
まずすべてを更新します。ディストリビューションがサポート終了の場合は、アップグレードします。その後、もう一度試してください。
問題が解決しない場合は、C++ プログラムと同じように膨大な処理を実行する小さな C プログラムで再現し、そのメモリ上で C++ と同様の処理を繰り返すことができますmmap()(おそらく、"奥深くまで" アクセスしてみるだけで十分です)。すべてを収集し、ディストリビューションのバグ報告チャネルから報告してください。