ほぼ満杯のRAMでコンピューターがフリーズする、おそらくディスクキャッシュの問題


74

私が考える問題は、このスレッドにいくらか似てます。

スワップを有効にするか無効にするかは関係ありません。実際に使用されるRAMの量が最大に近くなり、ディスクキャッシュ用のスペースがほとんどなくなると、システムは完全に応答しなくなります。

ディスクは乱暴に回転し、10〜30分間の長い待機の後、フリーズが解除される場合があります(または、我慢が足りない場合もあります)。時々、私がすぐに行動すれば、ゆっくりとコンソールを開き、ブラウザのようなラムを食べるアプリケーションの一部を殺すことができ、システムはほぼ即座にフリーズ解除されます。

この問題のため、スワップには何も表示されず、数MBしか存在しない場合があり、この問題が発生した直後になります。私がそれほど教育されていない推測は、それが何らかの方法で貪欲すぎるディスクキャッシュに接続されているか、メモリ管理が寛大すぎるため、メモリが必要なときに十分にすぐに解放されず、システムが枯渇することです。

ディスクキャッシュに読み込まれたラグファイル(500MB以上)を操作し、その後システムがそれらを十分に速くアンロードできない場合、問題は非常に速く達成できます。

どんな助けやアイデアも大歓迎です。

今のところ私は絶え間ない恐怖に耐えなければなりません。何かをするときはただフリーズすることができ、通常は再起動する必要があります。それが本当にRAMを使い果たしている場合は、broser(できれば最初に何を殺すかをマークできれば)

この状況では、なぜミステリーがスワップしないのでしょうか。

更新:しばらくはハングしませんでしたが、今度は何度か発生しました。私は現在、常に画面にRAMモニターを保持していますが、ハングが発生した場合でも、〜30%の空きがありました(おそらくディスクキャッシュで使用されます)。その他の症状:ビデオ(VLCプレーヤー)を視聴しているときに最初にサウンドが停止し、数秒後に画像が停止します。サウンドが停止している間、私はまだPCをある程度制御できますが、画像が停止すると、マウスを動かすことさえできなくなるので、しばらく待ってから再開しました。ちなみに、ビデオを視聴し始めたときはこれは起こりませんでしたが、しばらくの間(20分)、ブラウザとoowriteが常に2番目の画面で開いていても、その時点では積極的に何もしませんでした。基本的には、ある時点で何かが発生することを決定し、システムをハングさせます。

コメントのリクエストに応じて、ハングの直後にdmesgを実行しました。私は奇妙なことに気づきませんでしたが、何を見るべきか知らなかったので、ここにあります:https ://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=en_US &authkey=CPzF7bcC


11
これにはもっと注意を払う必要があります。私は長年にわたって報告されたバグがあることを知っています。
n3rd

1
@ n3rd:これはバグです。
ダンダスカレスク

@KrišjānisNesenbergs:長いファイルをコピーして貼り付けるのが間違っている場合は、修正してください。
Rick2047

この質問をして解決策を見つけてくれてありがとう。更新に日付を追加してください。そうしないと、何が機能し、何が機能しなかったのかがわかりません。私は常にメモリレベルをチェックしています、同じ問題を抱えている、と私は...私はそのようにそれを修正することができるかどうかを確認するために、32ギガバイトを持っていることを計画し、16ギガバイトを持っている
ベトAveiga

回答:


63

この問題を解決するには、物理​​RAM全体の5%〜6%をコンピューターのコア数で割った値に以下の設定を設定する必要があることがわかりました。

sysctl -w vm.min_free_kbytes=65536

これはコアごとの設定であるため、2 GBのRAMと2つのコアがある場合、1 GBの6%を計算し、安全のために少し余分に追加しました。

これにより、コンピューターはこの量のRAMを空き状態に保とうとしますが、そうすると、ディスクファイルをキャッシュする機能が制限されます。もちろん、まだそれらをキャッシュしてすぐにスワップアウトしようとするので、スワップも制限する必要があります。

sysctl -w vm.swappiness=5

(100 =可能な限り頻繁にスワップ、0 =必要に応じてのみスワップ)

その結果、Linuxは、ランダムに約1GBのムービーファイル全体をRAMでロードすることをランダムに決定することはなく、そうすることでマシンを強制終了します。

メモリー不足を回避するのに十分な予約スペースがありますが、これは明らかに問題でした(以前のようにフリーズがなくなるため)。

1日テストした後、ロックアップはなくなり、時々キャッシュがより頻繁にキャッシュされるため、軽微なスローダウンが発生しますが、数時間ごとにコンピューターを再起動する必要がなければ、私はそれに耐えることができます。

