問題タブ [huge-pages]

現在、私のアプリケーションは定期的に IO でブロックされており、出力は非常に低くなっています。いくつかのコマンドを使用してプロセスをトレースします。

jstackを使用すると、アプリが FileOutputStream.writeBytes でハングしていることがわかりました。

strace -f -c -p pidを使用してシステムコール情報を収集すると、それが見つかりました。通常の状況では、futex と write の両方のシステムコールがあります。しかし、異常になったときは、futex syscall しかありません。アプリは futex を呼び出し続けますが、すべて失敗し、次のように ETIMEDOUT をスローします。

この問題は定期的に発生し、数分または数時間継続し、再び正常になります。

特に、IO でブロックされた場合、echo 3 > /proc/sys/vm/drop_cachesを実行すると、常に一時的に正常になります。私はそれをグーグルで検索し、以下にリストする同様のプロリームを見つけました.

1. うるう秒。動作しません。システムの ntpd が停止しています。
2. 透過的なヒュージページのバグ。https://bugzilla.redhat.com/show_bug.cgi?id=879801 これは私の問題とよく似ていますが、私の khugepaged プロセスは正常で、負荷は常にほぼゼロです。特に drop_cachesは私のアプリケーションでも機能します。また、私のシステムもマルチコアで大容量メモリです。それは私にはうまくいきません。誰かが同じ問題に遭遇したか、この問題に精通していますか?

私のシステムに関するいくつかの情報。OS: Redhat 6.1、カーネル バージョン 2.6.31

JDK:1.7.0_05

CPU：X5650、24コア

メモリ:24GB と 48GB

Intel チップが最大 1 GB の仮想メモリ ページ サイズをサポートすることを読みました。MEM_LARGE_PAGES で VirtualAlloc を使用すると、2MB のページが取得されます。別のページサイズを取得する方法はありますか? 現在 Server 2008 R2 を使用していますが、Server 2012 にアップグレードする予定です。

私の問題

OVH CentOS 7 インストールで、Transparent Huge Pages (THP) に関する MongoDB の警告を削除するのに問題があります。問題は、/sys/kernel/mmroot として書き込めないことのようです。

まず、OVH カーネルがカスタマイズされていることを認識しています。多くの人がカスタマイズされていない新しいカーネルを使用することをお勧めしますが、それは現在のオプションではありません。現在のOSでこの問題を解決する必要があります。

MongoDB の警告:

MongoDB は transparent_hugepage ファイル (以下) を読み込もうとしていますが、存在しません:

ファイルを作成できません

私が見たすべてのソリューションには、MongoDB ドキュメントのスクリプトneverを含め、ファイルを作成してそれらにデータを入力することが含まれます。すべてのソリューションで、これが重要な部分です。

/sys/kernel/mmただし、ファイルは存在せず、ルートとして何も作成できません。

ディレクトリの所有者とグループは で/sys/kernel/mm、rootパーミッションを一時的に 700 から 777 に変更しましたが、ルートとしてディレクトリを作成できません。

調整されたプロファイルも役に立たない

徹底するために、カスタム Tuned プロファイルも作成し (上記の MongoDB リンクの手順に従って)、有効にしましたが、エラーが発生します。WARNING tuned.plugins.plugin_vm: Option 'transparent_hugepages' is not supported on current hardware.

調整済みプロファイル (/etc/tuned/no-thp/tuned.conf):

Tuned ログのエラー:

MongoDB自体の解決策はありますか?

不足しているファイルをチェックする必要がないように、THP を使用しないように MongoDB を明示的に構成することが最善の解決策のようですが、このようなものは見たことがありません。方法があれば、たとえそれが MongoDB のカスタマイズ (および更新のたびに繰り返すこと) を伴うものであっても、喜んで実行します。

https://github.com/libhugetlbfs/libhugetlbfs/blob/master/HOWTOのガイドに従って、hugepages でテキストとデータ セグメントをバックアップする可能性を探っています。

「-B/usr/share/libhugetlbfs -Wl,--hugetlbfs-align」を追加することで提案されているようにアプリケーションを再リンクし、「hugectl --text --data --heap --bss /path/to」でアプリケーションを開始しました/私のアプリケーション"。

しかし、データ セグメントとテキスト セグメントが実際に hugetlbfs ファイルシステム上のファイルにコピーされているかどうかを確認する方法がよくわかりません。

/proc/{pid}/maps を確認すると、最初の 2 つのアドレス範囲はアプリケーションにマップされていますが、hugepage ファイル システムにはマップされていないため、ヒュージページはヒープに使用されていますが、テキストおよびデータ セグメントには使用されていないことがわかります。

私の理解は正しいですか？実際、/proc/{pid}/maps からのヒープに hugepage が使用されているという私の結論も間違っているのではないかと思います。

データとテキスト セグメントが hugepage でサポートされているかどうかを確認するにはどうすればよいですか? 成功した場合、データとテキスト セグメントが hugetlbfs ファイルシステムにコピーされることはわかっていますが、それを確認するにはどうすればよいですか?

ありがとう！

/proc/{pid}/maps の出力

GCE 以外の他のクラウド プラットフォームでヒュージ ページ/ラージ ページを使用するように構成した JBOSS アプリケーションを実行しています。しかし、GCE で問題が発生しています。エラーが表示されます:

JVMを起動するとき。これらはUbuntu 14.04ベースのシステムで実行されており、以前にヒュージページが機能していた同様のシステムと同じように構成されているため、ラージページが機能するように正しく設定されていない仮想マシンレベルの設定があるかどうか疑問に思っています. 誰にも提案はありますか？

巨大な TLB ページ (1GB) を使用して 2GB のバッファーを割り当て、メモリ領域を特定の numa ノードにバインドしようとしています。

巨大な TLB ページを使用してバッファーを割り当てるために、次のコードを使用しています。

それから、私は電話しました：

バッファを特定のノードに移動します。

プログラムを実行すると、1GB を超えるバッファー オフセットにアクセスするとすぐに、「バス エラー (コア ダンプ)」でプログラムが停止します。

numa_tonode_memory を削除するとエラーは回避されますが、特定のノードにメモリを割り当てる目的が失われます。

この問題の回避策があるかどうかは疑問ですが、

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