Score:0

Openstack nova ยุติ vms ของแขกด้วย oom_kill

ธง it

ฉันใช้ openstack Victoria กับการปรับใช้ Kolla ansible ส่วนประกอบทั้งหมดถูกบรรจุในคอนเทนเนอร์

โหนดคอมพิวท์ (oom_kill) ฆ่าแขกเมื่อหน่วยความจำเต็ม มีวิธีหลีกเลี่ยงเช่นเดียวกับในไฮเปอร์ไวเซอร์อื่น ๆ ที่ทำงานได้ดีโดยไม่มีปัญหานี้ ฉันใช้ Centos 8.3 โปรดแจ้งให้เราทราบหากมีวิธีหลีกเลี่ยงปัญหานี้

ข้อผิดพลาด :

** 27 ก.พ. 12:18:15 เคอร์เนล server1: neutron-openvsw เรียกใช้ oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
27 ก.พ. 12:18:15 เคอร์เนล server1: oom_kill_process.cold.28+0xb/0x10
27 กุมภาพันธ์ 12:18:15 เคอร์เนล server1: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
27 ก.พ. 12:18:15 เซิร์ฟเวอร์ 1 เคอร์เนล: oom-kill: constraint = constraint_none, nodemask = (null), cpuset = 395BDE13C7E0570EF36DF008BC028D8701FD76C1B56E2A56AFFRAFFDRAFFDRAFFDRANDAFFDRAND3 -qemu,งาน=qemu-kvm,pid=2301214,uid=42436
27 ก.พ. 12:18:17 เคอร์เนล server1: oom_reaper: กระบวนการเก็บเกี่ยว 2301214 (qemu-kvm), ตอนนี้ anon-rss:0kB, file-rss:516kB, shmem-rss:0kB**

การใช้หน่วยความจำ sar

==================================
10:10:05 น. kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
12:00:05 น. 877228 0 393690660 99.78 0 500284 2254123104 542.46 374227828 12705256 0
12:10:04 น. 866416 0 393701472 99.78 0 501844 2254259520 542.49 374233440 12704360 0
12:20:04 น. 301182096 300028052 93385792 23.67 0 705140 1938778932 466.57 83794716 5028804 8
12:30:04 น. 301085624 299970968 93482264 23.69 0 779220 1939000988    
us flag
ดูเหมือนว่า [เธรดนี้](http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027350.html) ในรายชื่อส่งเมลของ openstack-discuss
Score:0
ธง it

ตอบคำถามของฉันเองเมื่อฉันพบวิธีแก้ปัญหา

การฆ่า 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

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา