C
Size: a a a
2019 November 18
GG
у тебя данные уже могут быть в труху
GG
насчет ресурсов - это лол, когда у тебя есть сервис, который при старте жрет ресурсов как не в себя, а потом выходит на.... устойчивое потребление
AY
Если ты в кубере, то данные выноси на отдельный диск и всё норм будет
GG
вспомните Историю катастрофы с ЦЕФом от Капитулы
A
насчет ресурсов - это лол, когда у тебя есть сервис, который при старте жрет ресурсов как не в себя, а потом выходит на.... устойчивое потребление
Про ресурсы — это о том, что оставлять софт работать в невалидном состоянии все равно не имеет смысла.
GG
> софт работать в невалидном состоянии все равно не имеет смысл.
с этой мыслью согласен
с этой мыслью согласен
ЕО
Alexander
Потому пристрелить OOM-ом загнанный процесс — самый милосердный вариант и с точки зрения потребления ресурсов, и с точки зрения сохранности данных.
Ну вообще не факт, у тебя стейтфул-сервис мог бы выходить в РО при проблемах с выделением памяти
ЕО
ООМ хорошее решение для стейтлесс приложений, но такое себе для баз данных и всего такого
A
у тебя данные уже могут быть в труху
Порчу данных из-за недозаписи софт еще может обработать. А вот ситуацию, когда данные просто тихо проебались, а код не в курсе и работает дальше, отловить почти невозможно.
Смотри. Вот например, у тебя софт делает malloc, а затем memcpy с выделенный регион памяти. malloc у тебя с оверкоммитментом пройдет почти всегда, т.к. памяти на самом деле не занимается и ситуация OOM произойдет только во время memcpy. Но memcpy не возвращает ошибку, у системы тупо нет никакой возможности сообщить приложению, что данные скопировать невозможно. И есть только 2 варианта: прибить процесс на месте или тихо не выполнить memcpy и дать программе работать дальше.
Смотри. Вот например, у тебя софт делает malloc, а затем memcpy с выделенный регион памяти. malloc у тебя с оверкоммитментом пройдет почти всегда, т.к. памяти на самом деле не занимается и ситуация OOM произойдет только во время memcpy. Но memcpy не возвращает ошибку, у системы тупо нет никакой возможности сообщить приложению, что данные скопировать невозможно. И есть только 2 варианта: прибить процесс на месте или тихо не выполнить memcpy и дать программе работать дальше.
A
Ну вообще не факт, у тебя стейтфул-сервис мог бы выходить в РО при проблемах с выделением памяти
Как должен выглядеть "переход в РО"? Особенно, при включенном оверкоммитменте.
GG
Alexander
Порчу данных из-за недозаписи софт еще может обработать. А вот ситуацию, когда данные просто тихо проебались, а код не в курсе и работает дальше, отловить почти невозможно.
Смотри. Вот например, у тебя софт делает malloc, а затем memcpy с выделенный регион памяти. malloc у тебя с оверкоммитментом пройдет почти всегда, т.к. памяти на самом деле не занимается и ситуация OOM произойдет только во время memcpy. Но memcpy не возвращает ошибку, у системы тупо нет никакой возможности сообщить приложению, что данные скопировать невозможно. И есть только 2 варианта: прибить процесс на месте или тихо не выполнить memcpy и дать программе работать дальше.
Смотри. Вот например, у тебя софт делает malloc, а затем memcpy с выделенный регион памяти. malloc у тебя с оверкоммитментом пройдет почти всегда, т.к. памяти на самом деле не занимается и ситуация OOM произойдет только во время memcpy. Но memcpy не возвращает ошибку, у системы тупо нет никакой возможности сообщить приложению, что данные скопировать невозможно. И есть только 2 варианта: прибить процесс на месте или тихо не выполнить memcpy и дать программе работать дальше.
Я не возражаю
GG
Нормальный софт выделяет памяти столько, сколько ему скажешь, плюс задекларированный оверхед.
Всё остальное — наколенное говно, писаное красноглазыми макаками, не умеющее обрабатывать NULL от malloc и делать memset.
Всё остальное — наколенное говно, писаное красноглазыми макаками, не умеющее обрабатывать NULL от malloc и делать memset.
Никто так не пишет софт. К сожалению
A
Нормальный софт выделяет памяти столько, сколько ему скажешь, плюс задекларированный оверхед.
Всё остальное — наколенное говно, писаное красноглазыми макаками, не умеющее обрабатывать NULL от malloc и делать memset.
Всё остальное — наколенное говно, писаное красноглазыми макаками, не умеющее обрабатывать NULL от malloc и делать memset.
Проблема в том, что 99% софта написано этими макаками, потому в ядре есть OOM.
GG
Alexander
Как должен выглядеть "переход в РО"? Особенно, при включенном оверкоммитменте.
Давайте оверкомит выключать. Не проблема
GG
Но если вам нравятся игрища с ублажением ООМ, бога ради, эджайл ведь, а память дешевле часа работы его величества программизда.
Лол
GG
Не всегда можно память докинуть
GG
Или дёшево докинуть