Высокая загрузка ОЗУ в Linux по неизвестной причине


9

После того, как я искал и нашел только сообщения людей, которые неправильно интерпретируют «кэшированную» фигуру, я решил задать этот вопрос.

У меня есть несколько серверов под рукой, которые ведут себя странно. А именно, их использование RAM очень высоко, без видимой причины. Кажется, что невидимый процесс имеет много «использованной» оперативной памяти (и я имею в виду «используется»).

Вот немного информации:

  • все серверы работают под SLES 11
  • ядро 3.0.76
  • все серверы работают как гости в инфраструктуре VMWare ESX
  • Я не настроил серверы, не имел права выбора ОС и не имею доступа к инфраструктуре виртуализации.
  • все серверы настроены одинаково, и они работают на одном и том же наборе программного обеспечения (это кластер и, да, я знаю, виртуализированный кластер, yada yada, как сказано: я имел и не могу сказать об этом)

И некоторый вывод оболочки:

root@good-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      14780       1173          0        737       8982
-/+ buffers/cache:       5059      10894
Swap:        31731          0      31731

root@good-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.7 GiB
=================================

root@bad-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      15830        123          0        124       1335
-/+ buffers/cache:      14370       1583
Swap:        31731         15      31716

root@bad-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.0 GiB
=================================

Содержимое / proc / meminfo хорошего сервера

MemTotal:       16336860 kB
MemFree:          112356 kB
Buffers:          138384 kB
Cached:          1145208 kB
SwapCached:         1244 kB
Active:          4344336 kB
Inactive:        1028744 kB
Active(anon):    3706796 kB
Inactive(anon):   382724 kB
Active(file):     637540 kB
Inactive(file):   646020 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32477728 kB
Dirty:              1248 kB
Writeback:             0 kB
AnonPages:       4087776 kB
Mapped:            60132 kB
Shmem:               156 kB
Slab:             274968 kB
SReclaimable:     225864 kB
SUnreclaim:        49104 kB
KernelStack:        4352 kB
PageTables:        16400 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6576912 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359418748 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       73728 kB
DirectMap2M:    16703488 kB

Содержимое / proc / meminfo плохого сервера

MemTotal:       16336860 kB
MemFree:         1182320 kB
Buffers:          756244 kB
Cached:          8695688 kB
SwapCached:            0 kB
Active:         13499680 kB
Inactive:         843208 kB
Active(anon):    4853460 kB
Inactive(anon):    37372 kB
Active(file):    8646220 kB
Inactive(file):   805836 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32493560 kB
Dirty:              1268 kB
Writeback:             0 kB
AnonPages:       4890180 kB
Mapped:            84672 kB
Shmem:               252 kB
Slab:             586084 kB
SReclaimable:     503716 kB
SUnreclaim:        82368 kB
KernelStack:        5176 kB
PageTables:        19684 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6794180 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359419468 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      112640 kB
DirectMap2M:    16664576 kB

TL; DR - если сравнить их бок о бок, вот основные различия (BADserver - GOODserver):

MemFree       -1070 MB
Cached        -7550 MB
Active        -9155 MB
Active(anon)  -1147 MB
Active(file)  -8009 MB
AnonPages     - 802 MB

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

Как вы можете видеть, на хорошем сервере общий объем всей памяти RES и SHR всех процессов в значительной степени соответствует free -mвыводу для значения «used - / + buffers / cache» - что и следовало ожидать, верно ?

Теперь посмотрим на неверный сервер: free -mвывод для значения «used - / + buffers / cache» примерно в 3 раза выше, чем вы могли бы ожидать, суммируя все, что psвам может показать.

Это также соответствует тому, что /proc/meminfoговорит мне.

Пока что я понятия не имею, как это вообще возможно. Что здесь может происходить?


Оба выхода /proc/meminfoвашей претензии для хорошего сервера? Можете ли вы предоставить неверную ссылку на сервер?
Мэтью Иф

Есть ли у вас доступ к консоли VMware vSphere или к виртуальному центру? Или какой-нибудь способ увидеть пару вещей, связанных с гостевой памятью?
ewwhite

Пожалуйста, опубликуйте вывод / proc / zoneinfo
Мэтью Ифе

@ewwhite нет, к сожалению, у меня абсолютно нет доступа ни к чему, кроме самой операционной системы.
Luxifer

@MatthewIfe лейбл meminfo был опечаткой - исправил ее ... теперь тянет контент
zoneinfo

Ответы:


12

Я думаю, что у вас может быть проблема раздувания памяти VMware . Существует вероятность того, что чрезмерное использование памяти в инфраструктуре vSphere слишком велико. Вы не сможете исправить это без доступа к vSphere vCenter, но вы должны быть в состоянии обнаружить это из ваших виртуальных машин, предполагая, что vmtools установлен:

Можете ли вы опубликовать вывод vmware-toolbox-cmd stat balloon?

Кроме того, вам было выделено 16 ГБ оперативной памяти. Пожалуйста , спросите кого есть контроль над инфраструктурой , если есть какие - либо ручные пределы RAM , размещенные на виртуальных машинах под вопросом.


Прочитав, как раздувание работает на vmware linux, я думаю, в этом причина. Я довольно не впечатлен, что они не предлагают способ со стороны виртуальной машины для учета «используемых» страниц, хотя.
Мэтью Ифе

1
Я думаю, это действительно правильно ... хороший сервер показывает "o МБ" ... плохой сервер показывает "10092 МБ", что в значительной степени соответствует тому, что мы видим!
Luxifer

@luxifer Так что теперь вы, ребята, должны это исправить . Это означает либо удаление искусственного ограничения ОЗУ на виртуальной машине, либо vMotioning на другой хост ESXi. Попросите группу специалистов по инфраструктуре VMware выяснить, является ли это более распространенной проблемой .
ewwhite

@ewwhite, я обязательно сообщу им. Однако это инфраструктура одного из наших клиентов, и обычно они должны были это идентифицировать. К сожалению, это не то, как работают крупные поставщики ИТ-услуг по всему миру;)
luxifer

@luxifer Серьезно, я считаю, что это может происходить во всех видах организаций , и люди, которым поручено управлять инфраструктурой vSphere, похоже, не осознают этого.
ewwhite
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.