ここでの教訓は-デフォルトのメモリ管理はユースケースの1つにすぎず、一部の人が別の方法で提案しようとしても、常に最良とは言えません-ホームエンターテイメントubuntuはサーバーとは異なるように構成する必要があります。


これらの設定を次の/etc/sysctl.confように追加して、永続的にしたいでしょう。

vm.swappiness=5
vm.min_free_kbytes=65536

問題をよりよく認識できるようにバグを報告してみてください。映画全体をランダムに読み込まないように誰かが解決策を見つけられることを願っています。
Oxwivi

ありがとう、非常に詳細で私の問題を説明しています。とても有難い!
odedbd

1
まあ、私はほとんどすべてを試しましたが、あなたの提案だけが物事を改善しました。ありがとう
vitalii

1
スワップパーティションなしで実行している場合、5〜6%を超える量を使用する必要がありますか?そしてvm.swappiness、その場合、設定は何もしません、と思いますか?
ジャレットミラード

1
「[vm.min_free_kbytes]は、コンピューターにこの量のRAMを解放するように強制します。これにより、ディスクファイルをキャッシュする機能が制限されます。」-わざわざ申し訳ありませんが、これは何をするかとは関係ありませんvm.min_free_kbytes。これは、__GFP_WAITシステムメモリの競合が激しい場合にアトミック(つまり、fillまたはkill / non- )割り当てを容易にするために予約されたページのブロックとして機能します。それは可能性が実際に(おそらく、これらの屋台は、システムメモリの競合に関連しているとして)ここでそれを高めるために理にかなって、それは確かにこの答えで説明する理由ではないでしょう。
クリスダウン

9

これは、Ubuntu 14.04の新規インストールで起こりました。

私の場合、前述のsysctlの問題とは何の関係もありませんでした。

代わりに、問題は、インストール中にスワップパーティションのUUIDがインストール後と異なることでした。そのため、私のスワップは決して有効にならず、数時間使用するとマシンがロックアップしました。

解決策は、とのスワップパーティションの現在のUUIDを確認することでした

sudo blkid

そしてsudo nano /etc/fstab、不正なスワップのUUID値をblkidによって報告された値に置き換えます。

変更に影響を与える簡単な再起動、そして出来上がり。


3
どうもありがとうございます!私はこの信じられないほど腹立たしいバグに1年近く苦労しており、それを修正するためにあらゆることを試みました。Linuxにこのような動作があるのはなぜですか?スワップがないように振る舞うべきで、OOM-killerを起動するだけのようです。代わりに、スワップがあるように見せかけているように見えますが、実際にスワップアウトすることはできません(不適切に設定されているため、実際にはスワップアウトされないため)。
crazy2be

@ crazy2beそれは失敗ではなく、無限に成功しています。スワップがなくても、Linuxはメモリ内のプログラムおよび変更されていないファイルをページアウトし、ディスクからそれらを再読み取りできます。
マーティンソーントン

4

この質問は古いことは知っていますが、Acer C720 ChromebookのUbuntu(Chrubuntu)14.04でこの問題が発生しました。KrišjānisNesenbergsのソリューションを試してみたところ、多少は機能しましたが、まだクラッシュすることがありました。

最終的に、SSDで物理スワップを使用する代わりにzramをインストールすることで機能するソリューションを見つけました。それをインストールするには、次のようにここの指示に従ってください:

sudo apt-get install zram-config

その後、/etc/init/zram-config.conf21行目を変更することで、zramスワップのサイズを構成できました。

20: # Calculate the memory to user for zram (1/2 of ram)
21: mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

zramのサイズを、持っているRAMの量と同じサイズにするために、2を1に置き換えました。そうして以来、フリーズしたりシステムが応答しなくなったりすることはありません。


zramRAMを追加インストールできない場合にのみ実行可能なオプションです。SSDにスワップするときにシステムの速度が遅すぎてスワップなしでRAMがなくなったzram場合、もう少しやり直そうとすると、結果はスワップなしのRAM不足と同じになります。
ミッコランタライネン

4

何も私のために働いた!!

そこで、メモリ使用量を監視するスクリプトを作成しました。メモリ消費がしきい値を増やすと、最初にRAMキャッシュをクリアしようとします。スクリプトでこのしきい値を設定できます。それでもメモリ消費量がしきい値を下回らない場合は、メモリ消費量がしきい値を下回るまで、メモリ消費量の降順でプロセスが1つずつ強制終了されます。デフォルトで96%に設定しました。スクリプト内の変数RAM_USAGE_THRESHOLDの値を変更することで構成できます。

大量のメモリを消費するプロセスを強制終了することは完璧な解決策ではありませんが、すべての作業を失うのではなく、1つのアプリケーションを強制終了することをお勧めします。RAMの使用量がしきい値を増やすと、スクリプトはデスクトップ通知を送信します。また、プロセスを強制終了した場合も通知します。

