Komputer zawiesza się na prawie pełnej pamięci RAM, prawdopodobnie problem z pamięcią podręczną dysku

Problem, który moim zdaniem jest nieco podobny do tego wątku.

Nie ma znaczenia, czy mam włączoną lub wyłączoną zamianę, ilekroć rzeczywista wykorzystana ilość pamięci RAM zaczyna zbliżać się do maksimum i prawie nie ma już miejsca na pamięć podręczną dysku, system całkowicie przestaje odpowiadać.

Dysk obraca się dziko i czasami po długich odczekaniach 10-30 minut odmrozi, a czasem nie (lub zabraknie mi cierpliwości). Czasami, jeśli działam szybko, potrafię powoli otworzyć konsolę i zabić niektóre aplikacje wykorzystujące barana, takie jak przeglądarka, a system od razu się zawiesza.

Z powodu tego problemu prawie nigdy nie widzę niczego w zamianie, tylko czasami jest tam kilka MB, a wkrótce potem pojawia się ten problem. Domyślam się, że nie jest tak dobrze wykształcony, że jest on w jakiś sposób podłączony do zbyt chciwej pamięci podręcznej dysku lub zbyt łagodnego zarządzania pamięcią, więc kiedy pamięć jest potrzebna, nie jest wystarczająco szybko zwalniana i głodzi system.

Problem można rozwiązać naprawdę szybko, jeśli pracujesz z plikami lagrge (500 MB +), które są ładowane do pamięci podręcznej dysku i pewnie potem system nie jest w stanie ich wystarczająco szybko rozładować.

Każda pomoc lub pomysły będą mile widziane.

Na razie muszę żyć w ciągłym strachu, kiedy robiąc coś, komputer może po prostu zawiesić się i zwykle muszę go ponownie uruchomić, jeśli naprawdę kończy się RAM, wolałbym zabić niektóre aplikacje przestrzeni użytkownika, takie jak broser ( najlepiej gdybym mógł jakoś oznaczyć, który zabić jako pierwszy)

Chociaż tajemnicą jest to, dlaczego zamiana nie ratuje mnie w tej sytuacji.

AKTUALIZACJA: Przez pewien czas się nie zawieszał, ale teraz znów mam kilka wystąpień. Teraz cały czas trzymam monitor RAM na ekranie, a kiedy się zawiesił, nadal pokazywał ~ 30% wolnego (prawdopodobnie używany przez pamięć podręczną dysku). Dodatkowe objawy: Jeśli w czasie oglądania wideo (odtwarzacz VLC) dźwięk przestaje być pierwszy, po kilku sekundach obraz się zatrzymuje. Podczas gdy dźwięk się zatrzymał, nadal mam pewną kontrolę nad komputerem, ale kiedy obraz się zatrzymuje, nie mogę już nawet ruszyć myszy, więc uruchomiłem go ponownie po pewnym czasie. Przy okazji, tak się nie stało, kiedy zacząłem oglądać wideo, ale jakiś czas później (20 minut) i wtedy nie robiłem nic innego, mimo że przeglądarka i oowrite były cały czas otwarte na drugim ekranie. Zasadniczo coś po prostu decyduje się wydarzyć w pewnym momencie i zawiesza system.

Zgodnie z prośbą w komentarzach uruchomiłem dmesg zaraz po zawieszeniu. Nie zauważyłem niczego dziwnego, ale nie wiedziałem, czego szukać, więc oto: https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=pl_US&authkey=CPzF7bcC

Aby rozwiązać ten problem, stwierdziłem, że musisz ustawić następujące ustawienie na około 5% -6% całkowitej fizycznej pamięci RAM, podzielone przez liczbę rdzeni w komputerze:

sysctl -w vm.min_free_kbytes=65536

Pamiętaj, że jest to ustawienie na rdzeń, więc jeśli mam 2 GB pamięci RAM i dwa rdzenie, to obliczyłem 6% tylko 1 GB i dodałem trochę więcej, aby być bezpiecznym.

Zmusza to komputer do próby utrzymania tej ilości wolnej pamięci RAM, a przez to ogranicza możliwość buforowania plików na dysku. Oczywiście nadal próbuje je buforować i natychmiast je wymieniać, więc prawdopodobnie powinieneś również ograniczyć swoje zamiany:

sysctl -w vm.swappiness=5

(100 = zamień tak często, jak to możliwe, 0 = zamień tylko w razie konieczności)

Powoduje to, że linux nie decyduje już losowo o załadowaniu całego pliku filmowego o wielkości około 1 GB w pamięci RAM podczas oglądania go i zabijając przy tym maszynę.

Teraz jest wystarczająca ilość miejsca, aby uniknąć głodu pamięci, co zwykle było problemem (ponieważ nie ma już takich zawieszeń jak wcześniej).

Po całodniowym testowaniu - zawieszanie się minęło, czasem dochodzi do niewielkich spowolnień, ponieważ rzeczy są buforowane częściej, ale mogę z tym żyć, jeśli nie muszę restartować komputera co kilka godzin.

Lekcja jest taka - domyślne zarządzanie pamięcią jest tylko jednym z przypadków użycia i nie zawsze jest najlepsze, chociaż niektórzy próbują sugerować inaczej - ubuntu domowej rozrywki powinno być skonfigurowane inaczej niż serwer.

Prawdopodobnie chcesz, aby te ustawienia były trwałe, dodając je do swojego /etc/sysctl.conf:

vm.swappiness=5
vm.min_free_kbytes=65536

Stało się to dla mnie w nowej instalacji Ubuntu 14.04.

