11

hugepage を使用するアプリケーションがあり、バグが原因でアプリケーションが突然クラッシュしました。クラッシュ後、アプリケーションがヒュージページを適切に解放しないため、sys ファイルシステムで空きヒュージページ数が増加しません。

$ sudo cat /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages 
0
$ sudo cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages 
1024

hugepage を強制的に解放する方法はありますか?

4

5 に答える 5

8

場合によっては、hugetlbfs がマウントされているすべてのディレクトリを確認する必要があります。そう、

  1. コマンドでマウントされたディレクトリを見つけますmount | grep huge。

  2. 特にを除くすべてのディレクトリを確認してください/dev/hugepages。

  3. サイズが 2M のファイルをすべて削除します。(2M は hugepage のサイズです)

于 2014-10-21T10:37:53.087 に答える
2

ipcs -m共有メモリ セグメントを一覧表示するために使用します。ipcrm残りの共有メモリ セグメントを削除するために使用します。

2019 年 6 月 24 日の編集: わかりました。上記の回答は、正しい限りではありますが、少し簡潔でした。特に、複数の DB インスタンスを持つホストがあり、1 つだけがクラッシュした場合、どのメモリ セグメントをクリーンアップする必要があるかをどのように判断できますか?

まぁ、これも出来ます。実行中のインスタンスごとに、 w// as sysdbaで接続してから実行しますoradebug setmypid(すべての Oracle PID が SGA に接続するため、任意の pid で実行できます)。次に、実行しますoradebug ipc。それは（うまくいけば）返されIPC information written to the trace fileます。そのため、udump (または diag_dest) ディレクトリに移動し、トレース ファイルを探します。インスタンスのすべての IPC 情報が含まれます。これには が含まれますShmId。このインスタンスが使用している ShmId のファイルを調べます。の出力を見てくださいipcs -m。

実行中のすべてのインスタンスに対してこれを行った場合、ipcs -mゼロ以外のメモリ割り当てを示し、実行中のインスタンスからの情報で説明できないからのメモリ セグメント出力oradebug ipcは、クラッシュしたインスタンスからの残りのメモリ セグメントである必要があります。を使用ipcrmして削除します。

複数のインスタンスが実行されているホストでこれを行う場合、これは少し面倒な場合があります。注意して進めてください。実行中のインスタンスの SGA を削除したくない!

それが役立つことを願って....

于 2013-12-04T04:06:00.240 に答える
1

HugeTLB は、共有メモリ (および Mark J. Bobak の回答がそれに対処する) または hugetlb ファイルシステムで作成された app mmaps ファイルに使用できます。これらのファイルを削除せずにアプリがクラッシュした場合、それらのファイルは存続し、対応するメモリが「割り当てられた」ままになります。

hugeTLB ファイルシステムをチェックし、アプリからの残りのファイルがあるかどうかを確認します。それらを削除すると、メモリが解放されます。

于 2013-12-04T04:55:37.403 に答える