Linux високе використання оперативної пам'яті з невідомих причин


9

оглянувши це і знайшовши лише повідомлення людей, які неправильно інтерпретують фігуру "кешований", я вирішив задати це питання.

У мене є кілька серверів, які діють дивно. А саме, використання їх оперативної пам’яті дуже велике, без видимих ​​причин. Здається, що у невидимому процесі є багато "використаної" ОЗУ (і я маю на увазі "використано").

Ось деяка інформація:

  • на всіх серверах працює 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

Інші відмінності досить малі і в межах, які можна було очікувати (але ви можете самі переконатися)

Як ви бачите, на хорошому сервері загальна кількість всіх ВДЕ та SHR-пам’яті всіх процесів в значній мірі відповідає free -mзначенню 'для' використовуваного - / + буферів / кешу '', - що ви очікували, правда ?

Тепер подивіться на поганий сервер: free -mвихід "значення - / + буфери / кеш" приблизно в 3 рази вище, ніж ви могли очікувати, підсумовуючи все, що psможе вам показати.

Це також відповідає тому, що /proc/meminfoмені підказує.

Поки я не знаю, як це можливо. Що може статися тут?


Обидва висновки, на які /proc/meminfoви заявляєте, належать до хорошого сервера? Чи можете ви надати погану посилання на сервер?
Меттью Іфе

Чи є у вас доступ до консолі VMware vSphere або віртуального центру? Або будь-яким способом побачити пару речей, пов’язаних із пам’яттю гостя?
ewwhite

Будь ласка, опублікуйте вихід / proc / zoneinfo
Матвій Іфе

@ewwhite ні, на жаль, я абсолютно не маю доступу до нічого, крім самої операційної системи.
luxifer

@MatthewIfe етикетка meminfo була друкарською помилкою - її виправили ... тепер тягнуть вміст zoneinfo
luxifer

Відповіді:


12

Я думаю, у вас може виникнути проблема з повітряною кулею VMware . Є ймовірність, що перевиконання пам’яті в інфраструктурі vSphere занадто велике. Ви не зможете перенаправити це без доступу до vSphere vCenter, але ви маєте змогу виявити це у ваших віртуальних машинах, якщо припустити, що vmtools встановлено:

Чи можете ви опублікувати вихід vmware-toolbox-cmd stat balloon?

Також вам було виділено 16 Гб оперативної пам’яті. Будь ласка , запитайте кого є контроль над інфраструктурою , якщо є якісь - або ручні межі RAM , розміщені на віртуальних машинах під питанням.


Прочитавши, як працює повітряна куля на vmware linux vms, я думаю, це причина. Я дуже вражений, що вони не пропонують дороги з боку VM для того, щоб отримати рахунок для "використаних" сторінок.
Метью Іфе

1
Це дійсно правильно, я думаю ... хороший сервер показує "o MB" ... поганий сервер показує "10092 MB", що майже відповідає тому, що ми бачимо!
luxifer

@luxifer Отже, ви, хлопці, повинні це виправити . Що означає зняття штучного обмеження оперативної пам’яті на VM або vMotioning на інший хост ESXi. Попросіть свою команду з інфраструктури VMware перевірити, чи є це більш поширеною проблемою .
ewwhite

@ewwhite Я обов’язково сповіщу про них. Однак це інфраструктура одного з наших клієнтів, і зазвичай вони повинні були це визначити. На жаль, це не так, як здається, працюють світові провайдери послуг ІТ;)
luxifer

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