Linux ps vsz rss

Что такое RSS и VSZ в управлении памятью Linux

Что такое RSS и VSZ в управлении памятью Linux? В многопоточной среде, как можно управлять и отслеживать обе эти функции?

RSS — это размер резидентного набора и используется, чтобы показать, сколько памяти выделено этому процессу и находится в оперативной памяти. Он не включает память, которая выгружается. Он включает память из общих библиотек, пока страницы из этих библиотек фактически находятся в памяти. Он включает в себя всю память стека и кучи.

VSZ — это размер виртуальной памяти. Он включает в себя всю память, к которой может обращаться процесс, включая память, которая выгружается, память, которая выделена, но не используется, и память из общих библиотек.

Таким образом, если процесс A имеет двоичный файл размером 500 КБ и связан с 2500 КБ совместно используемых библиотек, имеет 200 КБ выделенных стеков / кучи, из которых 100 КБ фактически находится в памяти (остальная часть поменялась местами или не используется), и он фактически загрузил только 1000 КБ совместно используемых библиотек. и 400K своего двоичного файла:

Поскольку часть памяти является общей, многие процессы могут использовать ее, поэтому, если вы сложите все значения RSS, вы легко сможете получить больше места, чем в вашей системе.

Память, которая выделяется, также может отсутствовать в RSS, пока она не будет фактически использована программой. Поэтому, если ваша программа выделяет кучу памяти заранее, а затем использует ее со временем, вы можете увидеть, что RSS растет, а VSZ остается прежним.

Существует также PSS (пропорциональный размер набора). Это более новая мера, которая отслеживает общую память как пропорцию, используемую текущим процессом. Так что, если раньше было два процесса, использующих одну и ту же общую библиотеку:

Все потоки имеют одинаковое адресное пространство, поэтому RSS, VSZ и PSS для каждого потока идентичны всем другим потокам в процессе. Используйте ps или top для просмотра этой информации в linux / unix.

Существует гораздо больше, чем это, чтобы узнать больше, проверьте следующие ссылки:

Источник

UNIX: top и ps — VIRT, RES, SHR и SWAP память

VIRT (Virtual memory) — отображает общий объём памяти, который может использоваться процессом в данный момент. Включает в себя реально используемую память, другую память (например — память видеокарты), файлы на диске, загруженные в память (например — файлы библиотек), и память, совместно используемую с другими процессами ( SHR или Shared memory ). Она же отображается как VSZ в результатах ps (Process status) .

RES (Resident memory size) — отображает, сколько физической памяти занято процессом (используется для отображения в колонке %MEM в top -е). Она же отображается как RSS в результатах ps (Process status) .

SHR (Shared Memory size) — отображает объём VIRT памяти, который используется процессом совместно с другими процессами, например — файлы библиотек.

SWAP (Swapped size) — память, которая в данный момент не используется (не- RES ), но доступна процессу, при этом она «выгружена» в swap -раздел диска.

