Система висить, коли у неї не вистачає пам'яті


34

У мене eeePC 900a: він має 8 Гб спалаху як диск і лише 1 Гб оперативної пам’яті. Встановлений на ньому дистрибутив Linux - це ArchLinux.

Коли в системі не вистачає пам'яті, вона стає вкрай невідповідною: потрібно кілька секунд / хвилин, щоб виконати такі дії, як перехід на TTY1 або навіть переміщення покажчика миші. Іноді схоже на те, що система просто замерзає: три наших тому назад я її відпустив і взагалі нічого не змінилося.

Я вважаю за краще уникати створення swap-розділу / файлу на цьому eeePC, оскільки диск вже такий малий, а також тому, що багато записів на свопі просторі значно скоротить життя флеш-карти. Крім того, я думаю, що файл / розділ підкачки просто перемістить проблему, а не обов'язково виправить її.

Хіба ядро ​​не повинно вбивати деякі випадкові програми, коли у нього не вистачає пам'яті? Чому це не вдається (або займає віки) при цьому?

Кілька місяців / років тому я вже намагався розібратися далі в цьому, але не зміг знайти нічого, що насправді спрацювало б ...


1
Яку DE / WM ви використовуєте для налаштування, які послуги / демон використовуєте? Використовуючи повне навколишнє середовище робочого столу та переглядаючи Chromium або Firefox, наприклад, з'їдає вашу оперативну пам’ять для обіду. 1 Гб оперативної пам’яті повинно бути достатньо для запуску Arch Linux, але важливо, що ви ставите над цим.

1
Я використовую LXDE. Chromium - це програма, яка зазвичай займає більшу частину оперативної пам’яті. У всякому разі, справа не в цьому. Я не повинен дбати про те, скільки пам'яті використовує моя система, це моя система, яка не повинна вмирати через це. Якщо в моїй системі не вистачає пам’яті, вона може знищити будь-яку програму, яку вона бажає, я просто хочу, щоб вона не замерзла !
перо

6
Я маю в виду, я серйозно думав про запуск сценарію , як це (в псевдокоді): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Це, безумовно, виправить мою проблему. Але зачекайте, чи не повинно це зробити ядро ​​(і куди кращим чином, ніж мій сценарій)? Чому він не робить свою роботу?
перо

2
@Marcin, це лише перемістить проблему, не вирішить її. Навіть якби у мене було 4 Гб пам’яті (завдяки деякому обміну), у моєї системи могло б вичерпатися пам’яті (таким чином висить). Чого я хочу уникати, це завісання моєї системи, коли вона залишається поза оперативної пам'яті. Якщо моє ядро ​​просто раптово знищить хром, як тільки моя оперативна пам’ять закінчиться, я був би задоволений навіть 1GB, який я отримав зараз.
перо

4
@Lee "Чарівний sysrq" - це ключове комбо, яке переходить безпосередньо до ядра. Це часто спрацьовує, навіть якщо клавіатура та миша не відповідають. Дивіться en.wikipedia.org/wiki/Magic_SysRq_key
Раман

Відповіді:


14

Можливий виклик OOM-вбивці (не вбивця пам'яті) безпосередньо за допомогою клавіатури:

SysRq-F

Клавіша SysRq зазвичай комбінується в клавіші PrtSc на клавіатурах.

Убивця OOM вбиває деякий процес (-ів) і система знову стає чуйною.

Thx Raman за порадою щодо цієї функції в коментарях вище.

PS: Це мені дуже допомогло. Я погоджуюся з думкою, що це найкорисніша порада щодо цієї проблеми, якщо вона спричинена Chrome або будь-яким жадібним програмним забезпеченням. Але вам потрібно мати на увазі, що вбивця OOM може вбити якийсь справді важливий процес, використовуйте його обережно.


2
У мене є ключ PrtScn|SysRq. Але натискання SysRq - Fотримує лише скріншот
Лі

2
Оскільки ви в основному сприйняли мій коментар вище і зробили його відповіддю, невелике приписування було б добре. Я все-таки звернувся до тебе. :-)
Раман