#!/usr/bin/env python
import psutil, time
import tkinter as tk
from subprocess import Popen, PIPE
import tkinter
from tkinter import messagebox
root = tkinter.Tk()
root.withdraw()

RAM_USAGE_THRESHOLD = 96
MAX_NUM_PROCESS_KILL = 100

def main():
    if psutil.virtual_memory().percent >= RAM_USAGE_THRESHOLD:
        # Clear RAM cache
        mem_warn = "Memory usage critical: {}%\nClearing RAM Cache".\
            format(psutil.virtual_memory().percent)
        print(mem_warn)
        Popen("notify-send \"{}\"".format(mem_warn), shell=True)
        print("Clearing RAM Cache")
        print(Popen('echo 1 > /proc/sys/vm/drop_caches',
                    stdout=PIPE, stderr=PIPE,
                    shell=True).communicate())
        post_cache_mssg = "Memory usage after clearing RAM cache: {}%".format(
                            psutil.virtual_memory().percent)
        Popen("notify-send \"{}\"".format(post_cache_mssg), shell=True)
        print(post_cache_mssg)

        if psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD:
            print("Clearing RAM cache saved the day")
            return
        # Kill top C{MAX_NUM_PROCESS_KILL} highest memory consuming processes.
        ps_killed_notify = ""
        for i, ps in enumerate(sorted(psutil.process_iter(),
                                      key=lambda x: x.memory_percent(),
                                      reverse=True)):
            # Do not kill root
            if ps.pid == 1:
                continue
            elif (i > MAX_NUM_PROCESS_KILL) or \
                    (psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD):
                messagebox.showwarning('Killed proccess - save_hang',
                                       ps_killed_notify)
                Popen("notify-send \"{}\"".format(ps_killed_notify), shell=True)
                return
            else:
                try:
                    ps_killed_mssg = "Killed {} {} ({}) which was consuming {" \
                                     "} % memory (memory usage={})". \
                        format(i, ps.name(), ps.pid, ps.memory_percent(),
                               psutil.virtual_memory().percent)
                    ps.kill()
                    time.sleep(1)
                    ps_killed_mssg += "Current memory usage={}".\
                        format(psutil.virtual_memory().percent)
                    print(ps_killed_mssg)
                    ps_killed_notify += ps_killed_mssg + "\n"
                except Exception as err:
                    print("Error while killing {}: {}".format(ps.pid, err))
    else:
        print("Memory usage = " + str(psutil.virtual_memory().percent))
    root.update()


if __name__ == "__main__":
    while True:
        try:
            main()
        except Exception as err:
            print(err)
        time.sleep(1)

save_hang.pyというファイルにコードを保存します。次のようにスクリプトを実行します。

sudo python save_hang.py

このスクリプトはPython 3のみと互換性があり、tkinterパッケージをインストールする必要があることに注意してください。次のようにインストールできます。

sudo apt-get install python3-tk

お役に立てれば...


2

私の推測ではvm.swappiness、非常に低い値に設定しているため、カーネルのスワップが遅すぎて、システムが動作するにはRAMが低すぎます。

以下を実行することで、現在のスワップ設定を表示できます。

sysctl vm.swappiness

デフォルトでは、これは60に設定されています。UbuntuWiki では 10に設定することをお勧めしていますが、より高い値に設定することもできます。以下を実行することで変更できます:

sudo sysctl vm.swappiness=10

これにより、現在のセッションでのみ変更され、永続化するvm.swappiness = 10には、/etc/sysctl.confファイルに追加する必要があります。

ディスクが遅い場合は、新しいディスクの購入を検討してください。


実際にスワッピングを減らすことで問題が減りました(まれにしか起こりませんでした)。私は今5のままにしています。60歳のときに映画を見たり、大きなファイルを編集することにしたとき、ほぼGBのファイル全体がメモリにロードされ、すぐにシステムがプログラムをスワップアウトし始めたため、ハイジャースワップインの別の問題だったかもしれません積極的に使用し、ユーザーインターフェイス自体も使用します。スワップ部分を理解していると思います。RAMを使い果たしたときにマシンをフリーズするのではなく、欲張りなユーザーアプリケーションを殺すことです。(好ましくは、キャッシュ内のファイルのサイズを制限)
KrišjānisNesenbergs

@Krisa:システムがメモリ(RAMおよびスワップ)を使い果たすと、カーネルはoom_killを呼び出し、プロセスを強制終了してメモリを節約します。残念ながら、ターゲットプロセスを制御することはできません。手動でトリガーするには、Alt + SysRq + Fを押しdmesgます。コマンドを実行すると、プロセスの情報(およびプロセス名+ id)が表示されます。新しい高速のディスクを購入する方が良いと思います。または、RAMをアップグレードします。
-Lekensteyn

