Комментарии 15
Спасибо, очень годная статья. Вот каждый раз делаю cat /proc/meminfo (редко), или в метрики смотрю, и каждый раз приходится вспоминать, а что все эти слова значат. Особенно WSS.
Напрашивается в начале статьи кратенько (свёрнуто) список этих самых типов памяти и расшифровочку. Да, и про библиотечки я б тоже послушал - грузятся ли они в память, а в какую. Чтоб добавил одну только эту статью в закладки, и каждый раз, когда надо, пошёл, посмотрел и всё сразу стало ясно. Да даже не в закладки, а прям с графаны ссылочку сюда тыц.
Статья хорошая, в начале вы пишите:
Формально, OOM-killer вызывается тогда, когда usage_bytes достигает лимита
А ниже по статье
На самом деле, память кончается, когда ее съедает RSS
Или я что то здесь не понял
Представьте, что есть бочка с водой. В бочке плавает поплавок, который возвышается над водой на 5 сантиметров. Владелец бочки считаете, что бочка полная, не когда вода достигнет края, а когда края достигает поплавок. По хорошему, можно долить еще 5 см воды. Но владелец говорит "нет, нифига, я сужу по поплавку".
Формально, до края бочки доходит поплавок. Но доходит он только потому, что его толкает вода. Вода - это RSS. Поплавок - это usage.
Отличная статья, спасибо! Я как разу же неделю не мог понять, почему же Rancher в своём встроенном дашборде использования ресурсов рисует мне конское использование памяти, хотя я вижу, что памяти скушано намного меньше, а всё остальное -- файловый кэш. Очевидно, от тупо рисует сумму usage_in_bytes во всех относящихся в подам cgroups.
По поводу поведения oom_killer. И по моим наблюдениям, и по документации ядра уборщик Виктор oom_killer не сразу приступает к работе. Достижение лимита usage_in_bytes не должно мгновенно вызывать ситуацию OOM. Если немного подождать, то kswapd может успеть высвободить память. Об этом в той же документации говорится, киллер сначала много думает. Да, это объяснено дальше по тексту статьи, без погружения вглубь непонятно, что на самом деле у нас конкурентный процесс, когда мы не можем выделить память, но ждём ещё немного в надежде, что kswapd будет достаточно расторопен. Ещё в ядре 2.6, кстати, киллер особо не раздумывал, что доставляло немало беспокойства в эпоху засилья SLES 11 в моей конторе. Сейчас стало намного лучше.
Если немного подождать, то kswapd может успеть высвободить память
вот только емип в доке к k8s написано что swap надо хоронить, потому что они не осилили допилить что-то там..
так что формально вы правы, но для топикстартера пишущего статью с точки зрения пользователя k8s это всё "о птичках"..
Кстати, забавная ситуация со swap. В документации к ванильному k8s написано, что он должен быть отключен, а вот в документации к RKE2 такого требования уже нет, и они пишут, что не видят причин, по которым от него нужно отказываться. И как это понимать?
вот только емип в доке к k8s написано что swap надо хоронить, потому что они не осилили допилить что-то там..
Да, и главное. Насколько я понимаю, освобождением страниц, занятых дисковым кэшем, занимается тоже kswapd. Что вполне логично, он ведь решает, что можно выгрузить на диск, так почему бы ему же и не решать, что "доступно где-то ещё".
@lexore Спасибо за пост. Я пытаюсь найти информацию. Может вы подскажите. Как правильно высчитать сколько выставлять request cpu/memory для pod в k8s ? Выставлять значения, которые pod потребляет через 5 минут после старта? Или выставлять request cpu/memory средния в течение дня значения?
Мне кажется, среднее в течение дня будет ближе к среднему потреблению вообще.
Почему среднее а не максимальное ?
Для максимального предполагается использовать лимиты. Хотя реквесты и лимиты - это инструменты. Существуют разные подходы, как их использовать, например:
лимиты = реквесты = максимальное потребление
лимиты = реквесты * 2
и т.д.
Ваши настройки зависят от того, какие у вас приложения и какие у вас условия работы приложений.
Благодарю, очень дотошный обзор, одна из лучших статей с доходчивым описанием работы памяти (после https://www.linuxatemyram.com/). Про коварность WSS до этого не знал.
Благодарю за очень полезную статью!
Коварство метрик памяти Kubernetes (и cgroups)