13

私のUbuntu 12サーバーは不思議なことにメモリを失ったり浪費しています。64GBのRAMを搭載。すべてのアプリケーションをシャットダウンしても、約 46GB が使用済みとして表示されます。このメモリは、バッファまたはキャッシュに使用されるとは報告されていません。

top の結果 (私のアプリの実行中。アプリは約 9G を使用します):

top - 21:22:48 up 46 days, 10:12,  1 user,  load average: 0.01, 0.09, 0.12
Tasks: 635 total,   1 running, 633 sleeping,   1 stopped,   0 zombie
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 99.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65960100k total, 55038076k used, 10922024k free,   271700k buffers
Swap:        0k total,        0k used,        0k free,  4860768k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                         
  5303 1002      20   0 26.2g 1.2g  12m S    0  1.8   2:08.21 java                                                                                                                                             
  5263 1003      20   0  9.8g 995m 4544 S    0  1.5   0:19.82 mysqld                                                                                                                                           
  7021 www-data  20   0 3780m  18m 2460 S    0  0.0   8:37.50 apache2                                                                                                                                          
  7022 www-data  20   0 3780m  18m 2540 S    0  0.0   8:38.28 apache2      
  .... (smaller processes)

top はキャッシュに対して 48G ではなく 4.8G を報告しており、使用されているのは 55G であることに注意してください。free -m の結果:

             total       used       free     shared    buffers     cached
Mem:         64414      53747      10666          0        265       4746
-/+ buffers/cache:      48735      15678
Swap:            0          0          0

何が私のメモリを使用していますか? 出くわす可能性のあるすべての診断を試しました。Linux はバッファ/キャッシュに RAM を使用しているため、フォーラムには同じ質問をする人が殺到しています。これはここで起こっていることではないようです。

システムが lxc コンテナーのホストであることが関連している可能性があります。上記で報告された上位および無料の結果はホストからのものですが、コンテナ内でも同様のメモリ使用量が報告されています。すべてのコンテナを停止しても、メモリは解放されません。一部の 46G は使用されたままです。ただし、ホストを再起動すると、メモリは解放されます。しばらくすると46Gに達しません。（数日か数週間かかるかはわかりません。数時間以上かかります。）

システムが zfs を使用していることも関連している可能性があります。Zfs はメモリを大量に消費すると言われていますが、それほど多くはありません。このシステムには、1.5T と 200G の 2 つの raidz プールに 2 つの zfs ファイルシステムがあります。まったく同じ問題 (何も使用されていない 46G) を示す別のサーバーがあり、ほとんど同じように構成されていますが、1.5T ではなく 3T アレイを使用しています。zfs ファイルシステムごとにたくさんのスナップショット (100 程度) があります。私は通常、各ファイルシステムのスナップショットを常に 1 つずつマウントしています。それらをアンマウントしても、記憶は戻りません。

上のスクリーンショットの VIRT 数値は、使用されているメモリとほぼ一致していることがわかりますが、これらのアプリをシャットダウンした後も、それらを実行しているコンテナーをシャットダウンした後でも、メモリは使用されたままです。

編集:スワップを追加してみましたが、興味深いことが起こりました。30Gのスワップを追加しました。しばらくすると、上部にキャッシュとしてマークされたメモリの量が 5G から 25G に増加しました。Free -m は、使用可能なメモリが約 20G 多いことを示しました。さらに 10G のスワップを追加し、キャッシュ メモリを 33G に増やしました。さらに 10G のスワップを追加すると、さらに 6G がキャッシュとして認識されます。この間ずっと、数キロバイトのスワップしか使用されていないと報告されています。あたかも、カーネルが認識またはキャッシュされていると報告するすべてのビットに対して、一致するスワップが必要であるかのようです。40G のスワップを使用した top の出力は次のとおりです。

top - 23:06:45 up 46 days, 11:56,  2 users,  load average: 0.01, 0.12, 0.13
Tasks: 586 total,   1 running, 585 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65960100k total, 64356228k used,  1603872k free,   197800k buffers
Swap: 39062488k total,     3128k used, 39059360k free, 33101572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                         
 6440 1002      20   0 26.3g 1.5g  11m S    0  2.4   2:02.87 java                                                                                                                                             
 6538 1003      20   0  9.8g 994m 4564 S    0  1.5   0:17.70 mysqld                                                                                                                                           
 4707 dbourget  20   0 27472 8728 1692 S    0  0.0   0:00.38 bash

どんな提案でも大歓迎です。

編集 2: /proc/spl/kstat/zfs/arcstats の arc* 値は次のとおりです。

arc_no_grow                     4    0
arc_tempreserve                 4    0
arc_loaned_bytes                4    0
arc_prune                       4    0
arc_meta_used                   4    1531800648
arc_meta_limit                  4    8654946304
arc_meta_max                    4    8661962768

ZFS 用にアクティブ化された L2ARC はありません

4

1 に答える 1

15

このメモリーは、ZFS ARC キャッシュおよびカーネルメモリーに格納されているその他の ZFS 関連データによって使用される可能性が非常に高くなります。ARC キャッシュはバッファ キャッシュに似ているため、通常、このメモリは必要に応じて ZFS によって解放されるため、心配する必要はありません。

ただし、バッファ キャッシュ メモリと ARC キャッシュ メモリには微妙な違いがあります。最初のものは割り当てにすぐに利用できますが、ARC キャッシュのものはそうではありません。ZFS は使用可能な空き RAM を監視し、少なすぎる場合は RAM を他の消費者に解放します。

これはほとんどのアプリケーションで問題なく動作しますが、一部のアプリケーションでは、使用可能な RAM の量が少ないと報告されたときに混乱したり、リリース プロセスが適切にペースを維持するために割り当てられたメモリが多すぎたり速すぎたりします。

これが、ZFS で ARC サイズが使用できる最大サイズを減らすことができる理由です。この設定は/etc/modprobe.d/zfs.confファイルで行います。

たとえば、ARC が 32 GB を超えないようにするには、次の行を追加します。

options zfs zfs_arc_max=34359738368

現在の ARC サイズとその他のさまざまな ARC 統計を取得するには、次のコマンドを実行します。

cat /proc/spl/kstat/zfs/arcstats

sizeメトリックは、ARC の現在のサイズを示します。他の ZFS 関連のメモリ領域も RAM を共有する可能性があり、使用されなくなってもすぐに解放されるとは限らないことに注意してください。最後に、Linux 上の ZFS は、Solaris のネイティブ実装よりも確かに成熟度が低いため、このようなバグに見舞われる可能性があります。

共有ストレージ プールの設計により、ZFS ファイル システムをアンマウントしてもリソースは解放されないことにも注意してください。最終的にメモリを解放するには、プールをエクスポートする必要があります。

于 2013-09-15T02:19:04.723 に答える