Как сообщается об использовании памяти в Linux?


17

Используя ps, я могу видеть размер, vsize (такой же, как у VIRT вершины?) И rss (такой же, как у RES у вершины?). (Еще одна, которую я вижу сверху - это SHR.)

Может ли кто-то резюмировать для меня, что означают эти разные области?


Я предпочел бы увидеть хорошее резюме на этой странице, чем ссылку, которая может исчезнуть, чтобы эта страница могла использоваться в качестве ссылки.
Джим Хунзикер

Ответы:


34

Короче говоря:

  • Виртуальный размер: это объем адресного пространства, которым управляет процесс. Виртуальное адресное пространство содержит все, к чему процесс может получить доступ через указатели (ссылки на адреса в памяти). Например, если ваша программа получает доступ к кадровому буферу вашей видеокарты, эта память сопоставляется с виртуальным пространством процесса и получает адрес, который хранится в указателе. Отображенные в память файлы и анонимные сопоставления также учитываются в размере виртуального адресного пространства. Практически все в виртуальном размере. Если вы суммируете размер всех диапазонов адресов, перечисленных в /proc/<pid>/maps, он должен вернуть вам примерно одинаковое значение виртуального размера.

  • Резидентный размер: это объем памяти, который принадлежит именно тому процессу, который в данный момент находится в памяти. Это означает, что объем памяти, который не находится в разделе подкачки. Обратите внимание, что части процесса могут находиться в памяти подкачки, даже когда процесс запущен. Операционная система извлечет эти области из раздела подкачки, когда процесс попытается получить к нему доступ. Это должно включать в себя кучу, стеки всех потоков и другие частные отображения. Если вы посмотрите /proc/<pid>/maps, то [stack], [heap]и другие анонимные отображения (те без путей к файлам), либо заменены или учитываются в резидентном.

  • Общий размер: объем памяти, который может принадлежать нескольким процессам. Например, если в память загружено четыре экземпляра одного и того же приложения, у вас будет четыре экземпляра кучи и как минимум четыре стека, по одному для каждого процесса (это резидентная память), но у вас будет только один экземпляр двоичный код программы и ее библиотек. Это общее пространство. Он включает в себя не только двоичный код программы и ее библиотеки, но также файлы локализации, программные данные только для чтения, сегменты разделяемой памяти SysV и POSIX, семафоры и т. Д. Если вы посмотрите /proc/<pid>/maps, большинство отображений, связанных с файлами библиотеки и программы, общий.

Обратите внимание, что VIRT содержит объединение RSS и SHR и всегда будет больше, чем любой из них. Там могут быть регионы, которые учитываются как RSS и SHR.


2
Кстати, в последних версиях linux вы можете увидеть очень подробную разбивку использования памяти в / proc / <pid> / smaps
bdonlan

1
Общий размер памяти , который может быть общим. Если приложение является единственным пользователем библиотеки, библиотека будет храниться в памяти одним процессом. Таким образом, даже совместно используемая память может быть «принадлежащей процессу» памятью.
Хьюберт Карио

6

На Джулиано отвечу:

Обратите внимание, что RSS + SHR <= VIRT, всегда.

Это просто ложь. SHR содержит всю виртуальную память, которая может использоваться другими процессами, а RSS содержит всю физическую память в оперативной памяти, которая используется процессом.

Таким образом, вся разделяемая память, находящаяся в настоящее время в ОЗУ, подсчитывается как в SHR, так и в RSS, поэтому SHR + RSS не имеет смысла, поскольку может содержать количество дубликатов.

Чтобы создать процесс с RSS + SHR> VIRT, просто отобразите большой файл (1 ГБ), а затем полностью его прочитайте: файл mmaped будет загружен в ОЗУ, а VIRT, SHR и RSS будут чуть больше 1 ГБ, поэтому SHR + RSS> VIRT.


Да, это было скорее заявление о VIRT, чем два других. Я имел в виду скорее объединение RSS и SHR, чем их сумму, то есть VIRT содержит как RSS, так и SHR. Плохое математическое представление.
Джулиано
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.