web-dev-qa-db-ja.com

システムが1時間使用した後、さらにRAM=を使用するのはなぜですか？

XFCE DEおよびXFWM4 WMでArch Linux（5.1.8-Arch1-1-Arch）を使用しています。物事はかなりエレガントで、RAMとCPUの使用率が低くなっています。

起動後、DEが完全にロードされると、RAMの使用率が665 MiBになります。

しかし、Atom、Code、Firefox、Chromiumなどのアプリケーションを開いた後、またはGIMP、Blenderなどで作業した後は、RAMの使用量が増加します。これは明らかです。しかし、すべてのアプリケーションを閉じてgnome-system-monitorだけを残した後、RAMの使用量が1.2〜1.4 GiBであることがわかります。/proc/meminfoはgnome-system-monitorに同意しますが、htopは常に異なる結果を提供します。

さらに悪いのは、後でRAMホギングアプリケーションを開くと、その1.4 GiBに加えて必要なメモリが再び消費されることです。これは常に当てはまります。メガバイトになる可能性のあるファイルは、/ tmp /ディレクトリーに保管されません。

また、それだけRAMを使用しているプロセスを探しても（ブラウザーを閉じた後の700 MiBから1.4 GiBまで!!）、何も表示されません。実際、Arch ARMを実行しているRaspberry Piでも同じ問題に直面しました。

Here's A Screenshot 1Here's A Screenshot 2

Rubyコード：

#!/usr/bin/Ruby -w
STDOUT.sync = true

loop do
    IO.readlines(File.join(%w(/ proc meminfo))).then { |x| [x[0], x[2]] }.map { |x| x.split[1].to_i }.reduce(:-)
        .tap { |x| print "\e[2K\rRAM Usage:".ljust(20), "#{x / 1024.0} MiB".ljust(24), "#{(x / 1000.0)} MB" }
    Kernel.sleep(0.1)
end

cat /proc/meminfoコマンドの出力は次のとおりです。

MemTotal:        3851796 kB
MemFree:         1135680 kB
MemAvailable:    2055708 kB
Buffers:            1048 kB
Cached:          1463960 kB
SwapCached:          284 kB
Active:          1622148 kB
Inactive:         660952 kB
Active(anon):     923580 kB
Inactive(anon):   269360 kB
Active(file):     698568 kB
Inactive(file):   391592 kB
Unevictable:      107012 kB
Mlocked:              32 kB
SwapTotal:       3978216 kB
SwapFree:        3966696 kB
Dirty:               280 kB
Writeback:             0 kB
AnonPages:        924844 kB
Mapped:           563732 kB
Shmem:            374848 kB
KReclaimable:      74972 kB
Slab:             130016 kB
SReclaimable:      74972 kB
SUnreclaim:        55044 kB
KernelStack:        8000 kB
PageTables:        14700 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     5904112 kB
Committed_AS:    3320548 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
Percpu:             1456 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      226736 kB
DirectMap2M:     3778560 kB
DirectMap1G:           0 kB

まず、htopが同意しないことに気づきました。私はそれについてあまり知りません。

次に、xfdesktopが44 MiBを使用し、他のいくつかのプロセスがメモリの一部を使用し、カーネルが約150 MiBを使用していることを確認できます。それとは別に、1.5 GiB RAMが表示されるのはなぜですか。中古？これは本当にシステムのパフォーマンスに影響を与えますか？

performanceram
7
S.Goswami

未使用RAMは無駄なRAMです。Linuxカーネルには高度なメモリ管理機能があり、システムのボトルネックであるハードドライブ/ SSDに負担がかからないようにします。ファイルをメモリにキャッシュしようとします。

メモリ管理システムは複雑な方法で機能し、パフォーマンスの向上が目標です。

/proc/meminfoを調べると、何が行われているかを確認できます。

cat /proc/meminfo

