o👹
с earlyoom просто закладка говорила oops
Size: a a a
2020 January 24
A
@olegon это ты про первые жертвы OOM киллеров? :)
A
А, уже вижу.
o👹
A
Press F. @aavMGTkFVLCZ16AeM
o👹
и тут такое началось :(
o👹
Press F. @aavMGTkFVLCZ16AeM
а у тебя просто дефолтный overcommit и без киллеров?
A
Я не ставлю на хост его.
o👹
Я не ставлю на хост его.
и оверкоммит штатный?
FL
Как обстоят дела со snap в fedora? Про Flatpak в курсе, но там нету.
Так же, как в любой не-убунте - с горем пополам.
A
и оверкоммит штатный?
+
o👹
понял, спасибо, попробую, наверное
2020 January 25
L
@DontDistrub чекниш эту штуку, я не могу собрать модуль и проверить, заработает ли у нас.
https://github.com/electrified/asus-wmi-sensors
https://github.com/electrified/asus-wmi-sensors
AK
Господа, есть челик @mvvcp344
Является спамером.
Является спамером.
A
Господа, есть челик @mvvcp344
Является спамером.
Является спамером.
Действительно. Бот и здесь удалил от него сообщение. Спс. 👮♀️
АА
что-то поставил я overcommit=2 и ratio=95 жене, у нее все практически крешиться начало :(
Отвечу недавней пастой из соседнего чата:
1. Большинство приложений не обрабатывают ошибки выделения, это может приводить к неожиданному поведению.
2. Трудно найти оптимальное значение overcommit ratio, хотя это может быть не проблема не сервере с предсказуемой нагрузкой. - Если выставить большой ratio, то получим тот же эффект, что и при наличии дефолтного оверкоммита, и будет приходить киллер. При низком overcommit ratio просто получим неполную утилизацию физической памяти. - Процессы будуть падать при полупустом свопе или при полупустой памяти. - Если нужно огараничить память, то лучше использовать контрольные группы и MemoryMax и MemorySwapMax - эти параметры ограничивают физическую память, а не виртуальную, в отличие от случая с запретом оверкоммита. Еще альтератива - юзерспейсный демон earlyoom - он сначала отправляет SIGTERM, завершая процессы по возможности более корректно
1. Я знаю один способ отключения киллера - panic on oom. Разве есть другие? 2. оом киллер надо не отключать, а вызывать по возможности раньше. Не вызванный киллер - умершая система. Киллер - это лекарство от смерти. "если уж хочется жить без oom" - то я предпочитаю earlyoom - процессы завершаются по SIGTERM, до дедлоков с зависаниями не доходит дело.
Ограничение оверкоммита не всегда означает отключение киллера - многое еще зависит от overcommit ratio
Еще момент: киллер убивает процесс с наибольшим oom_score - обычно самый жирный. С ограничением оверкоммита упадет не обязатено самый жирный - могут падать и мелкие процессы, если жирный процесс протекает, но при этом обрабатывает ошибки выделения
1. Большинство приложений не обрабатывают ошибки выделения, это может приводить к неожиданному поведению.
2. Трудно найти оптимальное значение overcommit ratio, хотя это может быть не проблема не сервере с предсказуемой нагрузкой. - Если выставить большой ratio, то получим тот же эффект, что и при наличии дефолтного оверкоммита, и будет приходить киллер. При низком overcommit ratio просто получим неполную утилизацию физической памяти. - Процессы будуть падать при полупустом свопе или при полупустой памяти. - Если нужно огараничить память, то лучше использовать контрольные группы и MemoryMax и MemorySwapMax - эти параметры ограничивают физическую память, а не виртуальную, в отличие от случая с запретом оверкоммита. Еще альтератива - юзерспейсный демон earlyoom - он сначала отправляет SIGTERM, завершая процессы по возможности более корректно
1. Я знаю один способ отключения киллера - panic on oom. Разве есть другие? 2. оом киллер надо не отключать, а вызывать по возможности раньше. Не вызванный киллер - умершая система. Киллер - это лекарство от смерти. "если уж хочется жить без oom" - то я предпочитаю earlyoom - процессы завершаются по SIGTERM, до дедлоков с зависаниями не доходит дело.
Ограничение оверкоммита не всегда означает отключение киллера - многое еще зависит от overcommit ratio
Еще момент: киллер убивает процесс с наибольшим oom_score - обычно самый жирный. С ограничением оверкоммита упадет не обязатено самый жирный - могут падать и мелкие процессы, если жирный процесс протекает, но при этом обрабатывает ошибки выделения
o👹
спасибо, познавательно, хотя меня к решению на сервере пока не привело
o👹
задача была в том, чтобы исключить зависания при переполнении памяти, а это даже маленький своп не решает
o👹
Отвечу недавней пастой из соседнего чата:
1. Большинство приложений не обрабатывают ошибки выделения, это может приводить к неожиданному поведению.
2. Трудно найти оптимальное значение overcommit ratio, хотя это может быть не проблема не сервере с предсказуемой нагрузкой. - Если выставить большой ratio, то получим тот же эффект, что и при наличии дефолтного оверкоммита, и будет приходить киллер. При низком overcommit ratio просто получим неполную утилизацию физической памяти. - Процессы будуть падать при полупустом свопе или при полупустой памяти. - Если нужно огараничить память, то лучше использовать контрольные группы и MemoryMax и MemorySwapMax - эти параметры ограничивают физическую память, а не виртуальную, в отличие от случая с запретом оверкоммита. Еще альтератива - юзерспейсный демон earlyoom - он сначала отправляет SIGTERM, завершая процессы по возможности более корректно
1. Я знаю один способ отключения киллера - panic on oom. Разве есть другие? 2. оом киллер надо не отключать, а вызывать по возможности раньше. Не вызванный киллер - умершая система. Киллер - это лекарство от смерти. "если уж хочется жить без oom" - то я предпочитаю earlyoom - процессы завершаются по SIGTERM, до дедлоков с зависаниями не доходит дело.
Ограничение оверкоммита не всегда означает отключение киллера - многое еще зависит от overcommit ratio
Еще момент: киллер убивает процесс с наибольшим oom_score - обычно самый жирный. С ограничением оверкоммита упадет не обязатено самый жирный - могут падать и мелкие процессы, если жирный процесс протекает, но при этом обрабатывает ошибки выделения
1. Большинство приложений не обрабатывают ошибки выделения, это может приводить к неожиданному поведению.
2. Трудно найти оптимальное значение overcommit ratio, хотя это может быть не проблема не сервере с предсказуемой нагрузкой. - Если выставить большой ratio, то получим тот же эффект, что и при наличии дефолтного оверкоммита, и будет приходить киллер. При низком overcommit ratio просто получим неполную утилизацию физической памяти. - Процессы будуть падать при полупустом свопе или при полупустой памяти. - Если нужно огараничить память, то лучше использовать контрольные группы и MemoryMax и MemorySwapMax - эти параметры ограничивают физическую память, а не виртуальную, в отличие от случая с запретом оверкоммита. Еще альтератива - юзерспейсный демон earlyoom - он сначала отправляет SIGTERM, завершая процессы по возможности более корректно
1. Я знаю один способ отключения киллера - panic on oom. Разве есть другие? 2. оом киллер надо не отключать, а вызывать по возможности раньше. Не вызванный киллер - умершая система. Киллер - это лекарство от смерти. "если уж хочется жить без oom" - то я предпочитаю earlyoom - процессы завершаются по SIGTERM, до дедлоков с зависаниями не доходит дело.
Ограничение оверкоммита не всегда означает отключение киллера - многое еще зависит от overcommit ratio
Еще момент: киллер убивает процесс с наибольшим oom_score - обычно самый жирный. С ограничением оверкоммита упадет не обязатено самый жирный - могут падать и мелкие процессы, если жирный процесс протекает, но при этом обрабатывает ошибки выделения
а oom_adj киллерами учитывается? я просто его базе назначаю
o👹
все остальное при утечках может умереть