| 1.1, Аноним (1), 21:53, 17/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Я что-то заметил, 5.4 как-то иначе реагирует на кончившуюся память, не как 4.19. Иксы больше не зависают, курсор продолжает двигаться (с лагами), но запустить или убить ничего нельзя (хоткей с xkill бы работал, эх). Но в то же время у меня на 5.4 зависла консоль на tty, чего с 4.19 никогда не случалось. В логах после хардресета посмотрел, ядро реагировало на magic key, но этого с хоста было не увидеть никак. Вывод: раньше было лучше -- ядро опять сломали.
| | |
| |
| |
| 3.6, Аноним (1), 22:25, 17/05/2020 [^] [^^] [^^^] [ответить]
| +4 +/– | |
Очень часто случается такое, что ядро реагирует только на sysrq+b, тут уж как повезёт. Это очень болезненно, хотя бы потому, что все диски смонтированы с data=writeback. В норме то реагирует на sysrq+f и всё сразу в порядке (не для убитого процесса). В крайнем случае sysrq+e (отправить sigterm всем процессам) должен спасти. Но, если никакие команды кроме b не срабатывают, всё очень плохо. Тут они срабатывали, да видеодрайвер, похоже, завис.
Юзерспейсные обработчики ни от чего не спасут, памяти нужно много и внезапно: порядка 80% на линковку, например.
| | |
| |
| 4.8, tr (?), 22:32, 17/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Юзерспейсные обработчики ни от чего не спасут
Они спасают от нехватки памяти, что подтверждено многочисленными отзывами. Они как раз и предотвращают состояние, когда все запущено и реагировать трудно, ибо реагируют тогда, когда память еще не полностью исчерпана.
| | |
| |
| 5.10, Аноним (1), 22:36, 17/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так в том и дело, что память будет исчерпана целиком и полностью совершенно внезапно. Когда тут реагировать? Отдельное приключание, если у нас ещё есть своп, который можно невозбранно исчерпать не менее внеазпно.
| | |
| |
| 6.12, tr (?), 22:45, 17/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>целиком и полностью совершенно внезапно
Ничего подобного, память исчерпывается с ограниченной скоростью. Даже без свопа при запуске многопоточного stress скорость исчерпания ограничена десятком гигабайт в секунду.
Юзерспейсные обработчики проверяют состояние памяти до десяти раз в секунду. Этого вполне достаточно для реакции, даже если память пожирается очень быстро.
Например:
https://youtu.be/UCwZS5uNLu0 – running multiple fast memory hogs at the same time without swap space.
Тем более при наличии свопа нет проблемы вовремя среагировать.
| | |
| |
| 7.14, Аноним (1), 22:58, 17/05/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Слишком абстрактно. Я когда-то тестировал память в четырёхканальном режиме, там получалось что-то в районе 60гб/с. Естественно, память очень медленная даже в идеальных условиях, но на вероятность исчерпать последние проценты и повесить систему это не влияет.
CONFIG_HZ_PERIODIC=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
С такими параметрами ядро может реагировать достаточно долго даже на magic-key что уж там говорить про какие-то пользовательские приложения. С nohz у меня лаги были, а так там вроде можно и больше 1000 раз (с nohz).
| | |
| |
| 8.18, tr (?), 23:21, 17/05/2020 [^] [^^] [^^^] [ответить] | +/– | Наоброт, предоставлена конкретика обработчик нехватки памяти nohang обрабатывае... текст свёрнут, показать | | |
| |
| 9.20, Аноним (1), 23:34, 17/05/2020 [^] [^^] [^^^] [ответить] | +/– | Синтетика 8230 Видеокарта не используется, опять же, а ведь именно видеокарта ... текст свёрнут, показать | | |
| |
| 10.23, хз2 (?), 04:11, 18/05/2020 [^] [^^] [^^^] [ответить] | +/– | Синтетика как раз позволяет моделировать нужное поведение, такое как быстрое пог... текст свёрнут, показать | | |
| |
| |
| 12.26, хзъ (?), 06:40, 18/05/2020 [^] [^^] [^^^] [ответить] | +/– | Всё так Ни ядро, ни юзерспейсные киллеры не разруливают переполение tmpfs Впро... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 4.9, Аноним (1), 22:34, 17/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пока сделал вывод, что не нужно пытаться перейти на tty, если иксы "залагали" подобным образом от нехватки памяти. Если sysrq+f не помогает, лучше жать sysrq+e и молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске. Потому что после перехода на tty всё точно окончательно зависнет (баг в kms?). Почему всё зависло в тот раз и без иксов (они даже не были запущены), я не знаю, видимо опять этот баг в kms.
| | |
| |
| 5.11, tr (?), 22:40, 17/05/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске
Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса, по возможности избегая убийства всей сессии с потерей несохраненных данных.
| | |
| |
| 6.13, Аноним (1), 22:48, 17/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все
> процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через
> SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса,
> по возможности избегая убийства всей сессии с потерей несохраненных данных.
А кто им даст такую возможность? Даже если приложение написано в лучшем стиле реалтайм систем... И никогда не выделяет память динамически (и ничего не запускает -- с чем запустили, с тем и живём), если оно висит в фоне, ему времени может и не перепасть. Тут даже magic key реагирует с задержкой в пару минут. А уж если led-индикаторы на клавиатуре не реагируют, это надёжный признак того, что мы приплыли. На удивление, sysrq+b всё равно работает. Но это ничем не отличается от хардресета.
| | |
| |
| 7.15, tr (?), 23:01, 17/05/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>А кто им даст такую возможность?
1. Автор демона.
2. Админ, который установит и запустит демона.
>приложение написано в лучшем стиле реалтайм систем
Реалтайм не обязателен. Достаточного одного mlockall() - это уже дает фору демону, особенно при своппинге.
>И никогда не выделяет память динамически
Для парсинга значений oom_score процессов нужно совсем немнго памяти, и делается это за десятки миллисекунд.
>ему времени может и не перепасть
Такое возможно, если специально выставить неадекватные пороги - то есть указать демону реагировать лишь когда память совсем исчерпана, близка к нулю. На самом деле время практически всегда всегда перепадает, и проблем с реакцией нет, что и продемонстрировано здесь: https://youtu.be/UCwZS5uNLu0
>даже magic key реагирует с задержкой в пару минут
Правильно, потому что ядерный киллер сломан. Триггеринг киллера зачастую приводит лишь к purging GPU memory вместо убийства жиробаса. В то время как юзерспейсный киллер за десятки секунд находит жертву и отправляет сигнал.
| | |
| |
| 8.16, tr (?), 23:05, 17/05/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Пардон, за десятки миллисекунд Это у ядерного счет идет на секунды, минуты и ча... текст свёрнут, показать | | |
| 8.19, Аноним (1), 23:30, 17/05/2020 [^] [^^] [^^^] [ответить] | +/– | Очень даже обязателен Реалтайм процессы не выделяют память и ни от чего не зави... текст свёрнут, показать | | |
| |
| 9.22, хз2 (?), 03:55, 18/05/2020 [^] [^^] [^^^] [ответить] | +/– | В современном гном3 и циннамоне каждое приложение запускается в отдельной группе... текст свёрнут, показать | | |
| |
| |
| 11.27, хзъ (?), 07:04, 18/05/2020 [^] [^^] [^^^] [ответить] | –2 +/– | Тогда ССЗБ Большинство дистров поставляются с ним Зачем вы выбрали дистрибутив... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| |
| |
| |
| 5.30, Аноним (17), 10:05, 18/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо, это заставило меня почитать про kernel signals, я даже не знал что такое есть.
| | |
|
|
|
| 2.5, ilyafedin (ok), 22:23, 17/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Ctrl + Alt + SysRq + F - вызовет ядерный OOM-киллер через sysrq, от этого ядру не отвертеться. Разумеется, если включен kernel.sysrq.
| | |
| |
| 3.7, Аноним (1), 22:27, 17/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6 пояснил, далеко не всегда работает.
| | |
| |
| 4.39, Аноним (-), 13:15, 23/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6
> пояснил, далеко не всегда работает.
Щасливый пользователь нвидий? Если ядро на sysrq не реагирует - ему совсем поплохело. Или соотв. реакция запрещена, это настраивается.
| | |
| |
| 5.41, Аноним (1), 13:36, 23/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
У счастливого пользователя амд ядро падает в панику при открытии хромиума. Упс, ещё хуже.
| | |
|
|
|
| 2.33, RNZ (ok), 20:27, 18/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
 vm.overcommit_ratio = 200