W moim przypadku nie miało to nic wspólnego z wymienionymi problemami sysctl.

Problem polegał na tym, że identyfikator UUID partycji wymiany był inny podczas instalacji niż po instalacji. Tak więc moja zamiana nigdy nie była włączona, a moja maszyna blokowała się po kilku godzinach użytkowania.

Rozwiązanie było sprawdzenie aktualnego UUID partycji SWAP z

sudo blkid

a następnie, sudo nano /etc/fstababy zastąpić wartość UUID niepoprawnej zamiany wartością zgłoszoną przez blkid.

Prosty restart, aby wpłynąć na zmiany i voila.

Wiem, że to pytanie jest stare, ale miałem ten problem w Ubuntu (Chrubuntu) 14.04 na Chromebooku Acer C720. Wypróbowałem rozwiązanie Krišjānis Nesenbergs i działało to trochę, ale czasami ulegało awarii.

W końcu znalazłem rozwiązanie, które działało, instalując zram zamiast korzystania z fizycznej wymiany na dysku SSD. Aby go zainstalować, postępowałem zgodnie z instrukcjami tutaj :

sudo apt-get install zram-config

Potem mogłem skonfigurować rozmiar zamiany zram poprzez modyfikację /etc/init/zram-config.confw linii 21.

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

Zamieniłem 2 na 1, aby rozmiar ZRAM był taki sam, jak ilość pamięci RAM. Od tego czasu nie zawieszałem się ani nie reagowałem na system.

Nic mi nie działało !!

Napisałem więc skrypt do monitorowania zużycia pamięci. Najpierw spróbuje wyczyścić pamięć podręczną RAM, jeśli zużycie pamięci zwiększy próg. Możesz skonfigurować ten próg w skrypcie. Jeśli zużycie pamięci nie spadnie nawet poniżej tego progu, rozpocznie proces zabijania jeden po drugim w malejącym porządku zużycia pamięci, aż zużycie pamięci spadnie poniżej progu. Domyślnie ustawiłem go na 96%. Możesz go skonfigurować, zmieniając wartość zmiennej RAM_USAGE_THRESHOLD w skrypcie.

Zgadzam się, że zabijanie procesów zużywających dużo pamięci nie jest idealnym rozwiązaniem, ale lepiej jest zabić JEDNĄ aplikację, niż stracić CAŁĄ pracę !! skrypt wyśle ​​Ci powiadomienie na pulpicie, jeśli użycie pamięci RAM podniesie próg. Powiadomi Cię również, jeśli zabije jakikolwiek proces.

#!/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)

Zapisz kod w pliku, powiedz save_hang.py. Uruchom skrypt jako:

sudo python save_hang.py

Uwaga: ten skrypt jest kompatybilny tylko z Python 3 i wymaga instalacji pakietu tkinter. możesz zainstalować jako:

sudo apt-get install python3-tk

Mam nadzieję że to pomoże...

Domyślam się, że ustawiłeś vm.swappinessbardzo niską wartość, co powoduje, że jądro zamienia się zbyt późno, pozostawiając zbyt mało pamięci RAM do pracy z systemem.

Możesz pokazać swoje obecne ustawienie swapiness, wykonując:

sysctl vm.swappiness

Domyślnie jest on ustawiony na 60. Wiki Ubuntu zaleca ustawienie go na 10, ale możesz ustawić wyższą wartość. Możesz to zmienić, uruchamiając:

sudo sysctl vm.swappiness=10

Spowoduje to zmianę tylko dla bieżącej sesji , aby była trwała, musisz dodać vm.swappiness = 10do /etc/sysctl.confpliku.

Jeśli twój dysk jest wolny, rozważ zakup nowego.

Od dłuższego czasu zmagam się z tym problemem, ale teraz wydaje się, że został rozwiązany na moim laptopie.

Jeśli żadna z pozostałych odpowiedzi nie działa dla ciebie (próbowałem większość z nich), graj z min_free_kbytes , aby mieć więcej miejsca w pamięci RAM, gdy komputer zacznie się zamieniać (tuż przed osiągnięciem tej minimalnej wartości na wolnej pamięci RAM).

Mam 16 GB pamięci RAM, ale wcześniej niż później pamięć zapełniła się, a następnie przestała odpowiadać przez 10 do 30 minut, aż niektóre rzeczy się podmieniły.

Przynajmniej dla mnie ustawienie wartości min_free_kbytes powyżej zalecanej powoduje, że proces zamiany jest znacznie szybszy.

W przypadku 16 GB pamięci RAM spróbuj tego:

vm.min_free_kbytes=500000

Aby ustawić tę wartość, zobacz inne odpowiedzi lub po prostu google :)

Ciągle uruchamiam jeden z moich laptopów z karty SD Ubuntu na żywo, z małą partycją pamięci ext4 i plikiem wymiany na dysku twardym. Gdy używana jest prawie cała pamięć RAM, a wartość swapiness jest zbyt niska (czasami wolę całkowicie wyłączyć dysk twardy, jeśli to możliwe, ponieważ jest głośny), wydajność Linuksa spada dla mnie z klifu, tak że po prostu dostaję się do TTY1 zabicie Firefoksa zajmuje 15 minut.

/proc/sys/vm/vfs_cache_pressureWydaje się, że podniesienie wartości domyślnej 100 do wartości 6000 pomaga temu zapobiec. Jednak dokumentacja jądra ostrzega przed tym, mówiąc:

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.

Nie jestem do końca pewien skutków ubocznych, dlatego ostrożnie to robię.