Rss memory что это
Что такое RSS и VSZ в управлении памятью Linux
Что такое RSS и VSZ в управлении памятью Linux? В многопоточной среде, как можно управлять и отслеживать обе эти функции?
Таким образом, если процесс A имеет двоичный файл размером 500 КБ и связан с 2500 КБ совместно используемых библиотек, имеет 200 КБ выделенных стеков / кучи, из которых 100 КБ фактически находится в памяти (остальная часть поменялась местами или не используется), и он фактически загрузил только 1000 КБ совместно используемых библиотек. и 400K своего двоичного файла:
Поскольку часть памяти является общей, многие процессы могут использовать ее, поэтому, если вы сложите все значения RSS, вы легко сможете получить больше места, чем в вашей системе.
Память, которая выделяется, также может отсутствовать в RSS, пока она не будет фактически использована программой. Поэтому, если ваша программа выделяет кучу памяти заранее, а затем использует ее со временем, вы можете увидеть, что RSS растет, а VSZ остается прежним.
Существует также PSS (пропорциональный размер набора). Это более новая мера, которая отслеживает общую память как пропорцию, используемую текущим процессом. Так что, если раньше было два процесса, использующих одну и ту же общую библиотеку:
Все потоки имеют одинаковое адресное пространство, поэтому RSS, VSZ и PSS для каждого потока идентичны всем другим потокам в процессе. Используйте ps или top для просмотра этой информации в linux / unix.
Существует гораздо больше, чем это, чтобы узнать больше, проверьте следующие ссылки:
What is RSS and VSZ in Linux memory management
What are RSS and VSZ in Linux memory management? In a multithreaded environment how can both of these can be managed and tracked?
6 Answers 6
RSS is the Resident Set Size and is used to show how much memory is allocated to that process and is in RAM. It does not include memory that is swapped out. It does include memory from shared libraries as long as the pages from those libraries are actually in memory. It does include all stack and heap memory.
VSZ is the Virtual Memory Size. It includes all memory that the process can access, including memory that is swapped out, memory that is allocated, but not used, and memory that is from shared libraries.
So if process A has a 500K binary and is linked to 2500K of shared libraries, has 200K of stack/heap allocations of which 100K is actually in memory (rest is swapped or unused), and it has only actually loaded 1000K of the shared libraries and 400K of its own binary then:
Since part of the memory is shared, many processes may use it, so if you add up all of the RSS values you can easily end up with more space than your system has.
The memory that is allocated also may not be in RSS until it is actually used by the program. So if your program allocated a bunch of memory up front, then uses it over time, you could see RSS going up and VSZ staying the same.
There is also PSS (proportional set size). This is a newer measure which tracks the shared memory as a proportion used by the current process. So if there were two processes using the same shared library from before:
Threads all share the same address space, so the RSS, VSZ and PSS for each thread is identical to all of the other threads in the process. Use ps or top to view this information in linux/unix.
There is way more to it than this, to learn more check the following references:
Перевыделение памяти в 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).
Как правильно посмотреть сколько оперативной памяти потребляет процесс
В этой заметке мы узнаем, какое значение памяти, используемой процессом, является верным.
Понимание использования памяти в Linux
Эта запись для тех людей, которые когда-либо задавались вопросом: «Почему простой текстовый редактор KDE занимает 25 мегабайт памяти?» Многие люди думают, что многие приложения Linux, особенно программы KDE или Gnome, «раздуты» исключительно на основании того, что сообщают такие инструменты, как ps. Хотя это может быть правдой, а может и нет, в зависимости от программы, в целом это не так — многие программы намного эффективнее с точки зрения памяти, чем кажется.
Что сообщает ps
Инструмент ps может выводить различную информацию о процессе, такую как его идентификатор процесса, текущее состояние выполнения и использование ресурсов. Двумя возможными выходами являются VSZ и RSS, которые обозначают «virtual set size» и «resident set size», которые обычно используются компьютерщиками по всему миру, чтобы увидеть, сколько памяти занимают процессы.
Например, вот результат
для программы Writer из офисного пакета LibreOffice на моем компьютере:
Размер памяти приводится в килобайтах. Согласно ps, Writer имеет виртуальный размер около 12 гигабайт (!) и резидентный размер около 500 мегабайт (оба числа выше указаны в килобайтах). При этом в офисном пакете открыт не очень большой файл, в котором я в данный момент пишу. Похоже, что большинству людей нравится случайным образом выбирать одно из этих числе и использовать его как реальное использование памяти процессом. Я не собираюсь сейчас объяснять разницу между VSZ и RSS, но, разумеется, это неправильный подход; ни одно из чисел не даёт точного представления о том, какова стоимость памяти для работы Writer.
Почему ps «неправильный»
В зависимости от того, как вы на это смотрите, ps не сообщает о реальном использовании памяти процессами. На самом деле он показывает, сколько реальной памяти занял бы каждый процесс, если бы он был единственным запущенным процессом. Конечно, на типичной Linux-машине в любой момент времени выполняется несколько десятков процессов, а это означает, что числа VSZ и RSS, сообщаемые ps, почти определённо «неправильны». Чтобы понять почему, необходимо узнать, как Linux обрабатывает разделяемые библиотеки в программах.
Большинство основных программ в Linux используют общие библиотеки для облегчения определённых функций. Например, программа редактирования текста поставляемых с окружением рабочего стола KDE будет использовать несколько общих библиотек KDE (для обеспечения взаимодействия с другими компонентами KDE), несколько X-библиотек (для отображения изображений, копирования и вставки) и несколько общих системных библиотек (для выполнения основных операций). Многие из этих разделяемых библиотек, особенно часто используемые, такие как libc, используются многими программами, работающими в системе Linux. Благодаря этому совместному использованию Linux может использовать отличный трюк: он загружает одну копию разделяемых библиотек в память и использует эту копию для каждой программы, которая на неё ссылается.
Хорошо это или плохо, но многие инструменты не особо заботятся об этом очень распространённом приёме; они просто сообщают, сколько памяти использует процесс, независимо от того, используется ли эта память совместно с другими процессами. Таким образом, две программы могут использовать большую разделяемую библиотеку, но при этом её размер учитывается в обоих общих показателях использования памяти; библиотека подсчитывается дважды, что может ввести в заблуждение, если вы не знаете, что происходит.
К сожалению, нелегко получить идеальное представление об использовании памяти процессом. Вам нужно не только понять, как на самом деле работает система, но и решить, как вы хотите решать некоторые сложные вопросы. Следует ли учитывать общую библиотеку, которая требуется только для одного процесса, в использовании памяти этим процессом? Если общая библиотека используется моими несколькими процессами, следует ли равномерно распределять её использование памяти между различными процессами или просто игнорировать? Здесь нет жёсткого правила; у вас могут быть разные ответы в зависимости от ситуации, с которой вы столкнулись. Легко понять, почему ps не старается изо всех сил сообщать «правильные» итоги использования памяти, учитывая неоднозначность.
Просмотр карты памяти процесса
Хватит разговоров; давайте посмотрим, как обстоят дела с этим «огромным» процессом Writer. Чтобы увидеть, как выглядит память Writer, воспользуемся программой pmap (с флагом -d после которого идёт PID (идентификатор процесса)):
Я вырезал много вывода; остальное похоже на то, что показано. Даже без полного вывода мы можем увидеть некоторые очень интересные вещи. Важно отметить, что в выводе каждая разделяемая библиотека указана дважды; один раз для сегмента кода и один раз для сегмента данных. Сегменты кода имеют режим «r-x—», в то время как данные установлены на «rw—». Столбцы Kbytes, Mode и Mapping — единственные, о которых мы будем заботиться, так как остальные не важны для обсуждения.
Если вы просмотрите вывод, вы обнаружите, что строки с наибольшим количеством килобайт обычно являются сегментами кода включённых разделяемых библиотек (те, которые начинаются с «lib», являются разделяемыми библиотеками). Что замечательно в этом, так это то, что они могут быть разделены между процессами. Если вы вычлените все части, которые совместно используются процессами, вы получите общее количество «writeable/private», которое отображается в нижней части вывода.
Это то, что можно считать дополнительными затратами этого процесса без учёта разделяемых библиотек. Следовательно, стоимость запуска этого экземпляра Writer (при условии, что все общие библиотеки уже загружены) составляет около 1 гигабайта. Это совсем другая история по сравнению с 12 гигабайтами, о которых сообщила ps.
Что все это значит?
Мораль этой истории заключается в том, что использование памяти процессами в Linux — сложный вопрос; вы не можете просто запустить ps и знать, что происходит. Это особенно верно, когда вы имеете дело с программами, которые создают множество идентичных дочерних процессов, например Apache. ps может сообщить, что каждый процесс Apache использует 10 мегабайт памяти, в то время как на самом деле предельная стоимость каждого процесса Apache составляет 1 мегабайт памяти. Эта информация становится критически важной при настройке параметра Apache MaxClients, который определяет, сколько одновременных запросов может обрабатывать ваш сервер.
Это также показывает, что стоит как можно больше придерживаться программного обеспечения для одного рабочего стола. Если вы запускаете KDE для своего рабочего стола, но в основном используете приложения Gnome, вы платите большую цену за множество избыточных (но разных) разделяемых библиотек. Придерживаясь только приложений KDE или Gnome, насколько это возможно, вы сокращаете общее использование памяти за счёт снижения предельных затрат памяти при запуске новых приложений KDE или Gnome, что позволяет Linux использовать больше памяти для других интересных вещей (например, файловый кэш, который значительно ускоряет доступ к файлам).
Так как тогда посчитать, сколько реально памяти занимает процесс в Linux?
С помощью ps или аналогичных инструментов вы получите только количество страниц памяти, выделенных этим процессом. Это правильный номер, но:
В выводе программ обращайте внимание на поля RSS и RES.
RES — используемая оперативная память, является подмножеством VIRT, представляет физическую память, не помещённую в раздел подкачки, которую в текущий момент использует задача.
RSS — это «resident set size» — физическая память без подкачки, которую использовала задача (в килобайтах). Псевдоним rssize, rsz.
Для просмотра фактически используемой памяти попробуйте команду pmap:
Будут выведены поля
Обратите внимание на нижнюю строку начинающуюся с «total kB», это поле RSS.
В команде top ищите поле RES — вы можете сделать сортировку по данному полю, как это показано на скриншоте ниже:
Виртуальная память в Linux не складывается?
Я смотрел системный монитор в Linux и заметил, что Firefox использует 441 МБ памяти, а несколько других приложений используют 274, 257, 232 и т. д. (Добавляя до 3 ГБ виртуальной памяти). Итак, я перехожу на вкладку «Ресурсы», и там говорится, что я использую 462 МБ памяти и не раздел подкачки не задействован. Я в замешательстве. Что означает объем виртуальной памяти, если программы на самом деле её не используют. Я подумал, может быть, память они запросили, но не используют, но как ОС узнает об этом? Я не могу придумать ни одной функции «при котором данным процессам может понадобиться такое огромное количество памяти в будущем».
Во-первых, разделяемая память не совсем правильно подсчитывается методом команды top. Во-вторых, да, программа запрашивает права на память, а затем использует её, но она может никогда не коснуться выделенной ей памяти, и ОС это знает. Нет проблем если между всеми приложениями будет поделена вся доступная память вместе с разделом подкачки, по крайней мере до тех пор, пока они не пытаются всё это использовать.
Распространение памяти: cgroup memory.usage_in_bytes против RSS внутри контейнера докеров
«Кубернетес» (v1.10.2) говорит, что мой блок (который содержит один контейнер) использует около 5 ГБ памяти. Внутри контейнера RSS больше напоминает 681MiB. Может ли anypony объяснить, как получить от 681MiB до 5GB со следующими данными (или описать, как составить разницу с другой командой, которую я пропустил, либо из контейнера, либо из хоста докеров, который работает с этим контейнером в кубернетах)?
kubectl top pods говорит 5GB:
Cadvisor сообщает о том же количестве (возможно, было от немного другого времени, поэтому, пожалуйста, игнорируйте небольшие различия):
Внутри контейнера этот файл, как представляется, содержит информацию о том, где кэдзизор получает свои данные:
Размер резидентного набора (RSS) внутри контейнера НЕ совпадает (менее 1 ГБ):
Полный ps aux в случае, если это полезно:
Раздел памяти из статистики контейнера докеров API:
Total (memory.usage_in_bytes) = rss + cache
usage_in_bytes: Для эффективности, как и другие компоненты ядра, в группе памяти используется определенная оптимизация, чтобы избежать ненужного общего доступа к кешине. use_in_bytes зависит от метода и не показывает «точное» значение использования памяти (и swap), это значение fuzz для эффективного доступа. (Конечно, когда это необходимо, оно синхронизируется.) Если вы хотите узнать более точное использование памяти, вы должны использовать значение RSS + CACHE (+SWAP) в памяти.stat (см. 5.2).
Примечание. В Linux CLI Docker сообщает о потреблении памяти, вычитая использование кэша страниц из общего объема использования памяти. API не выполняет такой расчет, а скорее обеспечивает общее использование памяти и количество из кэша страниц, чтобы клиенты могли использовать данные по мере необходимости.
Информация о памяти от kubectl describe pod
Существует еще один вопрос, подобный этому (но с меньшей информацией) при некорректном сообщении о потреблении памяти контейнера с помощью каддизора. Спасибо!
ОТВЕТЫ
Ответ 1
Похоже, он использует VSZ, Virtual Memory Size, а не RSS. Куберне видит это:
ps внутри контейнера при суммировании 5-го столбца (VSZ), говорит:
VSZ находится в районе 7 ГБ (не соответствует точно, но он близок), тогда как RSS говорит 665 МБ, поэтому это заставляет меня поверить, что Kubernetes и /sys/fs/cgroup/memory/memory.usage_in_bytes используют что-то в соответствии с VSZ, по крайней мере в этом случае.
Ответ 2
Однажды я увидел аналогичную вещь для одного из наших основных приложений.NET, и я не мог понять, что именно происходит (возможно, утечка памяти в ядре.NET, так как это неуправляемая память, которое наше приложение не контролирует).
Возможно, это еще одна сводка для вас. Это будет зависеть от вашего приложения, было ли это использование нормальным или нет, но с точки зрения групп. Я полагаю, что использование памяти ядра по умолчанию не ограничено.