Фактическое использование памяти процесса

Ниже приведены данные об использовании памяти mysqlи apacheсоответственно на моем сервере. Согласно выводу, pmapскажем, mysqlиспользует около 379M и apacheиспользует 277M.

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

Сравнивая это с выводом top, я вижу, что значения почти совпадают.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

Теперь эти значения определенно не являются текущим использованием памяти этими двумя процессами, поскольку, если бы это было так, это превысило бы 512M ramв моей системе, и я понимаю тот факт, что это размер страниц, назначенных этим двум процессам, а не Размер памяти активно используется ими. Теперь, когда мы используем pmap -x, я вижу дополнительную колонку, Dirtyкоторая показывает гораздо меньшее использование памяти для процесса. Как видно из приведенного ниже примера, Dirtyстолбец показывает 15M, а не 379M в первом столбце. Мой вопрос: является ли значение в столбце Dirty«реальным» объемом памяти, активно используемым этим процессом? Если это не так, то как мы можем узнать реальное использование памяти процессом? Нет psи topпо тем же причинам, что и выше. У нас есть что-нибудь под/proc что даст эту информацию?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

Там нет команды, которая дает «фактическое использование памяти процесса», потому что нет такой вещи, как фактическое использование памяти процесса .

Каждая страница памяти процесса может быть (среди других различий):

• Временное хранилище, используемое только этим процессом.
• Совместно с другими процессами используются различные механизмы.
• Резервное копирование файла на диске.
• В физической памяти или подкачке.

Я думаю, что «грязная» фигура складывает все, что находится в оперативной памяти (не подкачки) и не поддерживается файлом. Это включает как разделяемую, так и не разделяемую память (хотя в большинстве случаев, кроме разветвления серверов, разделяемая память состоит только из отображенных в память файлов).

Отображаемая информация pmapпоступает от и . Это реальное использование памяти процессом - его нельзя суммировать одним числом./proc/PID/maps/proc/PID/smaps

Я приведу кое-что, что я написал на странице руководства для приложения, которое выполняет анализ, аналогичный top, и извлекает информацию из тех же источников, что и pmap(например /proc/[N]/maps):

ВИРТУАЛЬНОЕ АДРЕСНОЕ ПРОСТРАНСТВО VS. ФИЗИЧЕСКАЯ ПАМЯТЬ

Важно понимать разницу между виртуальным адресным пространством и физической памятью при интерпретации некоторых из приведенных выше статистических данных. Как следует из названия, виртуальное адресное пространство не реально; это в основном карта всей памяти, выделенной в данный момент процессу. Ограничение на размер этой карты одинаково для каждого процесса (обычно 2-4 ГБ), и оно не накапливается (т. Е. У вас может быть десятки или сотни процессов, каждый из которых имеет собственный виртуальный адрес 2-4 ГБ). пространство, в системе, которая на самом деле имеет только 512 МБ физической памяти ).

Данные не могут быть сохранены или извлечены из виртуального адресного пространства; реальные данные требуют реальной физической памяти. Задача ядра - управлять одним по отношению к другому. Статистика виртуального пространства (VirtualSz, Data + Stack и Priv & Write) полезна для рассмотрения структуры процесса и отношения к использованию физической памяти, но с учетом объема фактически используемой оперативной памяти, статистики физической памяти (ResidentSz, Share и Пропорция) это то, что имеет значение.

pmapв основном сообщает вам информацию о виртуальном адресном пространстве . Ваше наблюдение о том, что «значения практически совпадают» в topвыходных данных, по-видимому, относится к значению VIRT, которое сильно отличается от показателя RES. Это в точности соответствует тому, что я назвал «VirtualSz» и «ResidentSz» (VIRT для виртуальных, RES для резидентов).

Теперь, когда мы используем pmap -x, я вижу дополнительный столбец Dirty, который показывает гораздо меньшее использование памяти для процесса. Как видно из приведенного ниже примера, грязная колонна показывает 15 млн., А не 379 млн. В первой. Мой вопрос: является ли значение в столбце «Грязный» «реальным» объемом памяти, активно используемым этим процессом?

Нет, но вроде. «Грязная» память относится к данным, которые были загружены с диска и впоследствии изменены; поскольку он был изменен, он должен быть частью резидентной памяти, поскольку эти изменения в настоящее время хранятся в оперативной памяти. Однако это не является синонимом этого.

Виртуальная память похожа на номера быстрого набора, за исключением того, что их около 3 миллиардов (для 32-битной системы, 4 миллиарда для 32-битного приложения на 64-битном ядре, и многое другое для 64-битного приложения), и вы не можете набирать номера напрямую, быть сопоставленным с быстрым набором.

Несколько процессов могут иметь разные сопоставления (номера быстрого набора) для одного и того же адреса (номера телефонов). Например, они могут совместно использовать несколько библиотек, поэтому имейте виртуальные адреса для всей библиотеки (вы можете увидеть это в pmap). Они могут даже использовать один и тот же исполняемый файл, например, 2 экземпляра bash.

Пока что это объясняет, как может подходить подпункт всех виртуальных адресов, но это еще не все. У одного процесса может быть столько виртуальной памяти, что он не должен умещаться, как? Некоторые части библиотеки или исполняемый файл могут не использоваться, они не будут скопированы с диска в оперативную память, или оперативная память заполняется, и биты, загруженные с диска, сбрасываются, поскольку при необходимости их можно извлечь с диска, или память, для которой нет резервных копий, мой диск сопоставлен для замены, скопирован для замены и затем удален. Затем он может быть прочитан из свопа, если и когда это необходимо. Если какой-либо из этих последних стратегий используется слишком много, то система становится медленной.