kutelev Oct 10 2020 at 18:51

Тестирование приложений в условиях нехватки памяти

9 min

4.6K

Comments 52

gecube Oct 10 2020 at 21:56

Где же истории, как защищаться от ядерного Оомкиллера, когда система уже решила, что памяти не хватает и пора кого-нибудь прикончить? Я гарантирую, что любые колдунства над Malloс не дают гарантий, что оомкиллер в ядре не придёт в Вашу программу

Antervis Oct 11 2020 at 01:59

Runtime библиотеки на macOS уж очень не стабильны и норовят упасть при каждом «удобном случае»

а можно поподробнее?

Даже вызов printf на macOS может привести к SIGSEGV/SIGBUS.

ну если запихать в него каку, он где угодно упадет

Промежуточные косяки

Чтобы бросить исключение, например std::bad_alloc, необходимо выделить память под объект исключения. И, внезапно, память под объект исключения тоже может быть не выделена, если мы сталкиваемся с OOM

bad_alloc::what() может возвращать статическую строку. И резервировать память под объекты исключений отдельно. Хотя вы об этом написали ниже, но

На macOS никаких запасных буферов выявлено не было

а вы где выявляли? __cxa_allocate_exception из libc++ вызывает __aligned_malloc_with_fallback, который при нехватке памяти вызывает fallback_malloc, который как раз берет память из небольшого статического массива.

UPDATE: Как уже было сказано ранее, новые версии macOS / Xcode не имеют этой проблемы.

ой, всё

Поправьте статью плз… Ну и, как верно было замечено, нет смысла пытаться обрабатывать нехватку памяти до тех пор, пока вы не сможете гарантировать что ОС не сложит вашу приложуху SIGKILL'ом раньше

kutelev Oct 11 2020 at 06:27

а можно поподробнее?

Про printf всё очень просто, следующий код завершается аварийно на macOS, даже на Catalina при сборке с использованием Xcode 12:

int main(int argc, char** argv)
{
OverthrowerConfiguratorStep overthrower_configurator(0U);
activateOverthrower(); // Start failing ALL allocations.
printf("Some integer number: %d, some floating point number: %f, some string: %s\n", 100500, 100.500f, "100500");
deactivateOverthrower(); // Do not fail any allocations anymore.
return 0;
}

Ничего нелегального в fprintf, как мы видим, в данном случае не подаётся.

Запуск потока с использованием std::thread в условиях OOM приводит к падениям на macOS старее High Sierra.
Так же сталкивались с, что при попытки динамической загрузки Framework'ов вместо сообщений об ошибках получали падения внутри системных функций.

а вы где выявляли?

Из личного опыта и объективных результатов тестирования. Если __cxa_allocate_exception не может выделить память мы получаем аварийное завершение работы приложения даже на macOS Mojave: https://travis-ci.org/github/kutelev/overthrower/jobs/734673895

[ RUN      ] Overthrower.ThrowingException
...
libc++abi.dylib: terminating

На Catalina с последним Xcode этого не происходит.

Antervis Oct 11 2020 at 17:10

Ничего нелегального в fprintf, как мы видим, в данном случае не подаётся.

значит проблема не в printf?

приводит к падениям на macOS старее High Sierra… На Catalina с последним Xcode этого не происходит.

ну и забейте

BugM Oct 11 2020 at 03:38

В век контейнеров приходит ООМ киллер и убивает.
Вот это вот все не работает.

Tangeman Oct 11 2020 at 16:57

OOM киллер убивает не того кто просит память а того кто занимает больше всего памяти, при этом учитывая его важность для системы (OOM score).

Т.е. если ваш процесс не самый толстый в системе и к тому же имеет пониженный OOM score, то шанс его убийства довольно низок, хотя и остаётся открытым вопрос что случится если убитый процесс важен для работы вашего (или системы в целом).

В любом случае лучше попытаться (если возможно) аккуратно завершить работу в случае если память не дали (сбросить буфера, закрыть соединения, отменить транзакцию etc) чем просто умереть и потерять данные, на этот случай даже можно предусмотреть аварийный пул памяти (запрашиваемый в самом начале работы) которая может потребоваться на случай её нехватки в процессе нормальной работы.

Antervis Oct 11 2020 at 17:16

Т.е. если ваш процесс не самый толстый в системе

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

Tangeman Oct 11 2020 at 18:36

Единственный способ предоставить процессу заведомо достаточное количество памяти — это жёстко её выделить изначально, а это не всегда целесообразно — к примеру, это может быть процесс который обычно требует 10 Мб для работы, но изредка ему нужно (на короткое время) 100/200/500 Мб — если в этот самый момент когда оно нужно памяти нет, всё же лучше это обработать (к примеру, приостановить работу пока не появится). Выделять ему сразу потенциальный максимум — это просто бесполезная трата ресурса, своп тоже не всегда имеется (или может быть медленным до непрактичности).

BugM Oct 11 2020 at 19:05

У всех сейчас докеры с кубернетисами. Запросил больше положенного — умри. Негде там настраивать.
Процесс потребляющий на пике 500мб требует выделенных 500мб. Не надо такие процессы делать. Точнее 500Мб мелочи. А вот ступенька 1-50 Гб это больно. Приходится 50Гб выделять на постоянку. И доставать тикет на улучшение этого места из беклога.

gecube Oct 11 2020 at 19:19

ага, requests/limits — будьте добры ТОЧНО сказать сколько вам памяти надо — иначе на мороз, простите, в Вальгаллу для сервисов-неудачников ))))

Tangeman Oct 11 2020 at 19:26

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

Докеры и кубернетисы (которые, кстати, далеко не у всех, хотя и очень популярны) расчитаны на то чтобы ресурсы использовались максимально эффективно — это не карт-бланш на игнорирование ситуаций когда ресурсы временно могут оказаться недоступны.

И 500 MB совсем не мелочи — если у вас таких процессов с сотню, но эти самые 500 MB нужны далеко не всем одновременно. И ничего "неправильного" в таких процессах нет — всё зависит от задач.

BugM Oct 11 2020 at 20:13

Оверкоммит это очень плохой сценарий. Он ведет к непонятным тормозам или багам в проде. Не надо так делать.

Вот так и живем. Утилизация за счет удобного и маштабируемого разделения контейнеров по железкам. Пока все жили bare metal была частая ситуация когда сервера недозагружены. Забыли, забили, не умеют, не уверены что там с ресурсами, просто не могут софт так раскидать по кластерам. Разные причины. Сейчас это делается почти само. Когда один контейнер процентов 10-20 (или меньше) от железки можно набить плотненько.

Сейчас софт надо писать так чтобы пикового потребления не было. Старый постепенно переписывать. Крутись как хочешь, жизнь такая. 500Мб надо? Бери и пользуйся навсегда. Надо это делать эффективно.