Прежде всего, программы / процессы не "кушают" память. Они используют или выделяются памяти.
VSZ (размер виртуальной памяти в килобайтах) - это сумма всей виртуальной памяти, требуемой процессом. Этот размер является в первую очередь атрибутом процесса / программы, а не под контролем ОС.
RSS - это размер резидентного набора, который представляет собой объем физической памяти, выделенной для процесса. Это физическая память, используемая для хранения страниц виртуальной памяти, которые являются резидентными (а не расположены в резервном хранилище, т.е. выгружены) во время выполнения процесса. RSS будет меньше или равен размеру виртуальной памяти процесса.
Обратите внимание, что иногда RSS сообщается как число страниц (которое обычно имеет размер 4096 байт), а не в килобайтах. Поэтому в таких ситуациях сравнивать VSZ с RSS неуместно.
Обратите внимание, что оба этих размера для процесса могут включать в себя общие библиотеки, а также память для кода / текста, данных, кучи и стека. Операционная система должна планировать процессы и определять, какие страницы процесса остаются резидентными в (физической) памяти, а какие выгружаются. Общие библиотеки с большей вероятностью будут оставаться резидентными, чем страницы, используемые исключительно процессом. Процесс в спящем состоянии (например, STAT == D1 или STAT == S1) может выгружать большинство своих страниц и иметь небольшой RSS. Все под контролем ОС и динамики выполнения процесса.
Также обратите внимание, что Linux отличается от большинства других * nixes тем, что Linux (если не настроено иначе) будет перезапускать запросы на (виртуальную) память. Таким образом, даже если для процесса не выделены ни страницы, ни пространство подкачки (пока процесс не попытается получить доступ к этой "выделенной" памяти), его VSS может увеличиться.
Приложение: ответ на комментарий
почему разница такая огромная? иногда VSZ в 20 раз больше RSS, даже в системе без обмена.
Вы приводите конкретный пример без каких-либо подробностей.
Функция чрезмерной загрузки в Linux может стать фактором значительного расхождения между VSZ и RSS, если нет обмена. Эта программа выполняет malloc() больших, но неиспользуемых буферов?
Возможно, вам придется оценить использование памяти этим процессом самостоятельно, используя такие инструменты памяти, как pmap и top , которые предоставят немного больше деталей.
Смотрите "Runtime_Memory_Measurement" для получения дополнительной информации. top документация заявляет, что
SWAP -- Swapped size (kb)
The swapped out portion of a task's total virtual memory image.
RES -- Resident size (kb)
The non-swapped physical memory a task has used.
RES = CODE + DATA.
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.
VIRT = SWAP + RES
Я не знаю, должны ли эти top определения учитывать виртуальную память, которая была выделена, но еще не распределена по физическим ресурсам. Я думаю, что это так, но уравнение VIRT было упрощено, исключив (необычную) ситуацию с выделением, но еще не распределенной виртуальной памяти.
Приложение 2: ответ на комментарий
Может быть, попробуйте запустить top или htop на своем компьютере, вы увидите, что есть ряд процессов, которые используют значительное количество VSZ и почти не RSS
Не увидел ничего интересного в моей системе Ubuntu:
PID PR NI VIRT RES SHR S %CPU %MEM SWAP CODE DATA nDRT COMMAND
26379 20 0 20812 7996 3496 S 4 0.4 12m 4 2828 0 gs
1082 20 0 85292 46m 15m S 2 2.5 36m 1660 30m 0 Xorg
2036 20 0 22948 8756 7148 S 1 0.4 13m 40 788 0 multiload-apple
2411 20 0 47984 19m 10m S 1 1.0 27m 1924 7584 0 python
62 20 0 0 0 0 S 0 0.0 0 0 0 0 kondemand/0
930 20 0 3236 1528 792 S 0 0.1 1708 284 820 0 dbus-daemon
1618 20 0 6964 3084 2244 S 0 0.2 3880 420 836 0 cupsd
1971 20 0 15708 3100 2484 S 0 0.2 12m 216 10m 0 udisks-daemon
2037 20 0 39316 11m 9676 S 0 0.6 26m 76 1404 0 sensors-applet
25733 20 0 2568 1280 956 R 0 0.1 1288 64 480 0 top
2473 20 0 6712 4060 1564 S 0 0.2 2652 780 2492 0 bash
Для всех пользовательских процессов VIRT == SWAP + RES было истинным, а RES == CODE + DATA - нет.
У меня есть несколько SBCS под управлением Embedded Linux, но не имеют top поперечного скомпилирован для них. Глядя на /proc/<pid>/stat для процесса оболочки, есть VSZ = 580 КБ и RSS = 200 КБ (на самом деле 50 страниц), но, конечно, /proc/meminfo сообщает о нулевых байтах для подкачки. Может быть, получить top запуск на этом SBC может быть интересно (так как я не знаю, где top получает свои номера для обмена).