3
@Lee Ви повинні це ввімкнути. У деяких дистрибутивах за замовчуванням не ввімкнено магічний sysrq. Це має допомогти: google.ca/search?q=sysrq+enable
Раман

2
@Raman Я ставлю на облік 99%, хто вважає, що це не може "включити" за замовчуванням, оскільки їхня машина вже заморожена ... чому вона не включена за замовчуванням?
themihai

3
@themihai, оскільки багато людей вважають це загрозою безпеки - він надає вам прямий доступ до ядра через фізичний доступ до пристрою введення, незалежно від стану програми, наприклад блокування екранів тощо.
Раман

12

Природний стан речей полягає в тому, що дані програми знаходяться в оперативній пам'яті, а файли - на диску.
Ідеальний стан речей, з точки зору продуктивності, полягає в тому, що дані, що часто використовуються, є в оперативній пам'яті, а дані, які не потрібні на даний момент, знаходяться на диску.
У звичайній системі ядро ​​робить дві речі, щоб спробувати досягти цього ідеалу:

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

У типовій системі значна частина оперативної пам'яті присвячена кешу і буферам (50% - типова цифра). Оскільки оперативна пам'ять є обмеженим ресурсом, це може зажадати переміщення деяких даних програми для заміни (своп необхідний лише за наявності кращого способу використання оперативної пам'яті).

У системі без підкачки є момент, коли дані програми використовують майже всю оперативну пам’ять, і тому кеш-пам'ять ледь не залишається. Тоді система, ймовірно, буде повільною. Ядро не почне вбивати програми, поки це дійсно не доведеться. Поки програми лише заповнюють 99% наявної пам'яті, система продовжує працювати, але дуже повільно, оскільки файлові дані повинні постійно завантажуватися та перезавантажуватися з диска. При запуску тих самих додатків система буде швидшою із свопом у цей момент.

Докладніше про це питання дивіться у цій lkml дискусії та у цій публікації в блозі .

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


1
Дякуючи за пояснення та посилання, вони допомогли усунути деякі сумніви щодо заміни. Після відповіді @Marcin на моє запитання я встановив 256 Мб стисненого віртуального свопу (compcache) у своїй оперативній пам’яті. Однак це не відповідає повністю на моє запитання: я розумію, що моя система буде повільною, коли вся ОЗУ буде використовуватися лише додатком, і нічого не буде кешовано; Досі я не можу зрозуміти, чому ця система висить хвилин / години (може, назавжди?), Коли я повністю поза оперативною пам’яттю. Я думаю, що моє ядро ​​не працює над тим, щоб знищувати програми, коли немає пам’яті, якщо 3 години недостатньо для переходу на TTY1.
перо

У мене обмін вимкнено з 32 Гб фізичної пам'яті, і коли поганий програмний продукт тікає з розподілом пам’яті (привіт ld, ви шматок сміття), він все ще зависає майже хвилину, прокинувшись достатньо, щоб дозволити мені на секунду перенести неймовірно мляву мишку або дві кожні кілька секунд. Обробка OOM Linux в повному обсязі. Якщо мені пощастить, вбивця OOM вбиває правильний процес, не повністю викручуючи середовище робочого столу. І я великий шанувальник Linux. Це набагато гірше, якщо підключення підключення. Пейджинг Linux - це жарт.
doug65536

6

Це відома помилка з 2007 року - див. Замороження системи при високому використанні пам'яті .

У цій ситуації Windows відображає діалогове вікно, що попереджає користувача закрити одну чи кілька програм.


2
Здається, в Ubuntu "непризначений". Можливо, DE повинен попередити користувача або навіть заморозити додаток, що займає велику пам’ять?
nkkollaw

1
@nbrogi - що завгодно, але мовчки замерзнути. Але удача переконала Ubuntu розробників зробити це.
Дан Даскалеску

6

Нещодавно я знайшов рішення своєї проблеми.

Оскільки вбивця Linux OOM не в змозі виконати свою роботу належним чином, я почав використовувати користувацький простір OOM Killer: earlyoom . Він написаний на мові С, досить настроюється, і він працює як шарм для мене.

Я також чув про деякі альтернативи, наприклад , OOMD Facebook , розроблений для роботи на їх серверах, але я не пробував цього

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.