o: VIRT — Virtual Image (kb)
The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out. (Note: you can define the STATSIZE=1 environment variable and
the VIRT will be calculated from the /proc/#/state VmSize field.)

p: SWAP — Swapped size (kb)
Per-process swap values are now taken from /proc/#/status VmSwap field.

q: RES — Resident size (kb)
The non-swapped physical memory a task has used.

VSZ (VSS) — Virtual Size in Kbytes (alias vsize) или Virtual memory — особый уровень абстракции «над» архитектурой физической памяти.

Каждый процесс получает в использование виртуальное адресное пространство, и при обращении к адресу в нём — адрес сначала конвертируется в адрес физической памяти (main memory — MM , она же RAM) при помощи Memory Management Unit (MMU) . Данные в виртуальном адресном пространстве могут располагаться в основной памяти, на диске (в swap -файле), сразу в обоих местах или на какой-то внешней памяти (например — памяти видеокарты). Однако, как только процесс запрашивает какие-то данные, которые в настоящий момент не находятся в основной памяти системы — они туда загружаются. Таким образом, процесс не считывает данные напрямую с диска ( memory mapping ), но некоторые или все его ресурсы могут находится на «внешней памяти» в любое время, а его страницы памяти могут быть выгружены в swap, что бы освободить память для других процессов.

RSS — Resident Set Size — количество выеделенной процессу физической ( MM ) памяти в настоящий момент. Это физическая память, которая используется для рамзмещения страниц виртуальной памяти ( virtual memory pages ), которая используется процессом постоянно. RSS всегда будет менее или равна памяти VSZ.

Вообще это очень большая тема, потому — несколько ссылок:

Источник

Перевыделение памяти в Linux и admin_reserve_kbytes

Перевыделение (overcommitting) оперативной памяти в Linux, особенно на рабочих серверах, является величайшим Злом, и это Зло в Linux разрешено по-умолчанию — vm.overcommit_memory=0

По-умолчанию ( vm.overcommit_memory=0 ) Linux выделяет памяти больше чем есть в наличии, при этом используется эвристический анализ определения выделяемой процессу памяти. Т.е. выделяя оперативки больше чем есть, Linux ещё дополнительно расходует ценные системные ресурсы на эвристику, которая не во всех случаях может давать положительный результат. Эвристический анализ — это, как пальцем в небо.

Более того, наличие возможности перевыделить памяти поощряет говнокодеров говнокодить кривые приложения в стиле » хуяк-хуяк и в продакшин » без реализации кода для надлежащей утилизации неиспользуемой приложением памяти.

Кому сложно понять что такое перевыделение памяти, то для сравнения можно привести пример с продажей билетов, скажем в кино. К примеру, в кинотеатре всего 100 мест, а мы продали 1000 в надежде, что не все купившие билеты дойдут до кинотеатра и востребуют свои места. Но, » сталося не так як гадалося «:

• 100 первых пришедших в кино заняли все доступные места;
• 100 по дороге е.анулось, ещё 100 обо.ралось, и до кинотеатра не дошло (ура товарищи);
• 700 оставшихся таки дошли до кинотеатра, но понятно, что мест им не осталось, в гневе они в хлам развалили тот кинотеатр, и в конечном итоге кина не досталось никому.

Дабы подобного беспредела не происходило на Linux сервере мы обязательно должны ограничить рамки перевыделения памяти, что дополнительно избавит от необходимости тратить ресурсы на эвристику, например:

Обычно, относительно «вменяемые» приложения при запуске запрашивают не более чем в 3 раза больше памяти, чем им реально требуется, а значит vm.overcommit_ratio=300 должно быть вполне достаточно в большинстве случаев. При таком раскладе будет доступно оперативки: РАМ * (overcommit_ratio/100) + SWAP. Скажем, у нас РАМ 2048 МБ и СВОП 5120, тогда получим: 2048 * 3 + 5120 = 11264 МБ около того.

vm.overcommit_memory=2 полезно даже в тех случаях, когда в системе работают более-менее «вменяемые» и проверенные приложения, — ведь не факт, что они всегда будут работать стабильно. Ведь даже самые проверенные и надёжные приложения (как и люди) время от времени, по различным причинам, могут сойти с ума начав «форкать чилдов» и запрашивать всё новые и новые порции памяти (перенаселение, голодовка, и песдец).

vm.overcommit_memory=2 совместно с vm.overcommit_ratio=300 определяет границы реальных возможностей системы виртуальной памяти, а OOM killer (OOM: out-of-memory) в свою очередь прибивая пизданутые процессы и/или их чилдов помогает остальным процессам пребывать в равновесии с системными ресурсами.

1. Пусть земное население никогда не превышает 500.000.000, пребывая в постоянном равновесии с природой
2. Разумно регулируйте рождаемость, повышая ценность жизненной подготовки и многообразия человечества
3. Найдите новый живой язык, способный объединить человечество.
4. Проявляйте терпимость в вопросах чувств, веры, традиций и им подобных
5. Пусть справедливые законы и беспристрастный суд встанут на защиту народов и наций
6. Пусть каждая нация сама решает свои внутренние дела, вынося на мировой суд общенародные проблемы.
7. Избегайте мелочных судебных тяжб и бесполезных чиновников.
8. Поддерживайте равновесие между личными правами и общественными обязанностями.
9. Превыше всего цените правду, красоту, любовь, стремясь к гармонии с бесконечностью.
10. Не будьте раковой опухолью для земли, природе тоже оставьте место!

При vm.overcommit_memory=1 система считает, что в наличии неограниченное количество памяти и выделяет её без ограничений до тех пор пока она вся реально не закончится.

Когда vm.overcommit_memory=2 (overcommit ‘never’) нам нужно изменить значение по-умолчанию admin_reserve_kbytes , для определения которого нужно понимать смысл аббревиатур VSZ и RSS.

VSZ and RSS Linux memory

Что такое VSZ и RSS? Ответ нам даст man ps : VSZ — virtual memory size; RSS — resident set size, the non-swapped physical memory that a task has used (in kiloBytes) .

• VSZ — виртуально выделенная память, но не означает, что вся она используется. Кто в теме, тот в курсе, что Linux на запрос приложения перевыделяет (overcommitting) памяти больше, чем есть в наличии — прямо как американцы печатают баксов больше, чем фактически обеспечено золотовалютным резервом;
• RSS — фактически занимаемый в данный момент размер оперативки без учёта страниц перемещённых в swap.

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 и с чем его едят

cap_sys_admin — это флаг определяющий набор административных возможностей (capabilities) приложения/программы/пользователя. Подробнее в man capabilities

Отобразить список процессов и назначенный им список capabilities-флагов можно с помощью pscap из пакета libcap-ng-utils :

Как распределяется admin_reserve_kbytes

Ответ: а хрен его знает, документация по данному флагу об этом умалчивает.

В сети куча постов с копи/пастой мнения, что увеличив значение admin_reserve_kbytes мы уже якобы «гарантируем» себе возможность логина в вот-вот зависающей машине, — для пользователя root возможно, но для остальных не факт!

Давайте «погульчитаем» документацию по admin_reserve_kbytes где говорится, что:

1. » The amount of free memory in the system that should be reserved for users with the capability cap_sys_admin. «, — резервируется размер свободной оперативки для пользователей с возможностями cap_sys_admin .
2. » How do you calculate a minimum useful reserve? sshd or login + bash (or some other shell) + top (or ps, kill, etc.) . For overcommit ‘never’, we can take the max of their virtual sizes (VSZ) and add the sum of their RSS. » — если перевыделение памяти запрещено (overcommit ‘never’), то значение должно составлять сумму VSZ + RSS, очевидно всех процессов запущенных системой под такого пользователя и им самим же, которому присвоен флаг cap_sys_admin .

Замечено, что на процессы запускаемые от root-a через systemd эта самая зарезервированная в размере admin_reserve_kbytes оперативка не выделяется, а просто себе болтается без дела, и в этом можно убедится опытным путём.

Опыт №1

Ручками сложить сумму VSZ (ака VmSize) + RSS (ака VmRSS) всех процессов из списка pscap|less по каждому отельному /proc/PID/status будет довольно геморно, и поэтому давайте «наговнокодим» баш-скрипт автоматизирующий всю эту работу (назовём его ./vsz-total.sh):

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Запустив скрипт получим сумму значений VmSize и VmRSS всех процессов выданных прогой pscap :

Из результата видим, что рекомендуемое значение для admin_reserve_kbytes основанное на «VSZ + RSS» в данном случае составило 2166444 kB.

Увы, документация не уточняет какая именно » amount of free memory » резервируется параметром admin_reserve_kbytes = это от суммы СВОПа+РАМы или от одной РАМы? Вероятнее всего, от суммы СВОПа+РАМы.

Кроме того, сказано, что: » Changing this takes effect whenever an application requests memory. «, — изменения вступают в силу, когда приложения запрашивают память.

Потому, как все системные процессы из списка pscap уже запросили память при запуске и она была им выделена, то в условиях:

Когда до достижения ограничения CommitLimit у нас осталось около 4,5 ГБ, мы выполним рекомендацию документации sysctl -w vm.admin_reserve_kbytes=2166444 (зарезервируем 2+ ГБ) и попробуем запустить Chromium, который при запуске перевыделяет 3+ ГБ — т.е. минимум на 0,5 превышаем допустимый CommitLimit, и получаем:

Вернув же sysctl -w vm.admin_reserve_kbytes=262144 обратно к 256 МБ браузер успешно запущен и занял Committed_AS более 9хххххх kB (почти до 10 ГБ).

Теперь пишем данное значение vm.admin_reserve_kbytes=2166444 в /etc/sysctl.conf , но не применяем его, а закрываем все приложения и перезагружаем машину.

Опыт №2

Теперь, после перезагрузки, все процессы, запущенные от имени пользователя root , а он имеет неограниченные права и все флаги возможностей включая cap_sys_admin ( reserved for users with the capability cap_sys_admin ) , казалось должы были бы использовать большую часть admin_reserve_kbytes и «болтающейся» без дела памяти у нас быть не должно.

Однако, запуская все те же процессы, что были до перезагрузки, среди которых был и браузер palemoon :

На значении чуть выше 8128504 кб браузер был «забит» и перед смертью выдал » fork(): Невозможно выделить память «. Аналогичный результат можно получить при попытке запуска хрона:

Вернув же sysctl -w vm.admin_reserve_kbytes=262144 обратно к 256 МБ браузер успешно запущен и занял Committed_AS более 9хххххх kB (почти до 10 ГБ).

Итоги опытов

В итоге опытным путём мы убедились, что на процессы запускаемые от имени root через systemd зарезервированная память из admin_reserve_kbytes не выделяется, а просто себе болтается без дела как до, так и после перезагрузки.

Вероятно выделение памяти из admin_reserve_kbytes для пользователей с флагом cap_sys_admin происходит при интерактивном взаимодействии с машиной, например при авторизации по SSH/SU и т.п.

Как дать пользователю возможности cap_sys_admin

cap_sys_admin для su-пользователей CentOS 6/7

Далее подключаем PAM-модуль (Pluggable Authentication Modules) pam_cap.so . ВНИМАНИЕ! Строка подключения pam_cap.so должна быть перед строкой подключения pam_rootok.so !

Авторизируемся с помощью su , проверяем capabilities для текущего пользователя:

Значение для admin_reserve_kbytes

Отметим, что многие описания параметров в документации ядра не только являются не полными, но даже вводят в заблуждение, вот например: » admin_reserve_kbytes defaults to min(3% of free pages, 8MB) «, — 3% от свободных страниц, не объёма, а именно страниц (4 кб страница)? А, что это за 8MB?

Значение admin_reserve_kbytes по-умолчанию

Вот, пожалуйста, не у одного меня возник подобный вопрос на данную тему:

Во время загрузки ядра — когда подсистема MM инициализируется — она вычисляет 3% оставшейся свободной памяти. Если это больше, чем 8 МБ, значение устанавливается на 8 МБ.

» Если это больше, чем 8 МБ, значение устанавливается на 8 МБ. «, — да хрен там. На машине с Debian Stretch где » MemTotal: 2059828 kB » (без свопа) «default value of the admin_reserve_kbytes» составляло около 6х МБ, что таки да соответствует тем самым 3% от MemTotal: 2059828 kB / 100 * 3 = 61794,84.

На машине с 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 по-умолчанию и зависит от реализации функции init_admin_reserve(void) , а также иных функций ею вызываемых global_zone_page_state(NR_FREE_PAGES) и т.п.: https://elixir.bootlin.com/linux/v5.0/source/mm/mmap.c#L3666

Таким образом, admin_reserve_kbytes:

• defaults = как-то в расброс. То, 3% от RAM (без учёта свопа), то 8MB, а бывает и 7616 кб (Ой как бывает! Всё так зыбко и условно: https://www.youtube.com/watch?v=Ta4G51ZMZRM).

Если значение не указано явно, то admin_reserve_kbytes по-умолчанию может быть равно 3% (без учёта пространства подкачки страниц), и как видим не факт, что 8 МБ будет минимумом даже если 3% до 8 МБ не дотягивает, — короче, как повезёт. Если не хочется гадать, установи его явно.

Оптимальное значение для admin_reserve_kbytes

Если у нас нет удалённого доступа к нашей машине и соответственно пользователей с cap_sys_admin , vm.overcommit_memory = 2 , то вполне будет достаточно символического 1 кб sysctl -w vm.admin_reserve_kbytes=1 , — проверено, с таким значением ничто не загнулось, не взорвалось, ничего страшного не произошло.

А для нахождения оптимального значения admin_reserve_kbytes на удалённом сервере смотрим VmSize (virtual memory size: man proc ) + VmRSS из /proc/PID/status , для всех основных программ с которыми мы удалённо будем работать, например:

В случае overcommit_memory=2 , сложив размер VmSize + VmRSS для базовых процессов (sshd/screen/bash) обеспечивающих удалённое взаимодествие с сервером — получим не менее 125-256 МБ, а то и все 512 МБ от общей (ака CommitLimit) системной (РАМ + СВОП + (RAM * overcommit_ratio / 100)) памяти (считать всё в kB разумеется, в МБ указано для удобства).

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 просто завершает задачу, которая вызвала состояние нехватки памяти. Это позволяет избежать дорогостоящего сканирования списка задач.

Здесь описание параметра совпадает с реальным его поведением. Если, допустим, у нас из » CommitLimit: 10635924 kB » занято » Committed_AS: 7450192 kB «, и мы запустим процесс требующий более 3 ГБ, например Chromium, то OOM killer не обязательно грохнет сам Chromium, который собственно и вызвал «out-of-memory condition«, а может выбрать процесс из списка уже работающих, — таким процессом для OOM killer-а оказался другой уже работающий веб-браузер Pale Moon, который занимал до 2 ГБ, в котором на тот момент было открыто много полезных страниц с несохранёнными данными. Т.е., при vm.oom_kill_allocating_task=0 делается упор на освобождение памяти от уже работающих процессов вугоду только что запущенных.

vm.oom_kill_allocating_task=1 заставит OOM killer-а тупо мочить любые процессы, которые стали причиной » out-of-memory condition «, — этот вариаинт выбираю потому, что не хочу жертвовать уже работающими процессами. Данный вариант также должен гарантировать прибивание из уже работающих только «психанутых» процессов (вслучай чего с ними станется) вызвавших «out-of-memory condition», вместо наоборот завалить текстовый редактор с несохранёнными данными во благо свихнувшемуся php-cgi например.

Рекомендуемый контент

А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net

Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).

Источник