「drop_caches」を使用して、このキャッシュされたメモリを再利用できます。ただし、ドキュメントに「テスト環境またはデバッグ環境以外での使用は推奨されない」と書かれていることに注意してください。単に、「ドロップされたオブジェクトを再作成するために大量のI/OとCPUが必要になる可能性がある」ためです。

PageCacheのみをクリアします。

# sync; echo 1 > /proc/sys/vm/drop_caches

明確なエントリとiノード：

# sync; echo 2 > /proc/sys/vm/drop_caches

PageCache、dentries、inodeをクリアします。

# sync; echo 3 > /proc/sys/vm/drop_caches

syncはファイルシステムバッファをフラッシュして、すべてのデータが書き込まれたことを確認します。

kernel docs ：から

ページキャッシュ

物理メモリは揮発性であり、メモリにデータを取り込む一般的なケースは、ファイルからデータを読み取ることです。ファイルが読み取られるたびに、データがページキャッシュに入れられ、後続の読み取りでの高コストのディスクアクセスが回避されます。同様に、ファイルに書き込むと、データはページキャッシュに配置され、最終的にバッキングストレージデバイスに格納されます。書き込まれたページはダーティとしてマークされ、Linuxが他の目的でそれらを再利用することを決定した場合、デバイス上のファイルの内容を更新されたデータと確実に同期させます。

回収

システムのライフタイム全体を通じて、物理ページを使用してさまざまなタイプのデータを保存できます。これは、カーネルの内部データ構造、デバイスドライバーが使用するDMA可能なバッファー、ファイルシステムから読み取られたデータ、ユーザー空間プロセスによって割り当てられたメモリなどです。

ページの使用状況に応じて、Linuxのメモリ管理による扱いが異なります。ハードディスクなどの他の場所で利用可能なデータをキャッシュするため、またはハードディスクに再度スワップアウトできるため、いつでも解放できるページは、再利用可能と呼ばれます。再利用可能なページの最も注目すべきカテゴリは、ページキャッシュと匿名メモリです。

ほとんどの場合、内部カーネルデータを保持し、DMAバッファーとして使用されているページは、転用できず、ユーザーが解放するまで固定されたままです。そのようなページは、再利用不可能と呼ばれます。ただし、特定の状況では、カーネルデータ構造で占められているページでも再利用できます。たとえば、ファイルシステムメタデータのインメモリキャッシュはストレージデバイスから再読み取りできるため、システムがメモリ不足のときにメインメモリからそれらを破棄することができます。

再利用可能な物理メモリページを解放して再利用するプロセスは、（驚き！）再利用と呼ばれます。 Linuxは、システムの状態に応じて、非同期的または同期的にページを再利用できます。システムがロードされていない場合、メモリの大部分は解放されており、割り当て要求は空きページの供給から即座に満たされます。負荷が増加すると、空きページの量が減少し、一定のしきい値（最高水準点）に達すると、割り当て要求がksw​​apdデーモンを呼び起こします。非同期にメモリページをスキャンし、それらに含まれるデータが他の場所で利用可能な場合は解放するか、バッキングストレージデバイスに追い出します（ダーティページを覚えていますか？）。メモリ使用量がさらに増加し​​、別のしきい値（最小ウォーターマーク）に達すると、割り当てにより直接再利用がトリガーされます。この場合、要求を満たすために十分なメモリページが回収されるまで、割り当ては停止します。

メモリリーク

現在、一部のプログラムでは「メモリリーク」が発生している可能性があります。つまり、使用しなくなったメモリを解放することを「忘れ」ています。これは、プログラムをしばらく実行したままにしておくと、メモリ使用量が常に増加し、プログラムを閉じるとメモリが解放されない場合に確認できます。もちろん、プログラマーはもちろんメモリリークを回避しようとしますが、プログラムにはそれが含まれている可能性があります。このメモリを再利用する方法は再起動です。

19
thecarpy

プロセスとそのメモリ使用量のリストを見ました。しかし、問題がありました。あなたは完全なリストを見ていませんでした。

