Penggunaan RAM Linux tinggi untuk alasan yang tidak diketahui


9

setelah mencari-cari ini dan hanya menemukan posting orang yang tidak menafsirkan angka "cache" dengan benar, saya memutuskan untuk mengajukan pertanyaan ini.

Saya memiliki beberapa server, yang bertindak aneh. Yaitu, penggunaan RAM mereka sangat tinggi, tanpa alasan yang jelas. Sepertinya proses yang tidak terlihat memiliki banyak "digunakan" RAM (dan maksud saya "digunakan").

Berikut ini beberapa info:

  • semua server menjalankan SLES 11
  • kernel adalah 3.0.76
  • semua server dijalankan sebagai tamu di bawah infrastruktur VMWare ESX
  • Saya belum mengatur server dan tidak mengatakan dalam pilihan OS dan saya juga tidak memiliki akses ke infrastruktur virtualisasi
  • semua server diatur dengan cara yang sama dan mereka menjalankan perangkat lunak yang sama (ini sebuah cluster dan ya, saya tahu, cluster virtual, yada yada, seperti yang dikatakan: Saya sudah dan tidak punya suara dalam hal itu)

Dan beberapa keluaran shell:

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

Isi / proc / meminfo dari server yang baik

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

Isi / proc / meminfo dari server yang buruk

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 - jika Anda membandingkan sisi-sisi ini, inilah perbedaan utamanya (BADserver - GOODserver):

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

Perbedaan lainnya agak kecil dan dalam batas yang mungkin diharapkan seseorang (tetapi Anda dapat melihatnya sendiri)

Seperti yang Anda lihat, pada server yang baik total semua RES dan memori SHR dari semua proses cukup banyak sejalan dengan free -moutput untuk nilai "bekas - / + buffer / cache" - yang adalah apa yang Anda harapkan, kan ?

Sekarang lihat server yang buruk: free -moutput untuk nilai "used - / + buffer / cache" adalah sekitar 3 kali lebih tinggi dari yang Anda harapkan, jumlah semuanya psbisa menunjukkan kepada Anda.

Ini juga cocok dengan apa yang /proc/meminfomemberitahu saya.

Sejauh ini saya tidak tahu bagaimana itu mungkin terjadi. Apa yang mungkin terjadi di sini?


Kedua output yang /proc/meminfoAnda klaim adalah untuk server yang baik? Bisakah Anda memberikan referensi server yang buruk juga?
Matthew Ife

Apakah Anda memiliki akses ke konsol VMware vSphere atau Pusat Virtual? Atau ada cara untuk melihat beberapa hal yang berkaitan dengan memori tamu?
ewwhite

Silakan kirim output dari / proc / zoneinfo
Matthew Ife

@ewwhite tidak, sayangnya saya sama sekali tidak memiliki akses ke apa pun di luar sistem operasi itu sendiri.
luxifer

@MatthewIfe label meminfo adalah kesalahan ketik - dikoreksi ... sekarang menarik konten zoneinfo
luxifer

Jawaban:


12

Saya pikir Anda mungkin memiliki masalah memori balon VMware . Ada kemungkinan overcommitment memori di seluruh infrastruktur vSphere terlalu tinggi. Anda tidak akan dapat memulihkan ini tanpa akses ke vSphere vCenter, tetapi Anda harus dapat mendeteksi ini dari dalam mesin virtual Anda, dengan asumsi vmtools diinstal:

Bisakah Anda memposting output vmware-toolbox-cmd stat balloon?

Selain itu, Anda telah mengalokasikan 16GB RAM. Silakan tanyakan siapa yang mengendalikan infrastruktur jika ada batas RAM manual yang ditempatkan pada VM yang dimaksud.


Setelah membaca bagaimana ballooning bekerja pada vmware linux vms, saya pikir inilah penyebabnya. Saya sangat terkesan mereka tidak menawarkan cara dari sisi VM untuk akun halaman 'bekas'.
Matthew Ife

1
Ini memang benar saya pikir ... server yang baik menunjukkan "o MB" ... server yang buruk menunjukkan "10092 MB", yang cukup banyak sesuai dengan apa yang kami lihat!
luxifer

@luxifer Jadi sekarang kalian harus memperbaikinya . Yang berarti menghapus batas RAM buatan pada VM atau vMotioning ke host ESXi lain. Minta tim infrastruktur VMware Anda untuk melihat apakah ini masalah yang lebih luas .
ewwhite

@white saya akan memberi tahu mereka pasti. Namun, itu adalah infrastruktur dari salah satu pelanggan kami dan biasanya mereka seharusnya mengidentifikasi ini. Sayangnya, itu bukan seberapa besar, penyedia layanan TI di seluruh dunia tampaknya bekerja;)
luxifer

@luxifer Serius, saya menemukan bahwa ini bisa terjadi di semua jenis organisasi , dan orang-orang yang ditugaskan mengelola infrastruktur vSphere tampaknya tidak menyadarinya.
ewwhite
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.