vm.overcommit_memory = 2
swapoff
И все дела.
| | |
| |
| |
| 4.37, RNZ (ok), 12:40, 21/05/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> и хром не запустится
Не правда.
Запустится и будет работать, когда попытается аллоцировать больше чем есть - просто сразу сдохнет.
Проверь сам.
| | |
| |
| |
| 6.42, RNZ (ok), 16:53, 23/05/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> А если памяти мало - можно своп в zram сделать
Так и делаю где требуется:
# zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4 75,6G 15,6G 3,9G 11,2G 50 [SWAP]
# free -g
total used free shared buff/cache available
Mem: 251 76 130 24 45 149
Swap: 75 16 58
| | |
|
|
|
|
|
| 1.28, СеменСеменыч777 (?), 09:02, 18/05/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
апогей современной софт-индустрии.
вместо того, чтобы разобраться с текущим приложением (например ограничить его аппетит. или прекратить его использование. или свопнуть), давайте сперва отстрелим самое жирное через ядро, потом сделаем то же от юзера, потом заведем спец.подсистему в ядре !
| | |
| |
| 2.29, Секция (?), 09:48, 18/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Что сказать-то хотел, умник? оверкомммит разрешен для более полной утилизации памяти. однако киллер оказался слабоват, проблема вскрыта и решается средствами юзерспейса.
>апогей современной софт-индустрии.
Не апогей, а обычное средство мониторинга доступности ресурсов.
| | |
| 2.32, Annoynymous (ok), 19:08, 18/05/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Да, до изобретения виртуальной памяти такой проблемы действительно не было.
Но тогда, в 1977-м, были другие.
| | |
| |
| 3.34, пох. (?), 22:27, 18/05/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
эн, нет - в 78 виртуальная память была swap-backed, смысл ее виртуальности был в том чтобы дать программам память в рамках разделения ресурсов - "если ты все равно не занимаешь процессор, полежи на диске...зачеркнуто, для этого использовали барабан, заодно и память пригодится другим". В те времена такого катастрофического разрыва по скорости между оперативной памятью и внешним носителем не было.
Чудеса с виртуальной памятью в /dev/zero, которой не соответствует никакое место ни на диске ни в памяти - это изобретение 90х, когда памяти стало уже много, а диски изрядно от нее отстали.
| | |
|
|
|
