Замороження комп'ютера майже на повній оперативній пам’яті, можливо, проблема з кешем диска

Думаю, проблема дещо схожа на цю тему.

Неважливо, у мене включений або відключений своп, коли реальна використана кількість оперативної пам’яті починає наближатися до максимуму і майже не залишається місця для кеш-диска, система стає абсолютно невідповідною.

Диск дико розкручується, а іноді через тривалі очікування 10-30 хвилин він розморозиться, а іноді ні (або у мене не вистачає терпіння). Іноді, якщо я швидко дію, мені вдається повільно відкрити консоль і вбити деякі програми, які їдять баран, як-то браузер, і система розморожується майже миттєво.

Через цю проблему я майже ніколи не бачу нічого в свопі, лише іноді там є декілька МБ, а потім незабаром після появи цієї проблеми. Моя не так освічена здогадка, що він якось підключений до кеш-диска, який є занадто жадібним, або керування пам'яттю занадто поблажливим, тому коли потрібна пам'ять, вона не звільняється досить швидко і голодує систему.

Проблему можна вирішити дуже швидко, якщо робота з файлами відставання (500 Мб +), які завантажуються в кеш диска, а система після цього не зможе їх розвантажити досить швидко.

Будь-яка допомога чи ідеї будуть дуже вдячні.

Поки що мені доводиться жити в постійному страху, коли щось, що працює на комп’ютері, може просто замерзнути, і мені зазвичай доводиться його перезавантажувати, якщо він дійсно закінчується таран, я б набагато більше хотів би це просто вбити деякі програми з простору користувачів, наприклад, браузер ( бажано, якби я міг якось позначити, кого вбити першим)

Хоча таємниця, чому мій swap не врятує мене в цій ситуації.

ОНОВЛЕННЯ: Він деякий час не висів, але зараз я знову отримав кілька випадків. Зараз я постійно зберігаю монітор на моєму екрані, і коли вийшло, він все ще показав ~ 30% безкоштовно (можливо, використовується кеш диска). Додаткові симптоми: Якщо під час перегляду відео (плеєр VLC) звук спочатку припиняється, через кілька секунд зображення припиняється. Хоча звук припинився, я все ще маю деякий контроль над ПК, але коли зображення припиняється, я вже не можу рухати мишею, тому перезапустив його після деякого очікування. До речі, цього не сталося, коли я почав дивитись відео, але деякий час через (20 хв), і я активно не робив нічого іншого в той час, хоча браузер і власні програми були відкриті на другому екрані весь час. В основному щось просто вирішує статися в один момент і висить систему.

Відповідно до запиту в коментарях, я запустив dmesg відразу після зависання. Я нічого не дивився на дивне, але не знав, на що дивитися, тож ось це: https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=uk_a&keykeyCCzz7bccc

Щоб вирішити цю проблему, я виявив, що вам потрібно встановити наступне налаштування приблизно на 5% -6% від загальної фізичної оперативної пам’яті, поділену на кількість ядер у комп’ютері:

sysctl -w vm.min_free_kbytes=65536

Майте на увазі, що це налаштування на одне ядро, тому якщо у мене є 2 Гб оперативної пам’яті та два ядра, то я обчислив 6% лише 1 ГБ і додав трохи зайвих, щоб бути безпечним.

Це змушує комп'ютер намагатися зберегти цю кількість оперативної пам’яті безкоштовно, і тим самим обмежує можливість кешування файлів на диску. Звичайно, він все ще намагається кешувати їх та негайно заміняти їх, тому, ймовірно, слід також обмежити свою заміну:

sysctl -w vm.swappiness=5

(100 = міняйте місцями якомога частіше, 0 = міняйте місцями лише на повній необхідності)

Результат полягає в тому, що Linux більше не випадково вирішує завантажувати цілий файл фільму розміром приблизно 1 Гб в операційному режимі під час його перегляду, і вбиває машину при цьому.

Зараз є достатньо зарезервованого місця, щоб уникнути голодування пам’яті, що, як правило, було проблемою (бачимо, як більше немає заморожувань, як раніше).

Після тестування протягом дня - блокування немає, іноді виникають незначні уповільнення, тому що матеріал частіше кешується, але я можу з цим жити, якщо мені не доведеться перезавантажувати комп’ютер кожні кілька годин.

Тут є урок - управління пам'яттю за замовчуванням - лише один із випадків використання та не завжди найкращий, хоча деякі люди намагаються запропонувати інакше - домашні розваги ubuntu повинні бути налаштовані інакше, ніж сервер.

Ви, ймовірно, хочете зробити ці налаштування постійними, додавши їх до своїх /etc/sysctl.confподібних:

