Для чего используется память Linux? Низкий кэш, низкий буфер, а не виртуальная машина

Question

Прежде всего, да, я прочитал LinuxAteMyRAM, который не объясняет мою ситуацию.

# free -tm
             total       used       free     shared    buffers     cached
Mem:         48149      43948       4200          0          4         75
-/+ buffers/cache:      43868       4280
Swap:        38287          0      38287
Total:       86436      43948      42488
#

Как показано выше, строка -/+ buffers/cache: указывает на то, что используемая память очень высока. Однако из вывода top я не вижу ни одного процесса, использующего более 100 МБ памяти.

Итак, что использовала память?

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28078 root      18   0  327m  92m  10m S    0  0.2   0:25.06 java
31416 root      16   0  250m  28m  20m S    0  0.1  25:54.59 ResourceMonitor
21598 root     -98   0 26552  25m 8316 S    0  0.1  80:49.54 had
24580 root      16   0 24152  10m  760 S    0  0.0   1:25.87 rsyncd
 4956 root      16   0 62588  10m 3132 S    0  0.0  12:36.54 vxconfigd
26703 root      16   0  139m 7120 2900 S    1  0.0   4359:39 hrmonitor
21873 root      15   0 18764 4684 2152 S    0  0.0  30:07.56 MountAgent
21883 root      15   0 13736 4280 2172 S    0  0.0  25:25.09 SybaseAgent
21878 root      15   0 18548 4172 2000 S    0  0.0  52:33.46 NICAgent
21887 root      15   0 12660 4056 2168 S    0  0.0  25:07.80 SybaseBkAgent
17798 root      25   0 10652 4048 1160 S    0  0.0   0:00.04 vxconfigbackupd

Это машина x86_64 (не сервер общего бренда) под управлением Linux x84_64, а не контейнер на виртуальной машине. Ядро (uname -a):

Linux 2.6.16.60-0.99.1-smp #1 SMP Fri Oct 12 14:24:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Содержимое /proc/meminfo:

MemTotal:     49304856 kB
MemFree:       4066708 kB
Buffers:         35688 kB
Cached:         132588 kB
SwapCached:          0 kB
Active:       26536644 kB
Inactive:     17296272 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     49304856 kB
LowFree:       4066708 kB
SwapTotal:    39206624 kB
SwapFree:     39206528 kB
Dirty:             200 kB
Writeback:           0 kB
AnonPages:      249592 kB
Mapped:          52712 kB
Slab:          1049464 kB
CommitLimit:  63859052 kB
Committed_AS:   659384 kB
PageTables:       3412 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    478420 kB
VmallocChunk: 34359259695 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

df сообщает об отсутствии большого потребления памяти файловыми системами tmpfs .

Answer 1

Память в Linux может быть странным зверьком для диагностики и понимания.

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

Процесс в Linux имеет свое собственное виртуальное адресное пространство (VIRT в выводе top). Он содержит все данные, связанные с процессом, и может рассматриваться как "большой" процесс. Однако редко, чтобы вся эта память была активной частью "реальной" карты памяти (RES в выводе top). RES, или резидентная память, - это данные, которые непосредственно доступны в RAM в данный момент времени. Кроме того, есть еще общая память (SHR). Это может быть разделено между несколькими экземплярами одного и того же процесса. Таким образом, память, используемая процессом, находится в любой момент времени RES плюс SHR, но если существует более одного экземпляра процесса, использующего общую память, используется RES плюс RES плюс RES ... плюс SHR.

Так почему же разница между RES и VIRT? Конечно, если у процесса есть блок выделенной памяти, он выделяет память, не так ли? Нет. Память распределяется по страницам, и страницы могут быть активными или неактивными. Активные - это то, что есть в RES. Неактивны "остальные". Их можно отодвинуть в сторону, так как в данный момент к ним нет доступа. Это означает, что они могут быть выгружены на диск, если объем памяти ограничен. Но они не просто идут прямо на диск. Сначала они сидят в тайнике. Вы не хотите постоянно менять местами, поэтому между приложением и пространством подкачки есть буфер. Эти буферы постоянно меняются, так как подкачка выбирает другой процесс для выполнения, и разные страницы становятся активными и неактивными. И все, что происходит, это способ поститься за простого человека, чтобы не отставать.

И вдобавок ко всему, что есть дисковые буферы. Мало того, что неактивная память попадает в кэш, но когда этот кэш перезаписывается на диск, он сначала попадает в дисковый буфер, который ставится в очередь для записи. Так что это второй слой кеша в миксе. И эти дисковые буферы также используются другими частями системы для общей буферизации ввода-вывода. Так что они тоже постоянно меняются.

То, что вы видите в таких вещах, как top free т.д., - это мгновенные снимки текущего состояния машины или агрегированная статистика за определенный период времени. К тому времени, как вы прочитали данные, они устарели.

