rss memory что это
Под капотом Redis: Строки
Если вы знаете, почему простая строка `strings` в Redis займёт в оперативной памяти 56 байт — вам, думаю, статья не будет интересна. Всем остальным я попробую рассказать, что такое строки в Redis и почему использующему эту базу данных разработчику важно понимать, как они устроены и работают. Это знание особенно важно, если вы пытаетесь рассчитать фактическое потребление памяти вашим приложением или планируете строить высоко нагруженные системы статистики или учёта данных. Или, как часто бывает, пытаетесь срочно понять, почему вдруг ваш экземпляр redis стал потреблять неожиданно много памяти.
О чём буду рассказывать — как хранятся строки в Redis, какие внутренние структуры используются для хранения строк, какие виды оптимизаций использует Redis под капотом. Как эффективно хранить большие структуры и в каких ситуациях не стоит использовать строки или структуры, построенные на их основе. Строки — ключевая структура Redis, HSET/ZSET/LIST построены на их базе добавляя небольшой оверхед на представление своих внутренних структур. Зачем мне эта статья — более года я читаю и активно отвечаю на stackoverflow в тэге redis. На протяжение этого времени я постоянно вижу не прекращающийся поток вопросов так или иначе связанных с тем, что разработчики не понимают особенностей работы Redis с оперативной памятью и того, чем приходится расплачиваться за высокое быстродействие.
Ответ на вопрос сколько памяти будет использовано на самом деле зависит от операционной системы, компилятора, типа вашего процесса и используемого аллокатора(в redis по умолчанию jemalloc). Все дальнейшие расчёты я привожу для redis 3.0.5 собранном на 64 битном сервере под управлением centos 7.
Мне кажется, что тут совершенно необходима небольшая интерлюдия для тех, кто не пишет на с/с++ или не очень хорошо знаком с тем как всё работает на низком уровне. Давайте чудовищно сильно упростим несколько понятий, чтобы вам проще было понимать расчёты. Когда в программе на с/с++ вы объявляете структуру, и в ней у вас есть unsigned int поля (без знаковые целые на 4 байта) компилятор бережно выровняет их размер до 8 байт в реальной оперативной памяти (для х64 архитектуры). В это статье будет периодически говорится об аллокаторе памяти — эта такая штука которая выделяет память «по умному». Например, jemalloc старается оптимизировать для вас скорость поиска новых блоков памяти, делая ставку на выравнивание выделяемых фрагментов. Стратегия выделения и выравнивания памяти в jemalloс хорошо описана, однако я думаю, что нам стоит использовать упрощение, что любой размер выделенного фрагмента будет округлён до ближайшей степени 2. Вы просите 24 байт — выделят 32. Просите 61 — выделят 64. Я сильно упрощаю и надеюсь вам будет немного понятнее. Это те вещи, которые в интерпретируемых языках вас, по логике, волновать не должны, однако тут очень прошу вас обратить на них своё внимание.
Концепция и реализация строк за авторством Сальваторе Санфилиппо (aka antirez) лежит в одном из под проектов редиса под названием SDS (Simple Dynamic String, github.com/antirez/sds):
Это простая структура на `с`, заголовок которой хранит актуальный размер и свободное место в уже выделенной памяти, саму строку и обязательный завершающий ноль, который добавляет сам редис. В sds строках нас больше всего будет интересовать расходы на заголовок, стратегия изменения их размера и пенальти на выравнивание структур при выделении памяти.
4 июля 2015 года завершилась длинная история с оптимизацией строк, которой должна попасть в редис 3.1. Эта оптимизация привнесёт большую экономию памяти в заголовках строк (от 16% до 200% на синтетических тестах). Снимет ограничение в 512Мб на максимальную длину строки в редисе. Всё это станет возможным благодаря динамическому изменения длины заголовка при изменении длины строки. Так заголовок будет занимать всего 3 байта для строк с длиной до 256 байт, 5 байт для строк менее 65 кб, 9 байт (как сейчас) для строк до 512 мб и 17 байт для строк, чей размер «влазит» в uint64_t (64 битное без знаковое целое). К слову, с этим изменением наша реальная ферма экономит порядка 19,3% памяти (
42 гб). Однако, в последний на текущей момент 3.0.х с заголовком всё просто — 8 байт + 1 байт на завершающий ноль. Давайте прикинем, сколько памяти займет строка «strings»: 16 (заголовок) + 7 (длина строки) + 1(завершающий ноль) = 24 байта (16 байт на заголовок, т.к. компилятор выровняет для вас 2 unsigned int). При этом jemalloc выделит для вас 32 байта. Давайте пока это опустим (надеюсь позже будет понятно почему).
Что происходит, когда строка меняет размер? Всякий раз когда вы увеличиваете размер строки и уже выделенной памяти не хватает, редис сверяет новую длину с константой SDS_MAX_PREALLOC (определена в sds.h и составляет 1,048,576 байт). Если новая длина меньше этой величины, будет выделена память вдвое больше запрашиваемой. Если длина строки уже превышает SDS_MAX_PREALLOC — к новой запрашиваемой длине будет добавлено значение этой константы. Эту особенность будет важна в истории «про исчезающую память при использование bitmap». К слову сказать, при выделении памяти под bitmap всегда будет выделено в 2 раза больше запрошенного, из-за особенностей реализации команды setbit (смотри setbitCommand в bitops.c).
Теперь можно было бы сказать, что наша строка займёт в оперативной памяти 32 байта (с учетом выравнивания). Те, кто читал советы ребят из hashedin.com (redis memory optimization guide) могут вспомнить, что они настоятельно рекомендуют не использовать строки длиной менее 100 байт, т.к. для хранения короткой строки, скажем при использовании команды `set foo bar` вы потратите
96 байт из которых 90 байт это оверхед (на 64 битной машине). Лукавят? Давайте разбираться дальше.
Все значения в редис хранятся в структуре типа redisObject. Это позволяет редису знать тип значения, его внутреннее представление (в редисе это называется кодировкой), данные для LRU, количество ссылающихся на значение объектов и непосредственно само значение:
Чуть позже посчитаем её размер для нашей строки с учётом выравнивания компилятора и особенностей jemalloc. В разрезе строк нам очень важно знать, какие кодировки используются для хранения строк. Прямо сейчас редис использует три различные стратегии хранения:
EMBSTR появились в 2012 году и привнесли 60-70% увеличение производительности при работе с короткими строками, однако серьезных изысканий на тему влияния на память и её фрагментацию нет до сих пор.
Длина нашей строки «strings» всего 7 байт, т.е. тип её внутреннего представления — EMBSTR. Созданная таким образом строка размещена в памяти вот так:
Теперь мы готовы посчитать сколько оперативной памяти потребуется redis для хранения нашей строки «strings».
(4 + 4) * + 8(encoding) + 8 (lru) + 8 (refcount) + 8 (ptr) + 16 (sds header) + 7(сама строка) + 1 (завершающий ноль) = 56 байт.
Тип и значение в redisObject используют только 4 младших и старших бита одного числа, поэтому эти два поля после выравнивания займут 8 байт.
Давайте проверим, что я не вожу вас за нос. Посмотрим кодировку и значение. Воспользуемся одной мало известной командой для отладки строк — DEBUG SDSLEN. К слову, команды нет в официальной документации, она была добавлена в redis 2.6 и бывает очень полезна:
Используемая кодировка — embstr, длина строки 7 байт (val_sds_len). Что насчёт тех 96 байт, про которые говорили парни из hashedin.com? В моём понимании, они немного ошиблись, их пример с `set foo bar` потребует выделение 112 байт оперативной памяти (56 байт на значение и столько же на ключ), из которых 106 — оверхед.
Чуть выше я обещал историю про исчезающую память при использование BITMAP. Особенность о которой я хочу рассказать, постоянно утекает из внимания части разработчиков, её использующих. Парни, на этом регулярно зарабатывают консультанты по оптимизации памяти. Такие как redis-labs или datadog. Семейство команда «Bit and byte level operations» появились в redis 2.2 и сразу позиционировались как палочка выручалочка для счётчиков реального времени (например, статья от Spool), которые позволяют экономить память. В официальном гайде по оптимизации памяти тоже есть рекламный слоган об использовании этого семейства данных для хранения онлайна «Для 100 миллионов пользователей эта данные займут всего 12 мегабайт оперативной памяти». В описании SETBIT и SETRANGE предупреждают о возможных лагах работы сервера при выделении памяти, опуская при этом важный, как мне кажется, раздел «Когда вам не стоит использовать BITMAP» или «Когда лучше использовать SET вместо BITMAP».
Ваш фактический расход памяти составил 2,298,577 байт, при «полезной» для вас 1,250,001 байтах. Хранение одного вашего пользователя обошлось вам в
2,3 мб. Используя SET вам потребовалось бы
64 байта (при 4 байтах полезной нагрузки). Нужно правильно выбирать интервалы агрегации так, чтобы снижать разреженность данных и стараться, чтобы заполнение bitmap лежало в диапазоне от 30% — в этом случае вы на самом деле будете эффективно использовать память под эту структуру данных. Я говорю это к тому, что если у вас многомиллионная аудитория, а часовой онлайн скажем 10,000 — 100,000 человек то использовать для этой цели bitmap может быть накладным по памяти.
Наконец, изменение размеров строк в редисе — это постоянное перераспределение блоков памяти. Фрагментации памяти ещё одна специфика редис, о котором разработчики мало задумываются.
Метрика mem_fragmentation_ratio показывает отношение выделенной операционной системой памятью (used_memory_rss) и памятью, используемой редисом (used_memory). При этом used_memory и used_memory_rss уже включат в себя как сами данные так и затраты на хранение внутренних структур редиса для их хранения и представления. Редис рассматривает RSS (Resident Set Size) как выделенное операционной системой количество памяти, в котором помимо пользовательских данных (и расходов на их внутреннее представление)учитываются расходы на фрагментацию при физическом выделение памяти самой операционной системой.
Как понимать mem_fragmentation_ratio? Значение 2,1 говорит нам что мы используем на 210% больше памяти под хранение данных, чем нам нужно. А значения меньше 1 говорит о том, что память кончилась и операционная система свапится.
В разговоре о фрагментации, я не учитываю специфике редиса при включенном LRU или дополнительных сложностях при большом количество обычный строковых ключей — всё это тянет на отдельную статью. Буду признателен, если вы поделитесь предложениями, стоит ли об этом писать и что ещё вам кажется важным при работе с редисом.
Пользователь pansa верно замечает, что в ситуации со свапом редис не пересчитает значение used_memory_rss после того как операционная система вернёт процессу часть оперативной памяти. Редис пересчитает это значение уже при обращении к данным.
Перевыделение памяти в Linux и admin_reserve_kbytes
Кому сложно понять что такое перевыделение памяти, то для сравнения можно привести пример с продажей билетов, скажем в кино. К примеру, в кинотеатре всего 100 мест, а мы продали 1000 в надежде, что не все купившие билеты дойдут до кинотеатра и востребуют свои места. Но, » сталося не так як гадалося «:
Дабы подобного беспредела не происходило на Linux сервере мы обязательно должны ограничить рамки перевыделения памяти, что дополнительно избавит от необходимости тратить ресурсы на эвристику, например:
Обычно, относительно «вменяемые» приложения при запуске запрашивают не более чем в 3 раза больше памяти, чем им реально требуется, а значит vm.overcommit_ratio=300 должно быть вполне достаточно в большинстве случаев. При таком раскладе будет доступно оперативки: РАМ * (overcommit_ratio/100) + SWAP. Скажем, у нас РАМ 2048 МБ и СВОП 5120, тогда получим: 2048 * 3 + 5120 = 11264 МБ около того.
vm.overcommit_memory=2 совместно с vm.overcommit_ratio=300 определяет границы реальных возможностей системы виртуальной памяти, а OOM killer (OOM: out-of-memory) в свою очередь прибивая пизданутые процессы и/или их чилдов помогает остальным процессам пребывать в равновесии с системными ресурсами.
При vm.overcommit_memory=1 система считает, что в наличии неограниченное количество памяти и выделяет её без ограничений до тех пор пока она вся реально не закончится.
VSZ and RSS Linux memory
man admin_reserve_kbytes
The amount of free memory in the system that should be reserved for users with the capability cap_sys_admin.
admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
That should provide enough for the admin to log in and kill a process, if necessary, under the default overcommit ‘guess’ mode.
Systems running under overcommit ‘never’ should increase this to account for the full Virtual Memory Size of programs used to recover. Otherwise, root may not be able to log in to recover the system.
How do you calculate a minimum useful reserve?
sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
For overcommit ‘guess’, we can sum resident set sizes (RSS). On x86_64 this is about 8MB.
For overcommit ‘never’, we can take the max of their virtual sizes (VSZ) and add the sum of their RSS. On x86_64 this is about 128MB.
Changing this takes effect whenever an application requests memory.
Что такое cap_sys_admin и с чем его едят
Отобразить список процессов и назначенный им список capabilities-флагов можно с помощью pscap из пакета libcap-ng-utils :
Как распределяется admin_reserve_kbytes
Ответ: а хрен его знает, документация по данному флагу об этом умалчивает.
Давайте «погульчитаем» документацию по admin_reserve_kbytes где говорится, что:
Замечено, что на процессы запускаемые от root-a через systemd эта самая зарезервированная в размере admin_reserve_kbytes оперативка не выделяется, а просто себе болтается без дела, и в этом можно убедится опытным путём.
Опыт №1
Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!
Запустив скрипт получим сумму значений VmSize и VmRSS всех процессов выданных прогой pscap :
Из результата видим, что рекомендуемое значение для admin_reserve_kbytes основанное на «VSZ + RSS» в данном случае составило 2166444 kB.
Увы, документация не уточняет какая именно » amount of free memory » резервируется параметром admin_reserve_kbytes = это от суммы СВОПа+РАМы или от одной РАМы? Вероятнее всего, от суммы СВОПа+РАМы.
Потому, как все системные процессы из списка pscap уже запросили память при запуске и она была им выделена, то в условиях:
Опыт №2
Однако, запуская все те же процессы, что были до перезагрузки, среди которых был и браузер palemoon :
На значении чуть выше 8128504 кб браузер был «забит» и перед смертью выдал » fork(): Невозможно выделить память «. Аналогичный результат можно получить при попытке запуска хрона:
Итоги опытов
В итоге опытным путём мы убедились, что на процессы запускаемые от имени root через systemd зарезервированная память из admin_reserve_kbytes не выделяется, а просто себе болтается без дела как до, так и после перезагрузки.
Вероятно выделение памяти из admin_reserve_kbytes для пользователей с флагом cap_sys_admin происходит при интерактивном взаимодействии с машиной, например при авторизации по SSH/SU и т.п.
Как дать пользователю возможности cap_sys_admin
cap_sys_admin для su-пользователей CentOS 6/7
Значение для admin_reserve_kbytes
Значение admin_reserve_kbytes по-умолчанию
Вот, пожалуйста, не у одного меня возник подобный вопрос на данную тему:
На машине с Debian Stretch где » MemTotal: 250400 kB » и vm.overcommit_memory = 0 составило vm.admin_reserve_kbytes = 7616
Однако на другой машине с той же ОС Debian Stretch где » MemTotal: 5083092 kB » и vm.overcommit_memory = 0 составило vm.admin_reserve_kbytes = 8192
Таким образом, admin_reserve_kbytes:
Оптимальное значение для admin_reserve_kbytes
OOM killer
Немного про OOM killer (OOM: out-of-memory).
This enables or disables killing the OOM-triggering task in out-of-memory situations.
If this is set to zero, the OOM killer will scan through the entire tasklist and select a task based on heuristics to kill. This normally selects a rogue memory-hogging task that frees up a large amount of memory when killed.
If this is set to non-zero, the OOM killer simply kills the task that triggered the out-of-memory condition. This avoids the expensive tasklist scan.
If panic_on_oom is selected, it takes precedence over whatever value is used in oom_kill_allocating_task.
The default value is 0.
Если это значение равно нулю, убийца OOM просканирует весь список задач и выберет задачу для уничтожения на основе эвристики. Обычно он выбирает задачу, которая при уничтожении освободит больше всего памяти.
Если для этого параметра установлено ненулевое значение, убийца OOM просто завершает задачу, которая вызвала состояние нехватки памяти. Это позволяет избежать дорогостоящего сканирования списка задач.
Рекомендуемый контент
А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net
Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).
Smem – Отчеты о распределении памяти между процессами и пользователями в Linux
И снова здравствуйте. Друзья, хотим поделиться с вами переводом полезного материала о мониторинге использования памяти в Linux. Данный материал подготовлен специально для студентов курса «Администратор Linux».
Управление памятью в вопросах мониторинга ее использования – одна из самых важных областей в вашей Linux системе. В различных дистрибутивах Linux существует великое множество инструментов для мониторинга использования памяти. Работают они тоже по разному, но в этой статье мы рассмотрим установку и использования такого инструмента как smem.
Smem – это инструмент предоставления отчетов в командной строке, который выдает пользователю различные сводки по использованию памяти в системе Linux. В smem есть одна уникальная вещь, которая отличает его от традиционных инструментов мониторинга памяти. Дело в том, что smem сообщает вам PSS (Proportional Set Size), то есть он дает более полноценное представление о распределении памяти между приложениями и библиотеками в настройках виртуальной памяти.
Существующие традиционные инструменты сосредоточена главным образом на считывании RSS (Resident Set Size), т.е. на стандартной мере мониторинга использования памяти в физической схеме памяти, которая тем не менее имеет тенденцию переоценивать использование памяти приложениями.
С другой стороны PSS рационально оценивает использование памяти, определяя справедливое ее распределение между приложениями и библиотеками в схеме виртуальной памяти.
Вы можете обратиться к этому руководству (о PSS и RSS памяти), чтобы понять механизм потребления памяти в системе Linux. А теперь давайте перейдем к рассмотрению некоторых особенностей smem.
Особенности Smem:
Как установить Smem – инструмент мониторинга памяти в Linux
Перед тем, как приступить к установке smem, необходимо убедиться, что ваша система удовлетворяет следующим параметрам:
Большинство дистрибутивов Linux на сегодняшний день поставляются с последней версией ядра с поддержкой Python 2 или 3, поэтому единственным требованием по сути может быть только установка matplotlib для отрисовки красивых графиков.
На системах RHEL, CentOS и Fedora
Для начала включите репозиторий EPEL (Extra Packages for Enterprise Linux), затем установите следующее:
На системах Debian и Ubuntu
На Linux Mint
На Arch Linux
Как использовать Smem
Чтобы увидеть отчет по использованию памяти системой, всеми пользователями системы, введите следующую команду:
Когда стандартный пользователь запускает smem, то отображается использование памяти процессом, который инициировал этот пользователь. Процессы организованы по возрастанию PSS.
Взгляните на пример вывода для моей системы. Здесь показано использование памяти для процессов, инициированных пользователем aaronkilik:
Есть множество опций, которые вы можете вызвать во время использования smem, например, чтобы просмотреть потребление памяти в масштабах системы, выполните следующую команду:
Также вы можете просмотреть использование памяти маппингами:
Форматирование вывода может быть крайне полезным, поэтому smem предоставляет параметры, которые помогут вам форматировать отчеты об использовании памяти. Далее мы рассмотрим пару примеров.
Следующая команда будет выводить итоговые показатели в конце каждого столбца выходных данных:
Кроме того, есть специальные опции для графических сводок, которые вы также можете использовать. В этой секции мы их и рассмотрим.
Вы можете создать гистограмму процессов и их PSS и RSS значений. В приведенном ниже примере мы создаем гистограмму процессов, принадлежащих пользователю root.
Существует множество других полей помимо PSS и RSS, используемых для маркировки диаграмм.
Сейчас мы остановимся в smem на этом этапе. Если вы хотите получше разобраться с этим инструментом, посетите страницу руководства.
Memory_working_set vs Memory_rss in Kubernetes, which one you should monitor?
Jul 29, 2020 · 3 min read
In this article, we will know how cAdvisor collects memory_working_set and memory_rss metrics. Which one we should monitor, and which one causes OOMkill if we applied memory limits to your pods.
Before we get to the difference:
List the content of this directory and you will get the following control files:
Each file contains a piece of information about the memory. You can read more about them here.
What we are really interested in now is memory.status file:
cAdv i sor gathers those numbers and uses them to calculate memory metrics which are collected by Prometheus.
The difference between “container_memory_working_set_bytes” and “container_memory_rss”:
container_memory_rss:
From cAdvisor code, the memory RSS is:
The amount of anonymous and swap cache memory (includes transparent hugepages).
and it equals to the value of total_rss from memory.status file, find the code here:
Don’t confuse RSS with ‘ resident set size’. From kernel documentation:
Note:
Only anonymous and swap cache memory is listed as part of ‘rss’ stat.
This should not be confused with the true ‘resident set size’ or the
amount of physical memory used by the cgroup.
‘rss + file_mapped” will give you resident set size of cgroup.
(Note: file and shmem may be shared among other cgroups. In that case,
file_mapped is accounted only when the memory cgroup is owner of page
cache.)
container_memory_working_set_bytes:
From cAdvisor code, they define the working set memory as:
The amount of working set memory, this includes recently accessed memory,dirty memory, and kernel memory. Working set is Note:
The value from kubectl top pods the command is from container_memory_working_set_bytes metric.
Which one is important to monitor?
Now we know how cAdviser gets ‘ RSS’ and ‘ workin_set_bytes’ values, which one to monitor?
It is worth mentioning that if you are using resource limits on your pods, then you need to monitor both of them to prevent your pods from being oom-killed.