無料のRAMが消える-メモリリーク？
新しく起動されたシステムでは、freeが使用された1.5Gについて報告しますRAM（8G RAM_ together、lightdmおよびplasmaデスクトップを備えたUbuntu 12.04、1つのkonsoleウィンドウが起動しました）。私が使用しているアプリを実行していても、消費するのはまだ2G以下です。ただし、システムを数日間実行すると、使用中のアプリのリストに表示されずに、ますます多くの無料のRAMが消えます：smem --pie=nameは20％未満の使用を報告します（および80％が利用可能）、他のすべての表現は異なります。 free -mたとえば、約7日目のレポート：
total used free shared buffers cached
Mem: 7459 7013 446 0 178 997
-/+ buffers/cache: 5836 1623
Swap: 9536 296 9240
（ご覧のとおり、バッファでもキャッシュでもありません）。今日、これはついにシステムが完全にクラッシュすることで終わりました：Windowsマネージャーが消え、アプリが「空中にぶら下がっています」（フレームレス）-ポップアップが「開いているファイルが多すぎる」ことを通知します。 syslogレポート：
kernel: [856738.020829] VFS: file-max limit 752838 reached
そこで、閉じることができたアプリケーションを閉じ、Ctrl-Alt-backspaceを使用してXを強制終了しました。 Xはその後failsafeXを使用して再度起動しようとしましたが、構成を検出できなくなったため、起動できませんでした。そこで、Ctrl-Alt-F2を使用してコンソールに切り替え、考えられるすべての情報（vmstat、free、smem、proc/meminfo、lsof、ps aux）をキャプチャし、最後に再起動しました。 Xは再びfailsafeXを思いつきました。今回は、「バックアップされた構成から回復する」ように指示し、コンソールに切り替えて、startxを使用してグラフィカル環境を正常に起動しました。
Xを殺した後、free -mの出力は次のようになったので、この問題の原因については本当の手がかりはありませんが、X自体またはXで実行されているユーザープロセスのいずれかを使用する必要があります：
total used free shared buffers cached
Mem: 7459 2677 4781 0 62 419
-/+ buffers/cache: 2195 5263
Swap: 9536 59 9477
（〜3.5GBが解放されます）-再起動後の出力と比較するには：
total used free shared buffers cached
Mem: 7459 1483 5975 0 63 730
-/+ buffers/cache: 689 6769
Swap: 9536 0 9536
memstat -uにより、さらに2つの有用な出力が提供されます。クラッシュの少し前：
User Count Swap USS PSS RSS
mail 1 0 200 207 616
whoopsie 1 764 740 817 2300
colord 1 3200 836 894 2156
root 62 70404 352996 382260 569920
izzy 80 177508 1465416 1519266 1851840
Xを殺した後：
User Count Swap USS PSS RSS
mail 1 0 184 188 356
izzy 1 1400 708 739 1080
whoopsie 1 848 668 826 1772
colord 1 3204 804 888 1728
root 62 54876 131708 149950 267860
そして、再起動後、Xに戻ります。
User Count Swap USS PSS RSS
mail 1 0 212 217 628
whoopsie 1 0 1536 1880 5096
colord 1 0 3740 4217 7936
root 54 0 148668 180911 345132
izzy 47 0 370928 437562 915056
編集：監視システムから2つのグラフを追加しました。興味深いことに、メモリ消費量に「ジャンプ」があるたびに、CPUもピークに達します。たった今これを見つけました-それは、X自体を指している別のインジケーターを思い出させます：私のマシンに戻って画面のロックを解除するとき、しばしばCPUで重い仕事をしている何かを見つけました。 topで確認すると、常に/usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background noneであることが判明しました。
この長い説明の後、最後に私の質問：
- 考えられる原因は何ですか？
- 関係するプロセス/アプリケーションをよりよく特定するにはどうすればよいですか？
- この動作を回避するためにどのような手順を踏むことができますか？X日間すべてマシンを再起動するのに短いですか？
古いマシンで約5年間8.04（Hardy）を実行していましたが、同じようなことは一度もありませんでした（たとえば、カーネルの更新のために再起動する前に常に100日以上の稼働時間）。これは、12.04の新規インストールの完全な新しいマシンです。重要な場合、いくつかの仕様：
AMD A4-3400 APU Radeon（tm）HD Graphics、オープンソースATI/radeonドライバー（fglrxはインストールされていない）、8GB RAM、WDC WD1002FAEX-0 hdd（1TB）、Asus F1A75- V Evoメインボード。 KDE4/Plasmaを使用したUbuntu 12.04 64ビット。通常、アプリは多かれ少なかれ恒久的に開き、Evolution、Firefox、konsole（Midnight Commanderを実行中、約4つのタブ）、およびLibreOfficeに加えて、Calibre、Gimp、Moneyplex（私はすでに20年近く使用している銀行ソフトウェア）、 Hardyで問題なく動作したバージョン）。
編集：今日、私は「悪人」の1人を見つけました：KDE4sプラズマデスクトップ。 killall plasma-desktop && plasma-desktopを実行したとき、使用済みメモリは再び最大5GBでした。これにより、1.3GBのRAMが解放されました！ psさんのコメント：
RSS SIZE VSZ
plasma usage before restart 120988 526472 1300816
plasma usage after restart 92352 495972 1263632
では、1.3GBはどこにあるのでしょうか？これらの値の差分を合計すると、1.3GBではなく96MBになります。
そして、3.7GBがまだ使用されているので、これは1つの部分のみになります（2GB未満でなければなりません）。過去6日間、いくつかのツールを使用してこれを監視しました。使用されたメモリ（キャッシュとバッファについては説明していません）はゆっくりですが着実に増加します。机に何も走らなくても...
開いているファイルを使用したプロセスの監視については、現在、次の1ライナー（シェルと特にbashが大好き）を使用してトップ5を取得しています。
echo "$(for pid in $(ls -a /proc|egrep '^([0-9])*$'|sort -n 2>/dev/null); do \
if [ -e /proc/$pid/fd ]; then FHC=$(ls -l /proc/$pid/fd|wc -l); \
if [ $FHC -gt 0 ]; then PNAME="$(cat /proc/$pid/comm)"; \
echo "$FHC files opened by $pid ($PNAME)"; fi; fi; done)"|sort -r -n|head -n5
読みやすくするため、ここに4行でコマンドを入力します。そこからはまだ何もありません-Skypeがインターネット接続の切断を好まないことを除いて。切断するたびに、開いているファイルがわずかに増加しますが、劇的なことはありません。一方、プラズマもその原因であるようです：
最後にファイルハンドルのドロップを参照してください？それはプラズマの再起動でした。
膨大な数のオープンファイルは、何か問題が発生していることを示す良い手がかりです。私の推測では、KDEシステムデーモンでしょう。
コンソールを開き、「top」を実行します。次に、<および>を使用してソート列をVIRTまたはRESに変更し、どのプログラムが最もメモリを使用しているかを確認します。メモリリークは、リークしたメモリへのポインタが失われると使用されず、スワップアウトされるため、仮想メモリの使用量が大幅に増加するために現れます。また、「lsof」を実行して、多数のオープンファイルがあるプロセスを探します。これは、実際にはファイル記述子のリークのようです。
プログラムを追跡し、バグを報告してください。
それは通常のシステムの振る舞いだと思います。ほとんどの場合、すべてが正常です。
LinuxがRAMをどのように管理しているか、なぜ心配する必要がないのかを理解するために、この素晴らしい論文（Linuxは私のRAMを食べました）を読むことができます。