การใช้งาน RAM บน Linux สูงด้วยสาเหตุที่ไม่ทราบสาเหตุ


9

หลังจากค้นหาสิ่งนี้และค้นหาเฉพาะโพสต์ของคนที่ไม่ตีความตัวเลข "แคช" อย่างถูกต้องฉันตัดสินใจถามคำถามนี้

ฉันมีเซิร์ฟเวอร์อยู่ในมือซึ่งทำหน้าที่แปลก กล่าวคือการใช้ RAM ของพวกเขานั้นสูงมากโดยไม่มีเหตุผลที่ชัดเจน ดูเหมือนว่ากระบวนการที่มองไม่เห็นมี 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เอาต์พุตของค่า "ใช้ - / + บัฟเฟอร์ / แคช" ซึ่งเป็นสิ่งที่คุณคาดหวัง ?

ตอนนี้ดูเซิร์ฟเวอร์ที่ไม่ดี: free -mผลลัพธ์ของค่า "ใช้แล้ว - / + บัฟเฟอร์ / แคช" สูงกว่าที่คุณคาดไว้ประมาณ 3 เท่าโดยสรุปทุกอย่างpsจะแสดงให้คุณเห็น

ตรงกับสิ่งที่/proc/meminfoบอกฉัน

จนถึงตอนนี้ฉันไม่รู้ว่ามันเป็นไปได้ยังไง เกิดอะไรขึ้นที่นี่?


ผลลัพธ์ทั้งสองอย่างที่/proc/meminfoคุณอ้างว่ามีไว้สำหรับเซิร์ฟเวอร์ที่ดีหรือไม่? คุณสามารถให้การอ้างอิงเซิร์ฟเวอร์ที่ไม่ดีด้วยหรือไม่
Matthew Ife

คุณมีสิทธิ์เข้าถึงคอนโซล VMware vSphere หรือ Virtual Center ของคุณหรือไม่? หรือวิธีการดูสองสิ่งที่เกี่ยวข้องกับความทรงจำของแขก?
ewwhite

กรุณาโพสต์ผลลัพธ์ของ / proc / zoneinfo
Matthew Ife

@ ไม่ขาวโชคไม่ดีที่ฉันไม่สามารถเข้าถึงสิ่งใดนอกเหนือจากระบบปฏิบัติการของตัวเอง
luxifer

@ แมททีเรียป้ายชื่อ meminfo เป็นตัวพิมพ์ผิด - แก้ไขมัน ... ตอนนี้ดึงเนื้อหา zoneinfo
luxifer

คำตอบ:


12

ฉันคิดว่าคุณอาจมีปัญหาบอลลูนหน่วยความจำ VMware มีโอกาสที่หน่วยความจำ overcommitment ในโครงสร้างพื้นฐาน vSphere นั้นสูงเกินไป คุณจะไม่สามารถแก้ไขได้โดยไม่ต้องเข้าถึง vSphere vCenter แต่คุณควรสามารถตรวจจับสิ่งนี้จากภายในเครื่องเสมือนของคุณโดยสมมติว่าติดตั้ง vmtools:

คุณช่วยโพสต์ผลลัพธ์ของได้vmware-toolbox-cmd stat balloonไหม

นอกจากนี้คุณยังได้รับการจัดสรร RAM 16 GB โปรดถามผู้ที่อยู่ในความควบคุมของโครงสร้างพื้นฐานหากมีข้อ จำกัด RAM ด้วยตนเองใด ๆ ที่วางอยู่บน VMs ที่เป็นปัญหา


ต้องอ่านวิธีการบอลลูนทำงานบน vmware linux vms ฉันคิดว่านี่เป็นสาเหตุ ฉันค่อนข้างประทับใจพวกเขาไม่ได้เสนอวิธีการจากด้าน VM สำหรับบัญชีสำหรับ 'ใช้' หน้าแม้ว่า
Matthew Ife

1
มันถูกต้องแน่นอนฉันคิดว่า ... เซิร์ฟเวอร์ที่ดีแสดง "o MB" ... เซิร์ฟเวอร์ที่ไม่ดีแสดง "10092 MB" ซึ่งค่อนข้างสอดคล้องกับสิ่งที่เราเห็น!
luxifer

@luxifer ดังนั้นตอนนี้พวกคุณต้องแก้ไขมัน ซึ่งหมายถึงการลบขีด จำกัด RAM เทียมบน VM หรือ vMotioning ไปยังโฮสต์ ESXi อื่น สอบถามทีมโครงสร้างพื้นฐาน VMware ของคุณเพื่อดูว่านี่เป็นปัญหาที่แพร่หลายมากขึ้นหรือไม่
ewwhite

@ ขาวฉันจะแจ้งให้ทราบอย่างแน่นอน อย่างไรก็ตามมันเป็นโครงสร้างพื้นฐานของหนึ่งในลูกค้าของเราและโดยปกติแล้วพวกเขาควรจะระบุสิ่งนี้ น่าเสียดายที่ผู้ให้บริการด้านไอทีทั่วโลกดูเหมือนจะใช้งานได้ไม่ใหญ่
เท่าไหร่

@ luxifer อย่างจริงจังฉันพบว่าสิ่งนี้สามารถเกิดขึ้นได้ในองค์กรทุกประเภทและผู้คนที่ได้รับมอบหมายให้จัดการโครงสร้างพื้นฐาน vSphere ดูเหมือนจะไม่เข้าใจ
ewwhite
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.