ตอบคำถามของฉันเองเมื่อฉันพบวิธีแก้ปัญหา
การฆ่า Oom เกิดขึ้นแม้ว่าสถิติฟรีจะดูดี เช่น บน RAM 256G ใช้เพียง 140G และยังคงมีอยู่ประมาณ 100G ที่แสดงว่าฟรี
[root@serverxx ~]# ฟรี -g
รวมใช้บัฟ/แคชที่ใช้ร่วมกันฟรี
เบอร์: 251 140 108 0 2 108
สลับ: 19 6 13
การฆ่า oom ถูกเรียกโดย %commit สูงในสถิติ sar ซึ่งเคอร์เนลเริ่มกำหนดเป้าหมายอินสแตนซ์ที่มีรอยเท้าหน่วยความจำสูงเพื่อเพิ่มพื้นที่ว่าง
เพื่อหลีกเลี่ยงการฆ่า oom สำหรับอินสแตนซ์ของแขกที่มีรอยเท้าหน่วยความจำสูงกว่า ฉันตั้งค่าต่อไปนี้
vm.oom_kill_allocating_task=1
เมื่อฉันทำ sar -r %commit นั้นสูงกว่าที่ระบบสามารถจัดสรรได้และฉันคิดจาก ps ว่ามันเป็นคอนเทนเนอร์สำรองถ่านที่สร้างขึ้นโดยค่าเริ่มต้นจากการปรับใช้ kolla-ansible แต่ไม่ได้กำหนดค่า
สถิติของบริการสำรองข้อมูล Cinder ที่ฉันไม่ได้กำหนดค่าและเพิ่งทำงานอยู่ ปรากฎว่าคอนเทนเนอร์ที่ไม่ได้กำหนดค่ากำลังใช้หน่วยความจำทั้งหมดล่วงเวลาตามที่เห็นจากเอาต์พุตของคำสั่ง ps ใน vsz
ps -eo args,comm,pid,ppid,rss,vsz --sort vsz คอลัมน์
VSZ สูงมาก
COMMANDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â PID
/usr/libexec/qemu-kvm -ชื่อ qemu-kvm
/var/lib/kolla/venv/bin/pyt cinder-backup หลัก 43689 43544 170999912 870274784
สถิติ Sar สำหรับ % การคอมมิตกลับมาเป็นปกติหลังจากที่คอนเทนเนอร์สำรองหยุดทำงาน และตอนนี้ทุกอย่างกลับเป็นปกติ %commit เน้นจาก 1083.46 ถึง 14.21 หลังจากการเปลี่ยนแปลง
02:00:37 PM kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
15:00:37 น. 48843576 49998184 82890508 62.92 9576 5949348 1427280428 1083.46 75646888 2797388 324
03:10:37 น. 48829248 49991284 82904836 62.93 9576 5956544 1427343664 1083.50 75653556 2804592 116
03:20:22 น. 120198612 121445516 11535472 8.76 9576 6042892 18733688 14.22 4887688 2854704 80
03:30:37 น. 120189464 121444176 11544620 8.76 9576 6050200 18725820 14.21 4887752 2862248 88