3
問題は、コンピューターが約30分間ロックされる前にoom_killが呼び出されないことです。また、少なくともどのプロセスが最初に強制終了されるかを知る方法はありますか?
クリシャニスネゼンベルグス

2
2GBのRAMがあり、HDDは5400rpmです。あるモニターでビデオを視聴し、別のモニターで20〜30個のタブを閲覧している間に30分フリーズするのを正当化するような古いシステムだとは本当に思いません。実際、私は常にコンソールにアクセスしていくつかのプロセスを殺すことができれば非常に満足しています-システムのフリーズ中に動作するようにユーザー入力と端末を非常に高い優先度にする方法はありますか?
クリシャニスネゼンベルグス

1
とにかく-スワップとRAMの量は少しオフトピックです。問題は、スワップが無効になっていてもシステムが長時間応答しなくなり、その後プログラムを実行することがあるため(どこかでメモリを見つけることができます)、その他の場合はoom_killerを実行することです。システムは、RAMが不足していることを通知できるはずです。だから、それらのフリーズを停止したり、ユーザー入力の優先度を非常に高く設定したり、それらが発生したときにコンソールに切り替えて自分でいくつかのプロセスを殺すことができる方法はありますか?
クリシュジャニスネゼンバーグ11年

2

私はこの問題に長い間苦労してきましたが、今では私のラップトップで解決されるようです。

他の答えがどれもうまくいかない場合は(ほとんどのことを試してみました)、min_free_kbytesで遊んで、コンピューターがスワッピングを開始するときにRAMの空き容量を増やします(空きRAMでこの最小値に達する直前)。

16GBのRAMがありますが、やがてメモリがいっぱいになり、スワップされるまで10〜30分間応答を停止しました。

少なくとも私にとっては、min_free_kbytesの値を推奨値よりも高く設定すると、スワッププロセスがかなり速くなります。

16GB RAMの場合、これを試してください:

vm.min_free_kbytes=500000

この値を設定するには、他の回答を参照するか、単にグーグルで検索してください:)


0

私はラップトップの1台をUbuntuのライブSDカードから常に実行し、小さなext4ストレージパーティションとハードドライブ上のスワップファイルを使用します。ほとんどすべてのRAMが使用されており、swapiness値が低すぎる場合(ノイズが多いため、可能であればハードドライブを完全にオフにしたほうがよい場合があります) Firefoxを強制終了するTTY1には15分かかります。

/proc/sys/vm/vfs_cache_pressureデフォルトの100から6000の値に上げると、これを防ぐのに役立つようです。しかし、カーネルのドキュメントはそうすることに対して警告しています。

Increasing vfs_cache_pressure significantly beyond 100 may have negative
performance impact. Reclaim code needs to take various locks to find freeable
directory and inode objects. With vfs_cache_pressure=1000, it will look for
ten times more freeable objects than there are.

私はこれを行うことの副作用が完全にはわからないので、これを行うには注意が必要です。


vfs_cache_pressure10に近い(つまり、100をはるかに下回る)min_free_kbytesほど高く設定すると、おそらくより良い結果が得られます。設定min_free_kbytesが高すぎると、カーネルOOMキラーが全員を殺すことに注意してください!
ミッコランタライネン

@MikkoRantalainen私はすでにmin_free_kbytes262144に上げましたvfs_cache_pressureが、下げると逆の効果があることを観察しました-100未満に下げると、システムがはるかに速く応答しなくなります。正確な理由はわかりません。
Hitechcomputergeek

一般vfs_cache_pressureに、キャッシュファイルのコンテンツの前にディレクトリを増やすと、結果として、通常100を超える値で全体的なパフォーマンスが低下します。たとえば、Ubuntu Live CDで始まるシステムをクラッシュ/ハングさせる再現手順を理解できる場合カーネル開発者は根本原因を突き止めることができます。私にとって、ハングは警告なしに発生します。私の最善の推測は、OOM Killerが十分なRAMを解放する前に、OOMのためにカーネルがハングすることです。現在、min_free_kbytes = 100000、admin_reserve_kbytes = 250000、user_reserve_kbytes = 500000を実行しています。
ミッコランタライネン

(続き)swappiness = 5およびvfs_cache_pressure = 20であっても、上記の構成ではまだクラッシュしていません。システムには、SSDに16 GBのRAMと8 GBのスワップがあります。別のシステムには32 GBのRAMとゼロスワップがあり、同じ問題にランダムに苦しんでいるようです-システムが遅いと感じた後にAlt + SysRq + fを押すと助けになるようです。
ミッコランタライネン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.