Ну, вообще почти везде дефолтный - как раз vm.overcommit_memory = 0, а не 1 - и там как раз эта эвристика, первая-вторая производная и все такое в полный рост.
Если я правильно понимаю, как работает tmpfs/aufs - они используют POSIX shm + хранение в page cache, т.е. с точки зрения free - страницы tmpfs/aufs - это либо "Cached" (если они в памяти), либо "Swap" (если высвопились). С точки зрения точечных измерений - в какой-то степени этому можно верить, с точки зрения динамики - разумеется, это более-менее бесполезные сведения. Тогда уж проще смотреть в Shmem в /proc/meminfo.
Единственный нетривиальный момент с tmpfs/aufs - то, что они могут в некоторых случаях привязываться свои пулы страниц к каким-то NUMA-нодам, что не так уж редко встречается на современных серверах с >1 физическим процессором. Там тогда возникают более хитрые дополнительные пределы роста на-одну-ноду, которые я не очень представляю, как смотреть и тем более мониторить.
В приведенном случае, по-моему, срабатывает как раз эта самая эвристика "приложение слишком быстро растет, за последние 2 аккаунтинга оно стабильно выросло в X раз, если оно так будет расти - точно выйдет за CommitLimit" => "надо прибивать".
Если задача - никакими средствами не менять vm.overcommit_memory (и оно на самом деле дефолтное 0, а не 1, как ты говоришь), то можно идти двумя путями - либо отлаживать и править приложение, чтобы оно менее агрессивно хапало память (например, подменить realloc/remmap на какой-то более "мягкий" аллокатор - это можно делать через LD_PRELOAD в том числе), либо что-нибудь пытаться тюнить в OOM killer'е. Как вариант, я помню, кто-то говорил, что увеличение герцов ядра (до 1000 и вроде даже выше) сильно облегчает такие симптомы.
Я попутал. Чтобы числа не писать, давай говорить guess, never, always. Дефолтный режим guess, именно его я и отлаживаю. При режиме never оно не работоспособно - приложения слишком много virt берут.
NUMA исключаем, у нас interleave.
За shmem спасибо.
У меня задача не приложение отлаживать, а понять, когда на сервере OOM придёт, чтобы мониторинг настроить. Обычными методами он промахивается и срабатывает либо сильно заранее, либо не предупреждает о предстоящем OOM'е.
Если я правильно понимаю, как работает tmpfs/aufs - они используют POSIX shm + хранение в page cache, т.е. с точки зрения free - страницы tmpfs/aufs - это либо "Cached" (если они в памяти), либо "Swap" (если высвопились). С точки зрения точечных измерений - в какой-то степени этому можно верить, с точки зрения динамики - разумеется, это более-менее бесполезные сведения. Тогда уж проще смотреть в Shmem в /proc/meminfo.
Единственный нетривиальный момент с tmpfs/aufs - то, что они могут в некоторых случаях привязываться свои пулы страниц к каким-то NUMA-нодам, что не так уж редко встречается на современных серверах с >1 физическим процессором. Там тогда возникают более хитрые дополнительные пределы роста на-одну-ноду, которые я не очень представляю, как смотреть и тем более мониторить.
В приведенном случае, по-моему, срабатывает как раз эта самая эвристика "приложение слишком быстро растет, за последние 2 аккаунтинга оно стабильно выросло в X раз, если оно так будет расти - точно выйдет за CommitLimit" => "надо прибивать".
Если задача - никакими средствами не менять vm.overcommit_memory (и оно на самом деле дефолтное 0, а не 1, как ты говоришь), то можно идти двумя путями - либо отлаживать и править приложение, чтобы оно менее агрессивно хапало память (например, подменить realloc/remmap на какой-то более "мягкий" аллокатор - это можно делать через LD_PRELOAD в том числе), либо что-нибудь пытаться тюнить в OOM killer'е. Как вариант, я помню, кто-то говорил, что увеличение герцов ядра (до 1000 и вроде даже выше) сильно облегчает такие симптомы.
Reply
NUMA исключаем, у нас interleave.
За shmem спасибо.
У меня задача не приложение отлаживать, а понять, когда на сервере OOM придёт, чтобы мониторинг настроить. Обычными методами он промахивается и срабатывает либо сильно заранее, либо не предупреждает о предстоящем OOM'е.
Reply
Reply
Leave a comment