問題タブ [huge-pages]

mmap巨大なページを割り当てるために使用しています。これは問題なく動作しますが、使用可能なヒュージ ページの限界に近づくことがあり、メモリにアクセスすると SIGBUS 障害が発生します。しかし、そもそもメモリがなかったのになぜ成功したのか、十分なメモリがあることを示しているように見えるmmap理由がわかりませんか?/proc/meminfo

システムにヒュージページを設定しません。ダイレクト マッピングの値がおかしい理由 DirectMap4k: 251600 kB DirectMap2M: 5941248 kB DirectMap1G: 130023424 kB

コマンドラインを見てください。hugepages は指定されていません。ランタイムの hugepage もあり、ディレクトリには 2M の hugepage エントリしかなく、何も指定されていません。

私の /etc/default/grub ファイルでは、「hugepages=N」で明示的に N 個のヒュージ ページを確保しました。2 つの NUMA ノードを備えたボックスで実行している場合、ノードごとに N/2 のヒュージ ページが確保されますか、それともすべてノード 0 に移動しますか? また、ノード間でどのように分割されているかをコマンドラインで照会する方法はありますか?

私は PostgreSQL 9.5 を使用しており、huge_pages = try のデフォルト値を設定しています。サーバーの実行中にpostgresがそれを使用しているかどうかを確認するにはどうすればよいですか?

私は SPDK の実験 (これは DPDK を使用し、さらにヒュージページを使用します) を実行していますが、昨日は機能していました。私はそれらを共有環境で実行しています (あと 1 人か 2 人がこのマシンを他の目的で使用していると思います)。これを実行しようとすると、no free hugepages エラーが発生します。

/proc/meminfo の出力は次のとおりです。

マウントの出力:

前回の環境で機能していたものが機能しなくなりました。

次に、 /proc/meminfo の出力は次のとおりです。

しかし、実行しようとすると：

これらのページが余剰であり、無料ではないのはなぜですか? それらを解放する方法はありますか？他のジョブが実行されているか、他のユーザーが使用している可能性があるため、システムを再起動したいと考えています。

編集:マシンを再起動し、より多くの hugepage を割り当てたところ、それらは解放されました。テストを実行するとクラッシュし、ヒュージページが再び失われました。

有効な答えのない関連する質問 (少なくとも私にとって):

クラッシュしたアプリケーションからヒュージページを解放する方法

新しいプロセスで使用するために Linux で hugepage を実際に解放するにはどうすればよいですか?

TLB ミスを減らすために、アプリケーションの .text セグメントにヒュージ ページを使用しようとしています。libhugetlbfs サポートを使用してアプリを正常に再リンクし、メインの実行可能ファイルの .text セグメントが巨大なページでバックアップされたメモリに読み込まれるようになりました。

ただし、アプリのメイン コード ベースは複数の共有ライブラリとして構成されているため、これらのライブラリもヒュージ ページでサポートする必要があります。.so をメイン アプリと同じオプションでリンクし、env パラメータを設定するだけでは、.so .text セグメントが巨大なページになることはありません。

巨大なページに .so をロードする方法はありますか? アプリの静的リンクを行うこともできますが、ビルドが大幅に複雑になります。

Ignite は Linux ヒュージ ページ (またはトランスペアレント ヒュージ ページ) の恩恵を受けることができますか? 大きな物理メモリ サイズに合わせてヒュージ ページをチューニングするための推奨事項 (ベスト プラクティス) はありますか?

私のプログラムは巨大なページを使用しています。実行するには、次のようにファイルを開きます。

hugetlbfilenameファイル システム内の場所。それはうまくいきます。私のプログラムはmmap()、作成されたファイル記述子を使用できます。しかし、私のプログラムが強制終了された場合、ファイルは残ります...そして、次のコマンド (876 != 1024) で示されるように、残りのファイルはブロックされたメモリです。

したがって、私のプログラムは他の誰ともファイルを共有していないので、O_TMPFILE フラグを使用して一時ファイルを作成することは理にかなっています。だから私は試しました：

pathname は hugetlbfs のポイントです。次のエラーで失敗します（理由は説明できません）。

なんで？さらに要点: プログラムが使用しているすべての巨大なページが解放されることをどのように保証できますか?

はい: いくつかのシグナルをキャッチできました (例: SIGTERM)。すべてではありません ( SIGKILL)

はい:unlink()最初の方法を使用してできるだけ早くファイルを取得できましたが、とSIGKILLの間で が受信された場合はどうなりますか?open()unlink()

カーネルは保証のようなものです。私もそうです。プログラムがいつ、どのように終了するかに関係なく、100% のクリーンアップを保証する適切な方法は何ですか。