私が思う問題は、 this スレッドにいくらか似ています。
スワップを有効にするか無効にするかは関係ありません。実際に使用される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
この問題を解決するには、次の設定を物理RAM全体の約5%〜6%に設定し、コンピューターのコア数で割る必要があることがわかりました。
sysctl -w vm.min_free_kbytes=65536
これはコアごとの設定であるため、2GB 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
これは、Ubuntu 14.04の新規インストールで起こりました。
私の場合、前述のsysctlの問題とは何の関係もありませんでした。
代わりに、問題は、インストール中にスワップパーティションのUUIDがインストール後と異なることでした。そのため、私のスワップは決して有効にならず、数時間使用するとマシンがロックアップしました。
solution は、スワップパーティションの現在のUUIDを確認することでした
Sudo blkid
次に、Sudo nano /etc/fstab
を使用して、誤ったスワップのUUID値をblkidによって報告されたものと置き換えます。
変更に影響を与える簡単な再起動、そして出来上がり。
この質問は古いことは知っていますが、Acer C720 ChromebookのUbuntu(Chrubuntu)14.04でこの問題が発生しました。 KrišjānisNesenbergsのソリューションを試してみたところ、多少は機能しましたが、それでも時々クラッシュしました。
最終的に、SSDで物理スワップを使用する代わりにzramをインストールすることで機能するソリューションを見つけました。これをインストールするには、次のように here の指示に従いました。
Sudo apt-get install zram-config
その後、21行目で/etc/init/zram-config.conf
を変更することにより、zramスワップのサイズを構成することができました。
20: # Calculate the memory to user for zram (1/2 of ram)
21: mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))
Zramのサイズを、持っているRAMの量と同じサイズにするために、2を1に置き換えました。そうしてから、フリーズしたりシステムが応答しなくなったりすることはもうありません。
何も私のために働いた!!
そこで、メモリ使用量を監視するスクリプトを作成しました。メモリ消費量がしきい値を増やすと、最初に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 __== "__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
お役に立てれば...
私の推測では、vm.swappiness
を非常に低い値に設定したため、カーネルのスワップが遅すぎて、システムが動作するにはRAMが低すぎます。
以下を実行することで、現在のスワップ設定を表示できます。
sysctl vm.swappiness
デフォルトでは、これは60に設定されています。 buntu Wiki は、10に設定することを推奨していますが、より高い値に設定することもできます。以下を実行することで変更できます:
Sudo sysctl vm.swappiness=10
これにより、現在のセッションのみで変更されます。永続化するには、vm.swappiness = 10
を/etc/sysctl.conf
ファイルに追加する必要があります。
ディスクが遅い場合は、新しいディスクの購入を検討してください。
私はこの問題に長い間苦労してきましたが、今では私のラップトップで解決されるようです。
他の答えがどれもうまくいかない場合(私はそれらのほとんどを試しました)、min_free_kbytesで遊んで、コンピューターがスワッピングを開始するとき(これを押す直前)にRAMのスペースを増やします空きRAMの最小値)。
16GBのRAMがありますが、すぐにメモリがいっぱいになり、10〜30分間応答が停止しました。
少なくとも私にとっては、min_free_kbytesの推奨値を超える値に設定すると、スワッププロセスがかなり速くなります。
16GB RAMの場合、これを試してください:
vm.min_free_kbytes=500000
この値を設定するには、他の回答を参照するか、単にグーグルで検索してください:)
私はUbuntu 16.04からUbuntu 18.10まで同じ問題に直面しています。しばらくしてFirefoxの複数のタブを使用すると、スタックし、その後何もできなくなります。次に、電源ボタンを押して再度続行します。システムが破損するのではないかと心配です。
私はラップトップの1台をUbuntuのライブSDカードから常に実行し、小さなext4ストレージパーティションとハードドライブ上のスワップファイルを使用します。ほぼすべてのRAMが使用され、swappiness値が低すぎる場合(ノイズが多いため、可能であればハードドライブを完全にオフのままにすることを好む場合があります)、Linuxのパフォーマンスは崖から落ちる傾向があります、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.
私はこれを行うことの副作用が完全にはわからないので、これを行うには注意が必要です。