Hohe RAM-Auslastung von Linux aus unbekanntem Grund


9

Nachdem ich mich danach umgesehen und nur Beiträge von Personen gefunden hatte, die die "zwischengespeicherte" Zahl nicht richtig interpretierten, entschied ich mich, diese Frage zu stellen.

Ich habe einige Server zur Hand, die sich seltsam verhalten. Ihre RAM-Auslastung ist nämlich ohne ersichtlichen Grund sehr hoch. Es scheint, als ob ein unsichtbarer Prozess viel "benutzten" RAM hat (und ich meine "gebraucht").

Hier einige Infos:

  • Auf allen Servern wird SLES 11 ausgeführt
  • Kernel ist 3.0.76
  • Alle Server werden als Gäste unter einer VMWare ESX-Infrastruktur ausgeführt
  • Ich habe die Server nicht eingerichtet und hatte weder ein Mitspracherecht bei der Auswahl des Betriebssystems noch habe ich Zugriff auf die Virtualisierungsinfrastruktur
  • Alle Server sind ähnlich eingerichtet und führen dieselbe Software aus (es ist ein Cluster und ja, ich weiß, virtualisierter Cluster, yada yada, wie gesagt: Ich hatte und habe kein Mitspracherecht).

Und einige Shell-Ausgaben:

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
=================================

Inhalt von / proc / meminfo des guten Servers

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

Inhalt von / proc / meminfo des fehlerhaften Servers

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 - Wenn Sie diese nebeneinander vergleichen, sind hier die Hauptunterschiede (BADserver - GOODserver):

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

Die anderen Unterschiede sind eher gering und in Grenzen zu erwarten (aber Sie können es selbst sehen)

Wie Sie sehen können, entspricht auf dem guten Server die Summe aller RES- und SHR-Speicher aller Prozesse ziemlich genau der free -mAusgabe für den Wert "used - / + buffer / cache" - was Sie erwarten würden, richtig ?

Schauen Sie sich nun den fehlerhaften Server an: free -mDie Ausgabe für den Wert "used - / + buffer / cache" ist ungefähr dreimal so hoch wie erwartet. Zusammenfassend pslässt sich sagen, dass alles angezeigt wird.

Dies stimmt auch mit dem überein, was /proc/meminfomir sagt.

Bisher habe ich keine Ahnung, wie das überhaupt möglich ist. Was könnte hier los sein?


Beide Ausgaben von /proc/meminfoIhnen behaupten, sind für den guten Server? Können Sie auch eine schlechte Serverreferenz angeben?
Matthew Ife

Haben Sie Zugriff auf Ihre VMware vSphere-Konsole oder Ihr Virtual Center? Oder eine Möglichkeit, ein paar Dinge im Zusammenhang mit der Erinnerung an Gäste zu sehen?
ewwhite

Bitte posten Sie die Ausgabe von / proc / zoneinfo
Matthew Ife

@ewwhite nein, leider habe ich absolut keinen Zugriff auf etwas anderes als das Betriebssystem selbst.
Luxifer

@MatthewIfe das Meminfo-Label war ein Tippfehler - korrigiert es ... jetzt zieht Zoneinfo-Inhalt
Luxifer

Antworten:


12

Ich denke, Sie haben möglicherweise ein VMware-Speicherproblem . Es besteht die Möglichkeit, dass die Speicherüberlastung in der vSphere-Infrastruktur zu hoch ist. Ohne Zugriff auf das vSphere vCenter können Sie dies nicht beheben. Sie sollten dies jedoch in Ihren virtuellen Maschinen erkennen können, vorausgesetzt, vmtools sind installiert:

Können Sie bitte die Ausgabe von posten vmware-toolbox-cmd stat balloon?

Außerdem wurden Ihnen 16 GB RAM zugewiesen. Bitte fragen Sie , wem ist die Kontrolle über die Infrastruktur , wenn es irgendwelche manuellen RAM Grenzen für die VMs in Frage gestellt sind.


Nachdem ich gelesen habe, wie Ballonfahren unter VMware Linux VMS funktioniert, denke ich, dass dies die Ursache ist. Ich bin ziemlich unbeeindruckt, dass sie keinen Weg von der VM-Seite bieten, um die "verwendeten" Seiten zu berücksichtigen.
Matthew Ife

1
Das ist in der Tat richtig, denke ich ... der gute Server zeigt "o MB" ... der schlechte Server zeigt "10092 MB", was ziemlich genau dem entspricht, was wir sehen!
Luxifer

@luxifer Also jetzt müsst ihr es reparieren . Dies bedeutet entweder das Entfernen eines künstlichen RAM-Limits auf der VM oder das vMotioning auf einen anderen ESXi-Host. Fragen Sie Ihr VMware-Infrastruktur-Team, ob dies ein weiter verbreitetes Problem ist .
ewwhite

@ewwhite Ich werde sie sicher benachrichtigen. Es ist jedoch die Infrastruktur eines unserer Kunden, und normalerweise hätten sie dies identifizieren müssen. Leider scheinen so große, weltweite IT-Dienstleister nicht so zu funktionieren;)
Luxifer

@luxifer Im Ernst, ich finde, dass dies in allen Arten von Organisationen passieren kann , und die mit der Verwaltung der vSphere-Infrastruktur beauftragten Personen scheinen dies nicht zu erkennen.
ewwhite
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.