LINUX.ORG.RU

История изменений

Исправление wandrien, (текущая версия) :

Да даже если проблема, как её решать-то?

Прикладную проблему нужно решать в индивидуальном порядке, это понятно. Вопрос в другом. Если у тебя что-то пошло не так, система выела всю память и зависла на трешинге файловых страниц, то остаётся только жесткий ресет. С последующей проверкой целостности структур хранилища, попытке анализа ситуации по неполным логам и т.п.

А если у тебя по дефолту система работает так, что ssh всегда доступен даже при самой жесткой нагрузке на память со стороны приложения, то это уже совсем другая картина. Можно залогиниться и осмотреться на живую. Можно специально воспроизвести проблему в тестовом окружении и снять полные логи.

На серверах варварскими методами хакавлада (жохать всё oom-киллером) действовать нельзя.

Там немного не в том суть. Патч, предложенный гуглом еще лет много назад, препятствует трешингу файловых страниц, что даёт возможность исполнения кода без попадания в безвыходный цикл «подкачиваем то одну страницу кода, то вторую».

То есть эта настройка не замена уже имеющимся настройкам ограничений по потреблению памяти, а защитная функция от протекании страниц анонимной памяти выше значения, которое может переварить система.

Я давал тут ссылку на тест жесткого трешинга. Подкачка на медленный HDD 5400 rpm. 6 процессов tail /dev/zero в фоне. Никаких специальных настроек cgroups, всё по дефолту. Система позволяет логиниться в неё, запускать консольные приложения, снимать все показатели, смотреть логи и т.п. Вывод команды find / идёт полностью без задержек, то есть полностью функциональны как операции с файловыми данными, так и взаимодействие с пользователем.

Исправление wandrien, :

Да даже если проблема, как её решать-то?

Прикладную проблему нужно решать в индивидуальном порядке, это понятно. Вопрос в другом. Если у тебя что-то пошло не так, система выела всю память и зависла на трешинге файловых страниц, то остаётся только жесткий ресет. С последующей проверкой целостности структур хранилища, попытке анализа ситуации по неполным логам и т.п.

А если у тебя по дефолту система работает так, что ssh всегда доступен даже при самой жесткой нагрузке на память со стороны приложения, то это уже совсем другая картина. Можно залогиниться и осмотреться на живую. Можно специально воспроизвести проблему в тестовом окружении и снять полные логи.

На серверах варварскими методами хакавлада (жохать всё oom-киллером) действовать нельзя.

Там немного не в том суть. Патч, предложенный гуглом еще лет много назад, препятствует трешингу файловых страниц, что даёт возможность исполнения кода без попадания в безвыходный цикл «подкачиваем то одну страницу кода, то вторую».

То есть эта настройка не замена уже имеющимся настройкам ограничений по потреблению памяти, а защитная функция от протекании страниц анонимной памяти выше значения, которое может переварить система.

Я давал тут ссылку на тест жесткого трешинга. Подкачка на медленный HDD 5400 rpm. 6 процессов tail /dev/zero в фоне. Никаких специальных настроек cgroups, всё по дефолту. Система позволяет логиниться в неё, запускать консольные приложения, снимать все показатели, смотреть логи и т.п. Вывод команды find / идёт полностью без задержек, то есть полностью функциональны как операции с файловыми страницами, так и взаимодействие с пользователем.

Исходная версия wandrien, :

Да даже если проблема, как её решать-то?

Прикладную проблему нужно решать в индивидуальном порядке, это понятно. Вопрос в другом. Если у тебя что-то пошло не так, система выела всю память и зависла на трешинге файловых страниц, то остаётся только жесткий ресет. С последующей проверкой целостности структур хранилища, попытке анализа ситуации по неполным логам и т.п.

А если у тебя по дефолту система работает так, что ssh всегда доступен даже при самой жесткой нагрузке на память со стороны приложения, то это уже совсем другая картина. Можно залогиниться и осмотреться на живую. Можно специально воспроизвести проблему в тестовом окружении и снять полные логи.

На серверах варварскими методами хакавлада (жохать всё oom-киллером) действовать нельзя.

Там немного не в том суть. Патч, предложенный гуглом еще лет много назад, препятствует трешингу файловых страниц, что даёт возможность исполняния кода без попадания в цикл безвыходный «подкачиваем то одну страницу кода, то вторую».

То есть эта настройка не замена уже имеющимся настройкам ограничений по потреблению памяти, а защитная функция от протекании страниц анонимной памяти выше значения, которое может переварить система.

Я давал тут ссылку на тест жесткого трешинга. Подкачка на медленный HDD 5400 rpm. 6 процессов tail /dev/zero в фоне. Никаких специальных настроек cgroups, всё по дефолту. Система позволяет логиниться в неё, запускать консольные приложения, снимать все показатели, смотреть логи и т.п. Вывод команды find / идёт полностью без задержек, то есть полностью функциональны как операции с файловыми страницами, так и взаимодействие с пользователем.