gnome-system-monitorは、デフォルトでは「マイプロセス」のみを表示します。 rootユーザーを含むすべてのシステムユーザーが所有するプロセスを表示するには、右上のメニューアイコン（縦線の3つのドット）をクリックします。選択を「マイプロセス」から「すべてのプロセス」に変更します。

  1. 中古vs.使用可能なシステムRAM（単一の数値）
  2. / proc/meminfoの分析
  3. 使用できるその他のツール-atopを今日インストール8）

1.中古vs.使用可能なシステムRAM（単一の数値）

あなたのRubyコードはMemAvailableからMemTotalを減算します。これはgnome-system-monitorが使用しているのとまったく同じ計算で、システムが「1.5 GiB（41.4％）of 3.7 GiB）」。

少なくとも最初の概算として、gnome-system-monitorまたは手動の計算のいずれかを使用するのは正しいことです。 MemAvailable番号には、基本的にすべての再利用可能な「キャッシュ」が含まれます。つまりMemAvailableには、プログラムが空きメモリよりも多くのメモリを要求するとすぐに再利用できる「利用可能な」タイプの「キャッシュ」が含まれます。

補足：「キャッシュ」には別のタイプまたは意味があります。つまり、再利用可能ではありません。 Cache/"cache"番号を見ると、通常、Shmem/"shared"が含まれていると報告されています。 Shmemの部分は、再利用可能なキャッシュではありません。 Shmemがカーネルの「ページキャッシュ」を使用して巧妙に実装されたため、混乱が生じます。

「利用可能」をすばやく確認する別の方法は、free -hです。

freeコマンドは、「共有」、スワップの使用法なども表示します。システムのドキュメントには、出力フィールドと使用可能なオプションがman freeにリストされているはずです。他のフィールドのいくつかは誤解を招く可能性があります。

  • freeコマンドの「used」フィールドには（現在）、「shared」は含まれていません。これは非常に混乱する可能性があります。 「中古」フィールドを無視する。
  • freeで示される「キャッシュされた」値は、上記の問題の影響を受けます。
  • freeに「available」が表示されない場合、システムは古くなっています。古いドキュメントを参照してください。

2./proc/meminfoの分析

cat /proc/meminfoの完全な出力をありがとうございます。これは、多くの場合、特定の答え（またはすべての答え）を見つけるのに役立ちます。 MemAvailableの計算方法を自分で確認したい場合は、ここで私の回答の最初のセクションを読むことができます。 「キャッシュされた」メモリは事実上無料ですか？

AnonPages

あなたの例ではmeminfoにはAnonPages: 924844 kB（0.9 GB）があります。 AnonPagesは、MemAvailableを減らす用語の1つです。

AnonPagesが増加している場合、いくつかの実行中のプログラムの「RES」または「RSS」（RAM「セットサイズ」の「常駐」）の増加を示しているはずです。ただし、RSSは誤解を招く可能性があります。

RSSを追加することはできません。共有メモリが二重にカウントされるためです。 [〜＃〜] pss [〜＃〜]を合計する必要があります。これは、共有を考慮した後の比例RSSです。 smemコマンドは、PSSを表示し、合計を計算することもできます。例えば：

  • Sudo smem -t > p; head -n1 p; echo; tail -n17 p-プロセスごとのメモリ使用量を確認します。 tailの部分には、上位15プロセスが表示され、その後に合計PSSなどの行が表示されます。
  • smem -t -U ^sourcejedi$ > U; head -n1 U; echo; tail -n17 U-ユーザー「sourcejedi」に属するプロセスのメモリ使用量を確認します。
  • Sudo smem -t -u-ユーザー別にグループ化されたメモリを確認します。これは、独自のユーザーとして実行される一部のシステムデーモンとログインセッションを区別するのに役立ちます。例えば。 packagekitdはrootユーザーとして実行され、数百メガバイトを使用できます。
  • smem -t -P firefox-Webブラウザのメモリ使用量を確認します:-)。

  • Sudo smem -t -m > m; head -n5 m; echo; tail m-マッピング名でグループ化されたメモリを確認します-キャッシュされたファイルの名前、または "<anonymous>"または "[heap]" 。

    プロセスの「常駐」メモリには、両方の「匿名」メモリと一部のキャッシュファイルが含まれます。 smem -mは、すべてのキャッシュファイルを表示することはできません。現在使用されている特定のタイプのファイルのみを表示できます。具体的には、プログラムが仮想メモリにマッピングしたファイル。これには、mmap（）を使用してマップされたプログラムコード、ライブラリコード、およびファイルが含まれます。

