Сьогодні я (випадково) запустив якусь програму на своєму вікні Linux, яка швидко використала багато пам'яті. Моя система замерзла, стала не реагувати, і тому я не зміг вбити злочинця.
Як я можу запобігти цьому в майбутньому? Невже це не може тримати чуйне ядро чи щось працює?
Відповіді:
Б'юсь об заклад, що система насправді не «замерзла» (у сенсі, що ядро висіло), а навпаки, було дуже невідповідальним. Цілком ймовірно, що це було просто важко замінити, в результаті чого інтерактивна продуктивність та пропускна здатність системи впали, як камінь.
Ви можете вимкнути своп, але це просто змінює проблему від низької продуктивності до процесів, знищених OOM (і все задоволення, що викликає), а також зниження продуктивності через менш доступний кеш-диск диска.
Крім того, ви можете використовувати обмеження ресурсів на кожен процес (зазвичай його називають rlimitта / або ulimit), щоб вилучити можливість одного процесу, який займає смішний об'єм пам'яті та спричиняє обмін, але це просто штовхає вас на розважальну територію з процесами, які вмирають на незручні моменти, тому що вони хотіли трохи більше пам’яті, ніж система їх хотіла дати.
Якби ви знали, що збираєтесь зробити щось, що може спричинити масове використання пам'яті, ви, ймовірно, можете написати програму для обгортки, яка зробила, mlockall()а потім виконала вашу оболонку; це збереже його в пам'яті, і було б найближчим чином "зберегти чуйне ядро", яке ви, швидше за все, отримаєте (адже це не те, що процесор перенасичений, це проблема).
Особисто я підписався на метод управління ресурсами "не роби дурних речей". Якщо ви отримали корінь, ви можете завдати всілякі збитки системі, і тому робити все , про що не знаєте ймовірних результатів, - це ризикована справа.
ulimitабо навіть групувати в наші дні, якщо ти молодий хіп, виконує цю роботу досить добре. Якщо ви вносите зміни до запитів у виробництві, не підтверджуючи їх ефекти в некритичному середовищі, це ваша проблема, яка є першопричиною.
Як згадувалося вище в коментарі Tronic, можна викликати OOM-вбивцю (не вбивцю пам'яті) безпосередньо за допомогою комбінації клавіатур SysRq- F.
SysRqКлавіша зазвичай поєднується в межах PrtScклавіш на клавіатурах.
Убивця OOM вбиває деякий процес (-ів) і система знову стає чуйною. Прямий доступ до OOM-вбивці може бути не включений за замовчуванням, будь ласка, ознайомтеся з цим питанням, щоб дізнатися, як перевірити його стан та / або включити його.
PS: Це мені дуже допомогло. Я погоджуюся з думкою, що це найкорисніша порада щодо цієї проблеми, якщо вона викликана Chrome або будь-яким жадібним програмним забезпеченням для пам'яті. Але вам потрібно пам’ятати, що вбивця OOM може вбити якийсь справді важливий процес, використовуйте його обережно.
Це помилка, відома з 2007 року - див. Замороження системи при високому використанні пам'яті .
У цій ситуації Windows відображає діалогове вікно, що попереджає користувача закрити одну чи кілька програм.
Якщо ви хочете перекомпілювати ядро, ви можете спробувати виправити патч із EDITрозділу цього питання: /programming//q/52067753/10239615
Він не виселяє Active(file)сторінки під час високого тиску пам’яті і, таким чином, це дозволяє вбивці OOM запускати майже миттєво, тому що ядро більше не потрібно витрачати хвилини постійного перечитування з диска кожного виконуваного сторінки коду кожного процесу, що спричиняє застиглу операційну систему.
Це щось особливо важко запобігти. Це тому, що ядро починає мінятися. Одне рішення - вимкнути своп. Коли в системі не вистачить пам’яті, а не почати міняти, ядро вбиває деякі процеси; зазвичай це підбирає правильний процес для вбивства, але все одно краще вбити випадковий процес, ніж мати систему, що не відповідає.
Це може бути особливо хорошим рішенням для серверів, оскільки сервери часто мають достатню кількість оперативної пам’яті, і коли вони починають використовувати простір для обміну, це все одно щось не так. Однак на робочих столах зазвичай потрібен простір для обміну, тому я думаю, що для настільних ПК не існує хорошого рішення. Я часто вимикаю місця для заміни на серверах, особливо коли є підозра на витік пам'яті.