Любой процесс может получить доступ к большим объемам памяти, но это редко бывает разумным. В любом случае он не может получить доступ ко всей памяти одновременно, поэтому память, на которую она в данный момент не смотрит, перемещается в кэш, если только она не помечена как "заблокированная в ядре".

Таким образом, объем памяти, "используемой" приложением, и объем памяти, который он "имеет" - это две совершенно разные вещи. Большая часть пространства данных приложений на самом деле находится в кеше, а не в "основной" памяти, но, поскольку кеш находится в оперативной памяти, большую часть времени он мгновенно доступен и просто нуждается в "активации", чтобы стать "основной" памятью. Это происходит, если только он не был выгружен на диск, а затем требуется его сброс (что может быть быстрым, если он находится в буфере).

Из-за высокой скорости зверя и того факта, что цифры постоянно меняются, числа могут даже частично меняться, вычисляя, что они из себя представляют, поэтому невозможно точно сказать, "сколько памяти используется" из точка зрения пользователя. Meminfo - это моментальный снимок времени, предоставляемый ядром, но поскольку это ядро выполняет, то оно не обязательно показывает реальное состояние использования памяти каким-либо одним процессом, так как ни один процесс активно не выполняется в это время - он находится между процессами.

Как я уже сказал, все это очень запутанно.

Но в конце дня это действительно не имеет значения. Важно не то, сколько памяти у вас "свободно", а сколько места подкачки вы использовали, и как часто к нему обращаются. Это перестановка, которая замедляет работу системы, а не недостаток памяти (хотя недостаток памяти приводит к избыточной перестановке). Если у вас много используемой памяти, но вы не используете (или очень мало) пространство подкачки, тогда все нормально. Свободная память в целом нежелательна, и в любом случае она часто носит чисто переходный характер, поскольку она использовалась для одной цели, но еще не была выделена для другой - например, это была кэш-память, и она была перенесена на диск, но он еще не использовался ни для чего другого, или это были дисковые буферы, буферы были сброшены на диск, но ни одно приложение еще не запрашивало его для кэширования.

Answer 2

Это одна часть ответа:

Существует разница между тем, что обозначено как "Используемая" память (в команде "free") и «Память, выделенная активным (пользовательским) процессам» (в /proc /meminfo). Итак, ваша система имеет 48149 МБ всего (около 47 ГБ)

Если вы посмотрите на /proc /meminfo, то увидите: Неактивно: 17296272 КБ = (около 16,5 ГБ) - Неактивная память может быть от процессов, которые были прерваны. Это также может быть память, которая долгое время не использовалась активным процессом. Память не "освобождается" только потому, что процесс завершен. Зачем? потому что это больше работы. Та же страница памяти может быть использована снова, поэтому ядро Linux просто оставляет данные в "неактивном" списке до тех пор, пока процесс не понадобится.

Эта страница объясняет кое-что из этого. http://careers.directi.com/display/tu/Understanding+and+optimizing+Memory+utilization ; Прочтите раздел о PFRA(алгоритм восстановления фрейма страницы), используемый ядром Linux: «Страницы, включенные в кэш-память диска и памяти, на которые не ссылается ни один процесс, должны быть восстановлены до того, как страницы, принадлежащие адресным пространствам процессов пользователя», "Восстановление" означает перемещение их из "использованных" (неактивных + активных) в "свободные".

Это объясняет управление памятью более подробно: как работают активные и неактивные списки и как страницы перемещаются между ними https://www.cs.columbia.edu/~smb/classes/s06-4118/l19.pdf

Я полагаю, что есть также память, используемая ядром для структур данных, и что это проявляется как "slab 1049464 kb" (~ 1 ГБ), я полагаю, но я не уверен, что это подсчитывается отдельно.

Answer 3

Вы вообще используете NFS?
Возможно, стоит запустить slabtop -o любом случае, nfs_inode_cache может выйти из-под контроля.

Answer 4

Показатель, на который вы должны смотреть, использует swap, в вашем выводе, который равен "0", что означает, что вы НЕ исчерпали RAM. Пока ваша система не меняет память, вам не следует беспокоиться о других цифрах, которые в любом случае очень трудно интерпретировать.

Изменить: Хорошо, кажется, мой ответ считается загадочным, а не кратким. Итак, позвольте мне уточнить.

Я предполагаю, что основная проблема здесь заключается в интерпретации вывода top/ps, что не очень точно. Например, так как многократное использование одних и тех же общих библиотек не рассчитывается, как вы ожидаете, см., Например, http://virtualthreads.blogspot.ch/2006/02/understanding-memory-usage-on-linux.html.

Однако, что является абсолютно точным, так это то, что если размер подкачки равен нулю, то вашей системе не хватило памяти (пока). Конечно, это очень правильное утверждение, но для профилирования фактического использования памяти в ваших системах top не будет правильным решением. (И если вы посмотрите вверху, по крайней мере, отсортируйте вывод по virt или% mem.)

Смотрите также http://elinux.org/Runtime_Memory_Measurement