シュメム

また、Shmem: 374848 kB（0.4 GB）もあります。上記でShmem /「共有」について述べました。これは、「使用可能な」メモリを減らす別の用語です。 （再利用可能なキャッシュではありません）。これはかなり正常ですが、それが何であるかを確認することもできます。

一部の共有メモリは、個々のプロセスのメモリとして表示されます。共有メモリがプロセスによってマップされている場合、RSS/PSSでカウントする必要があります。上記を参照。ここで「マッピング名」が役立つ場合があります（例：smem -t -m）。

Shmemには、マウントされたtmpfs上のファイルが含まれます。 df -t tmpfsを使用して、マウントされているすべてのtmpfsを確認できます。

システムによっては、Shmemにグラフィックスバッファーが含まれる場合があります。私のシステム（Intelグラフィックス）で現在のサイズを確認する方法を見つけました： GEMバッファーとして割り当てられているメモリの量を確認できますか？ 別の方法を見つけたら知りたいですシステムを確認してください！

他のグラフィックスドライバーのShmemメモリリークは、Xorgの非常に大きなVIRT（別名VSIZE）に関連している可能性があることを読みました。 スワップ全体を使用するLinux、十分な空きRAMがある間は応答しなくなります

他のメモリ使用量？

  • MemTotal - MemAvailable = 1796088 kB（1.8 GB）
  • AnonPages: 924844 kB（0.9 GB）
  • Shmem: 374848 kB（0.4 GB）

残りの0.5 GBのうち、全体で0.1 GB未満の小さな使用がいくつかあります。カーネルも数パーセントのマージンを確保しています（「最低水準点」を参照）が、システム上では0.2 GB以下になると思います。だから私にはわからない使用法がもう少しあります。

カーネルスラブメモリ

「再利用不可能なスラブ」メモリは、MemAvailableを削減するもう1つの用語です。あまりありません：SUnreclaim: 55044 kB（0.05 GB）。

Slabtopを実行して、スラブのリストを表示することもできます。 AFAICT、slabtopはスラブの統計を再生可能または再生不可として提供しません。しかし、通常は推測できます。疑わしいスラブがある場合は、名前で検索できます。

3.使用できる他のツール-atopを今日インストール8）

smemはやり過ぎかもしれません。時には、必要なのはtop、またはお気に入りの選択肢であり、常駐メモリでソートする方法を知ることです。 （gnome-system-monitorはこれには適さないかもしれませんが、実際には十分に表示されないと思います）。

パフォーマンスに問題がある場合は、代わりにディスクの読み取りと書き込みを確認する必要があります。 Sudo iotopを使用できます。

プロセスごとのメモリ使用量のログが必要な場合があるので、メモリが不足し、システムがクロールする速度を低下させた理由を確認できます...

atopは、上記のすべてを実行できる気の利いた小さなツールです。これが便利に思えるなら、すぐにインストールすることをお勧めします。その後、必要なときにそれについて学ぶことができます:-)。

Sudo atop -Rは「PSIZE」を示します（「PSS」と同じ意味です）。 atopパッケージには、10分間隔で実行されるバックグラウンドサービスが含まれています。 atop -r ...を使用して、/ var/log/atop /に保存されているログファイルを開くことができます。

2
sourcejedi