vm.swappiness=5
vm.min_free_kbytes=65536

Це сталося для мене в новій інсталяції Ubuntu 14.04.

У моєму випадку це не мало нічого спільного із згаданими проблемами sysctl.

Натомість проблема полягала в тому, що UUID розділу swap був іншим під час встановлення, ніж після встановлення. Тож мій обмін ніколи не вмикався, і моя машина заблокувалась через кілька годин використання.

Рішення було перевірити поточний UUID розділу підкачки з

sudo blkid

а потім sudo nano /etc/fstabзамінити неправильне значення UUID swap на значення, повідомлене blkid.

Просте перезавантаження, яке вплине на зміни, і вуаля.

Я знаю, що це питання давнє, але у мене виникла проблема в Ubuntu (Chrubuntu) 14.04 на Chromebook Acer C720. Я спробував рішення Krišjānis Nesenbergs, і воно дещо спрацювало, але все-таки іноді виходило з ладу.

Нарешті я знайшов рішення, яке працювало, встановивши zram замість використання фізичного swap на SSD. Щоб його встановити, я просто дотримувався тут інструкцій , таких як:

sudo apt-get install zram-config

Згодом я зміг настроїти розмір zram swap, змінивши /etc/init/zram-config.confна лінії 21.

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

Я замінив 2 на 1, щоб розмір zram був таким же розміром, як і у мене кількість барана. З моменту цього у мене більше не було заморожування або невідповідності системи.

Нічого не працювало для мене !!

Тому я написав сценарій для моніторингу використання пам'яті. Спочатку він спробує очистити кеш оперативної пам'яті, якщо споживання пам'яті збільшує поріг. Ви можете налаштувати цей поріг у сценарії. Якщо споживання пам’яті навіть тоді не опуститься нижче порогового значення, воно почне вбивати процеси на порядок в порядку зменшення споживання пам’яті, поки споживання пам’яті не буде нижчим за поріг. Я встановив його за замовчуванням 96%. Ви можете налаштувати його, змінивши значення змінної RAM_USAGE_THRESHOLD у сценарії.

Я згоден, що процеси вбивства, які споживають високу пам'ять, не є ідеальним рішенням, але краще вбити ОДНУ додаток, а не втрачати ВСІ роботи! сценарій надішле вам сповіщення на робочому столі, якщо використання оперативної пам’яті підвищить поріг. Він також повідомить вас, якщо він вбиває будь-який процес.

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

Сподіваюся, це допомагає ...

Я здогадуюсь, що ви встановили vm.swappinessдуже низьке значення, через що ядро ​​занадто пізно змінюється, залишаючи занадто низьку оперативну пам’ять для роботи системи.

Ви можете показати свій поточний параметр простоти, виконавши:

sysctl vm.swappiness

За замовчуванням це встановлено на 60. Ubuntu Wiki рекомендує встановити його на 10, але сміливо встановлюйте його на більш високе значення. Ви можете змінити його, запустивши:

sudo sysctl vm.swappiness=10

Це змінить його лише для поточного сеансу , щоб зробити його стійким, потрібно додати vm.swappiness = 10його до /etc/sysctl.confфайлу.

Якщо ваш диск повільний, подумайте про придбання нового.

Я давно боровся з цим питанням, але зараз, здається, вирішено на своєму ноутбуці.

Якщо жоден з інших відповідей не працює для вас (я спробував більшість з них), пограйте з min_free_kbytes , щоб мати більше місця в оперативній пам’яті, коли ваш комп'ютер почне мінятися (безпосередньо перед тим, як потрапити на це мінімальне значення у вашій вільній оперативній пам’яті).

У мене є 16 Гб оперативної пам’яті, але раніше, ніж пізніше, пам'ять заповнилася, а потім перестала реагувати на 10–30 хвилин, поки деякі речі не поміняються.

Принаймні для мене, встановлення значення min_free_kbytes вище рекомендованого робить процес заміни значно швидшим.

Для 16 Гб оперативної пам’яті спробуйте це:

vm.min_free_kbytes=500000

Щоб встановити це значення, дивіться інші відповіді або просто google it :)

Я постійно запускаю один із своїх ноутбуків з живої карти Ubuntu SD постійно, з невеликим розділом зберігання ext4 та файлом swap на жорсткому диску. Коли використовується майже вся оперативна пам’ять і значення затишності є занадто низьким (іноді я віддаю перевагу повністю відключити жорсткий диск, якщо це можливо, тому що це шумно), продуктивність Linux, як правило, падає з обриву для мене, таким чином, щоб просто дістатися до TTY1 для вбивства Firefox займає 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.

Я не зовсім впевнений у побічних ефектах цього, тому ставлюся обережно.