Linuxでメモリの断片化を検出する方法はありますか？これは、一部の長時間実行されているサーバーでパフォーマンスの低下に気づき、プロセスを再起動した後にのみパフォーマンスが向上するためです。Linuxのヒュージページサポートを使用すると、Linuxのヒュージページが断片化されやすくなることに気付きました。

特に/ proc / buddyinfoを見ました。私はそれを見るためのより良い方法（CLIコマンド自体だけでなく、プログラムや理論的背景が行うであろう）があるかどうかを知りたいです。

Linuxタグに答えています。私の答えはLinuxだけに固有のものです。

はい、巨大なページは断片化の傾向があります。メモリには2つのビューがあります。1つはプロセスが取得するもの（仮想）、もう1つはカーネルが管理するもの（実際）です。特にページが大きいほど、隣接するグループをグループ化（および維持）するのが難しくなります。特に、デフォルトで他のメモリよりも多くのメモリを割り当てて書き込むシステムもサポートしているシステムで実行している場合はなおさらです。実際に使用することになります。

（実際の）許可されたアドレスのカーネルのマッピングはプライベートです。カーネルはユーザー空間を混乱させることなくオーバーコミットできる必要があるため、カーネルがそれらを表示するときにユーザー空間がそれらを見る非常に良い理由があります。あなたのプロセスは、素敵な、連続的な取得「Disneyfied」カーネルが実際にされているものの忘れて仕事にでアドレス空間、やっ舞台裏そのメモリとを。

長時間実行されているサーバーでパフォーマンスが低下するのは、明示的にロックされていない（たとえば、mlock()/ mlockall()またはposix_madvise()）しばらくの間変更されていない割り当てられたブロックがページアウトされたためです。それら。この動作を変更すると、プロセスが悪い隣人になります。これが、多くの人がweb / php / python / ruby​​ / whateverとはまったく異なるサーバーにRDBMSを配置する理由です。それを正す唯一の方法は、連続したブロックの競合を減らすことです。

断片化は、ページAがメモリ内にあり、ページBがスワップに移動した場合にのみ（ほとんどの場合）実際に顕著です。当然、サービスを再起動するとこれが「治癒」するように見えますが、それはカーネルがプロセスをページアウトする機会をまだ持っていないためです（現在）、オーバーコミット率の範囲内で新しく割り当てられたブロック。

実際、高負荷の状態で「apache」を再起動すると（たとえば）、他のサービスが所有するブロックを直接ディスクに送信する可能性があります。そのため、「apache」は短期間で改善されますが、「mysql」は、少なくとも十分な物理メモリが不足しているときに少なくともカーネルが同等に苦しめるまでは苦しむ可能性があります。

メモリを追加するか、要求の厳しいmalloc()コンシューマーを分割します:)注目すべき断片化だけではありません。

vmstat実際に何がどこに保存されているかの概要を取得してください。

カーネル

現在の断片化インデックスを取得するには、次を使用します。

sudo cat /sys/kernel/debug/extfrag/extfrag_index

カーネルメモリを最適化するには、次を実行してください。

sysctl vm.compact_memory=1  

また、Transparent Huge Pages（別名THP）をオフにするか、swap（または減少swappiness）を無効にします。

ユーザースペース

ユーザースペースの断片化を減らすために、たとえば、異なるアロケーターを試してみることをお勧めしますjemalloc（これには優れたイントロスペクション機能があり、アロケーターの内部断片化の内部を知ることができます）。

あなたはそれでまたはちょうどであなたのプログラムを実行して、プログラムを再コンパイルすることで、カスタムのmallocに切り替えることができますLD_PRELOAD：LD_PRELOAD=${JEMALLOC_PATH}/lib/libjemalloc.so.1 app （の用心THPとメモリのメモリアロケータの間の相互作用）

メモリの断片化とは少し関係ありません（ただし、メモリの圧縮/移行に接続されています）が、おそらくNUMAノードごとに1つのサービスの複数のインスタンスを実行し、を使用してそれらをバインドする必要がありますnumactl。

巨大なページを使用しても、Linuxで余分なメモリの断片化は発生しません。Linuxのhugeページのサポートは共有メモリ（shmgetまたはmmap経由）のみであり、使用されるhugeページはシステム管理者によって特別に要求され、事前に割り当てられる必要があります。メモリに格納されると、それらはそこに固定され、スワップアウトされません。メモリの断片化に直面して巨大なページをスワップすることの難しさは、まさにメモリ内に固定されたままである理由です（2MBの巨大なページを割り当てるとき、カーネルは512個の連続した空き4KBページを見つける必要がありますが、これは存在しないこともあります）。

巨大なページのLinuxドキュメント：http : //lwn.net/Articles/375098/

メモリの断片化により巨大なページの割り当てが遅くなる場合があります（ただし、巨大なページがメモリの断片化を引き起こす場合はありません）。それは、アプリケーションから要求された場合に巨大なページのプールを拡大するようにシステムが構成されている場合です。/ proc / sys / vm / nr_overcommit_hugepagesが/ proc / sys / vm / nr_hugepagesより大きい場合、これが発生する可能性があります。

あり/proc/buddyinfo非常に有用です。このPythonスクリプトができるように、素敵な出力形式でより便利です。

https://gist.github.com/labeneator/9574294

巨大なページの場合、2097152（2MiB）サイズ以上の空きフラグメントが必要です。透過的な巨大なページの場合、カーネルに要求されたときに自動的に圧縮されますが、取得できる数を確認するには、rootで実行します。

echo 1 | sudo tee /proc/sys/vm/compact_memory

また、はい、巨大なページは断片化に大きな問題を引き起こします。巨大なページを取得できないか、そのページが存在するため、カーネルが取得しようとして余分な時間を費やすことになります。

私に合った解決策があります。いくつかのサーバーとラップトップで使用しています。仮想マシンに最適です。

kernelcore=4GLinuxカーネルコマンドラインにオプションを追加します。私のサーバーでは8Gを使用しています。カーネルがそのメモリ外に何かを割り当てることを防ぐため、数値に注意してください。多くのソケットバッファを必要とするサーバーや、ディスク書き込みを数百のドライブにストリーミングするサーバーは、このように制限されることを好みません。スラブまたはDMAに「固定」する必要があるメモリ割り当ては、このカテゴリに属します。

その後、他のすべてのメモリが「移動可能」になります。つまり、巨大なページ割り当てのために素敵なチャンクに圧縮できます。透明な巨大ページは、想定どおりに実際に離陸して機能します。カーネルがさらに2Mページを必要とするときはいつでも、4Kページを別の場所に単純に再マッピングできます。

また、これがゼロコピーダイレクトIOとどのように相互作用するのか、完全にはわかりません。「可動ゾーン」のメモリは固定されることを想定していませんが、直接IOリクエストはDMAに対してそれを正確に行います。コピーするかもしれません。とにかくそれを可動ゾーンに固定するかもしれません。どちらの場合でも、おそらくあなたが望んでいたものではありません。