Точно - никак. Сама постановка задачи несколько странная.
Во-первых, OOM killer настраивается, и далеко не всегда его поведение имеет отношение к абстрактному "сколько памяти свободно". В некоторых режимах оверкоммита первостепенное значение начинает иметь аппроксимация первой или второй производной роста потребления у конкретного процесса и его могут прибить превентивно, иногда сильно далеко от конкретных лимитов потребления памяти.
Во-вторых, даже если таки как-то уговорить OOM killer погодить (в частном случае - отключив его или сильно закрутив лимиты) и выжрать памяти впритык - такая система внезапно становится сильно менее работоспособной, чем обычно, вплоть до "совсем неработоспособной". Особенно если в ней больше, чем один процесс.
Вопрос чисто теоретический или все-таки практический? На практике - подавляющее большинство живет примерной оценкой через чтение /proc/meminfo или /proc/vmstat и отнимания от них взятых с потолка 7-10-15%. Или все-таки это какая-то специфическая задача?
Итак, речь про обычный (дефолтный) режим №1. Меня интересует ситуация, когда free говорит, что памяти свободной много (допустим, free 300Mb, cached 3Gb, buffers 300Mb, в свопе +2Гб свободно), приложение пишет в 400Мб блок уже аллоцированной памяти, тут прилетает OOM и бьёт всех по рукам.
Экспериментально-эвристически было обнаружено, что дельта явно связана с объёмом записанного на tmpfs, но там ещё что-то есть.
.... А для мониторинга проблема, что "взятые с потолка 15%" ничего не гарантируют.
Ну, вообще почти везде дефолтный - как раз vm.overcommit_memory = 0, а не 1 - и там как раз эта эвристика, первая-вторая производная и все такое в полный рост
( ... )
Я попутал. Чтобы числа не писать, давай говорить guess, never, always. Дефолтный режим guess, именно его я и отлаживаю. При режиме never оно не работоспособно - приложения слишком много virt берут.
NUMA исключаем, у нас interleave.
За shmem спасибо.
У меня задача не приложение отлаживать, а понять, когда на сервере OOM придёт, чтобы мониторинг настроить. Обычными методами он промахивается и срабатывает либо сильно заранее, либо не предупреждает о предстоящем OOM'е.
Вообще, на самом деле - я так понимаю, что у вас относительно однозначный workload у сервера - есть X физической памяти и Y экземпляров виртуальных машин (у вас вроде KVM?), ведущих себя относительно однообразно.
Вы не думали о том, чтобы действительно отключать overcommit и делать какой-то собственный проактивный мониторинг / менеджмент памяти, например, в userspace, на основе собственно данных, таскаемых из виртуальных машин?
Во-первых, OOM killer настраивается, и далеко не всегда его поведение имеет отношение к абстрактному "сколько памяти свободно". В некоторых режимах оверкоммита первостепенное значение начинает иметь аппроксимация первой или второй производной роста потребления у конкретного процесса и его могут прибить превентивно, иногда сильно далеко от конкретных лимитов потребления памяти.
Во-вторых, даже если таки как-то уговорить OOM killer погодить (в частном случае - отключив его или сильно закрутив лимиты) и выжрать памяти впритык - такая система внезапно становится сильно менее работоспособной, чем обычно, вплоть до "совсем неработоспособной". Особенно если в ней больше, чем один процесс.
Вопрос чисто теоретический или все-таки практический? На практике - подавляющее большинство живет примерной оценкой через чтение /proc/meminfo или /proc/vmstat и отнимания от них взятых с потолка 7-10-15%. Или все-таки это какая-то специфическая задача?
Reply
Итак, речь про обычный (дефолтный) режим №1. Меня интересует ситуация, когда free говорит, что памяти свободной много (допустим, free 300Mb, cached 3Gb, buffers 300Mb, в свопе +2Гб свободно), приложение пишет в 400Мб блок уже аллоцированной памяти, тут прилетает OOM и бьёт всех по рукам.
Экспериментально-эвристически было обнаружено, что дельта явно связана с объёмом записанного на tmpfs, но там ещё что-то есть.
.... А для мониторинга проблема, что "взятые с потолка 15%" ничего не гарантируют.
Reply
Reply
NUMA исключаем, у нас interleave.
За shmem спасибо.
У меня задача не приложение отлаживать, а понять, когда на сервере OOM придёт, чтобы мониторинг настроить. Обычными методами он промахивается и срабатывает либо сильно заранее, либо не предупреждает о предстоящем OOM'е.
Reply
Reply
Вы не думали о том, чтобы действительно отключать overcommit и делать какой-то собственный проактивный мониторинг / менеджмент памяти, например, в userspace, на основе собственно данных, таскаемых из виртуальных машин?
Reply
Отключать оверкоммит - совсем не выход, qemu берёт virt'а больше, чем лимит памяти виртуалки в пару раз.
Reply
Leave a comment