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

11

Прежде всего, да, я прочитал 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файловых систем.

linux memory Джейсон
источник
2
Какой выход ps -eo pid,user,args,pmem --sort pmem?
Брайам
Вставил сюда ссылку , попробовал несколько раз, получил такой же вывод.
Джейсон
3
Не используйте head! Я хочу полный вывод всей команды. Если бы я хотел, чтобы вы использовали, headя бы поставил это в мою команду. Пожалуйста, всегда предоставляйте полный вывод команды, которую спрашивают люди.
Брайам
3
На телефоне не помню синтаксис в верхней части моей головы, но проверьте наличие общей памяти sysv. Думаю, команда - это ipcs.
Дероберт
5
Вы когда-нибудь находили решение для этого? - У меня похожая проблема здесь: superuser.com/questions/793192/…
Хакерон

Ответы:

4

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

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

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

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

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

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

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

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

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

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

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

Majenko
источник
6
Это действительно интересно, но не отвечает на вопрос, почему ФП отмечает это конкретное несоответствие.
тердон
Я думаю, что единственное реальное несоответствие лежит между ожиданиями ОП и тем, что предоставляет Linux. Т.е. значения, которые дает Linux, просто не складываются, и это потому, что они уже изменились.
Маженко
Поскольку ОП на самом деле не понимает вопрос, который он задает, я не понимаю, как можно выбрать «правильный» ответ. Мы можем объяснить, как работает система, пока мы не поседеем, но если он не сможет понять эти основы и осознать, что его вопрос фактически бессмыслен, у нас никогда не будет «правильного» ответа.
Маженко
Ценю за это, но, честно говоря, мне не нравится тон агностицизма за ним. Я согласен с теорией «моментальных снимков», но если на моментальном снимке будет отображаться то же число, которое говорит о высокой загрузке ОЗУ, в то время как вы не можете выяснить, как это произошло, вам не будет интересно?
Джейсон
5
Вы должны опубликовать это в своем блоге. Это хорошо, но здесь это не актуально. Происходит что-то странное (и я имею в виду странное происхождение от того, кто понимает, что вы написали), поскольку VIRT процессов не учитывает использование всей оперативной памяти, и система не меняет местами, несмотря на необходимость сделать это.
Жиль "ТАК - перестань быть злым"
0

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

Существует разница между тем, что обозначено как «Используемая» память (в команде «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 ГБ), я полагаю, но я не уверен, что это подсчитывается отдельно.

SSL
источник
Просто хотел добавить, что в прошлом у меня был опыт работы с системой, которой не хватало памяти из-за плохо написанного приложения, которое выделяло сегменты общей памяти, но не освобождало их. Сегменты общей памяти сохранялись даже после того, как все процессы, использующие их, умерли Это был не Linux, но это может быть и в Linux. как упомянуто выше, см. ipcs для информации об этом. см. makelinux.net/alp/035 В нем говорится, что вам необходимо явно освободить разделяемую память.
SSL
1
Я не понимаю всего, о чем ваш ответ, но «Неактивная память может быть из процессов, которые завершились», безусловно, неправильно. Память пользовательского пространства бывает двух видов: сопоставленная или анонимная. Отображенная память всегда может быть восстановлена, потому что данные могут быть загружены из файла. Анонимная память может быть восстановлена, если она выгружена. Неактивная память - это память, которая является хорошим кандидатом для восстановления; однако содержимое должно быть в файле или где-то подкачкой, потому что эта память все еще используется. Когда процесс умирает, его память становится свободной и больше не учитывается как активный + неактивный.
Жиль "ТАК - перестань быть злым"
1
Некоторые ссылки: Что может вызвать увеличение неактивной памяти и как ее восстановить? при сбое сервера; старые, но все еще в основном применимые советы от Red Hat . И статья Бхавина Турахии, которую вы цитируете; в этом вопросе ничего не говорится, но в разделе «Понимание PFRA» объясняются анонимные и отображаемые страницы.
Жиль "ТАК - перестать быть злым"
Я подумал об неактивных страницах, на которые не ссылается процесс, из этой статьи: kernel.org/doc/gorman/html/understand/understand013.html Хотя я предполагаю, что это могут быть страницы, освобожденные процессом, который все еще выполняется. раздел «Восстановление страниц из списков LRU»
ssl
Но, возможно, это относится только к страницам в кэше подкачки?
SSL
-2

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

cjve
источник
-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

Echsecutor
источник
1
Вы не должны беспокоиться, если ваша система также подкачки, это нормально. Вы должны беспокоиться, если ваша система слишком часто меняется (это не то же самое, что использование большого пространства подкачки). Тот факт, что используемый своп равен 0, сам по себе странный, с таким небольшим количеством свободной физической памяти.
Жиль "ТАК - перестань быть злым"
хорошо, его вывод указывает, что его система вообще не менялась. Это, безусловно, оптимальный коэффициент обмена. Я не сказал, что маленький размер свопа - это хорошо, но нулевой размер, безусловно, есть. И до тех пор, пока система фактически не исчерпывает свободную память, почему она должна начать обмен?
Echutor
Нет, отсутствие подкачки далеко не оптимально. Память программ, которые не используются в данный момент, должна быть заменена, чтобы освободить место для дискового кэша для часто используемых файлов. Что касается бита, который вы только что добавили о выводе free, я думаю, вы имели в виду top- но даже тогда сумма может быть только больше, чем общая сумма (потому что общая память подсчитывается несколько раз), а не меньше.
Жиль "ТАК - перестать быть злым"
что вы подразумеваете под суммой может быть только больше, а не меньше? top показывает только столько процессов, сколько умещается на экране, я уверен, что приведенные выше не все запущенные процессы, следовательно, они не отсортированы по использованию памяти, эта часть вывода довольно бесполезна для вопроса «что использовала память» ,
Echutor
о, и я не хочу вступать в дискуссию о том, когда оптимальное время для начала свопинга, но по умолчанию на сервере linux не происходит свопинг памяти только потому, что он "не используется в данный момент".
Echutor