ทำไม kswapd0 ทำงานบนคอมพิวเตอร์ที่ไม่มี swap?

ฉันมีเซิร์ฟเวอร์คลาวด์ที่มี RAM ~ 14G และไม่มีการสลับ แต่บางครั้งผมเห็น kswapd0 การขึ้น CPU topบางอย่างเมื่อผมทำงาน เหตุใด kswapd0 จะทำงานเลยถ้าไม่มีพื้นที่สว็อปเพื่อให้จัดการ

ยังมีกระบวนการตรวจสอบว่ามีการแลกเปลี่ยนหรือไม่ เพื่อลดความมันคุณจะต้องตั้งค่าของคุณswappiness -

แก้ไข "/etc/sysctl.conf" เป็นรูทจากนั้นเปลี่ยน (หรือเพิ่ม)

vm.swappiness = 0

พื้นที่สวอปใช้สำหรับข้อมูลที่ไม่ได้สำรองไว้โดยไฟล์อื่น ข้อมูลที่แมปจากไฟล์อื่น ๆ บนดิสก์ (เช่นโปรแกรมที่เรียกใช้งานได้) จะยังคงสลับเป็นไฟล์ที่เกี่ยวข้องแม้ว่าคุณจะไม่มีอุปกรณ์สลับ

เป็นปัญหาที่ทราบกันดีว่าเมื่อ Linux มีหน่วยความจำไม่เพียงพอสามารถป้อน swap loops แทนการทำในสิ่งที่ควรทำการฆ่ากระบวนการเพื่อเพิ่ม ram มีนักฆ่า OOM (หน่วยความจำไม่เพียงพอ) ที่ทำสิ่งนี้ แต่เฉพาะในกรณีที่ Swap และ RAM เต็ม

อย่างไรก็ตามสิ่งนี้ไม่ควรเป็นปัญหาจริงๆ หากมีหลายกระบวนการที่ละเมิดเช่น Firefox และ Chrome แต่ละแท็บที่ใช้และจับหน่วยความจำกระบวนการเหล่านี้จะทำให้การอ่านค่ากลับมา จากนั้น Linux จะเข้าสู่ลูปที่หน่วยความจำเดียวกันถูกย้ายไปมาระหว่างหน่วยความจำและฮาร์ดไดรฟ์ สิ่งนี้จะทำให้เกิดความผกผันของลำดับความสำคัญซึ่งการสลับกระบวนการกลับไปกลับมาทำให้ระบบไม่ตอบสนอง

หากคุณปิดใช้งาน swap คุณจะทำให้ปัญหานี้แย่ลงเนื่องจาก kswapd0 ไม่มีตัวเลือกในการสลับหน่วยความจำที่ถูกแมปเช่น executables หากคุณสลับไฟล์ที่เรียกใช้งานได้มันจะมีโอกาสมากที่พวกมันจะถูกสับเปลี่ยนกลับเข้ามาใหม่อย่างรวดเร็ว

ฉันพยายามเรียกพฤติกรรมนี้ใน NetBSD เพื่อทำการทดสอบและสิ่งที่เกิดขึ้นนั่นคือกระบวนการที่กระทำผิดนั้นช้าอย่างไม่น่าเชื่อในขณะที่ระบบปฏิบัติการนั้นตอบสนองได้ดีมาก หมายความว่าปัญหาการแลกเปลี่ยนเกิดขึ้น แต่ไม่มีการสลับลำดับความสำคัญ อย่างไรก็ตาม NetBSD ไม่มีไดรเวอร์ AMDGPU ดังนั้นฉันจึงติด Linux ในขณะนี้ บางที NetBSD ไม่ได้ใช้หน่วยความจำในการแมปไฟล์และนั่นคือสาเหตุที่มันไม่เข้าสู่การสลับลูป แต่ฉันไม่รู้จริงๆเกี่ยวกับการใช้งานเพื่อบอกว่าทำไมมันจึงไม่ตอบสนอง

Facebook มีปัญหานี้เช่นกันและสร้าง OOMD ซึ่งเป็น Out Of Memory Daemon นี่คือ daemon ที่ตรวจพบกิจกรรม kswapd0 และเริ่มการฆ่ากระบวนการ และจากข้อมูลของ Facebook พบว่าเซิร์ฟเวอร์ Linux เกือบหมดปัญหาการไม่ตอบสนอง อย่างไรก็ตามฉันยังไม่ได้ทดสอบและฉันไม่รู้ว่ามันจะทำงานได้ดีกับเซิร์ฟเวอร์หรือเดสก์ท็อป / แล็ปท็อปอื่น ๆ อย่างไร OOMD ที่น่าสนใจมีตรรกะบางอย่างที่ตัดสินใจว่ากระบวนการใดที่จะฆ่าเสียก่อนเพื่อรักษากระบวนการของระบบและส่วนหนึ่งของระบบเซิร์ฟเวอร์ที่รับผิดชอบการเปิดใช้งานสิ่งที่ถูกฆ่าใหม่

อย่างไรก็ตามนี่ไม่ใช่วิธีที่ควรแก้ไข OOMD เป็นแฮ็กที่น่าเกลียด ทางออกที่แท้จริงคือการแก้ไขลำดับความสำคัญผกผันที่ทำให้เกิดการวนรอบการสลับเช่นเดียวกับการทำให้เคอร์เนล OOM Killer ก้าวร้าวมากขึ้นในกระบวนการฆ่า การแก้ไขอยู่ในเคอร์เนลเพราะเป็นที่เดียวที่เราสามารถมั่นใจได้ว่าปัญหาถูกตรวจพบในเวลาและกระบวนการถูกฆ่าอย่างเหมาะสม

การตั้งค่า swappiness = 0 ไม่ใช่วิธีแก้ปัญหาเพราะเมื่อระบบไม่มีแรมว่างระบบจะเริ่มทำการแลกเปลี่ยนไม่ว่าจะเกิดอะไรขึ้น ไม่มีตัวเลือกในการรับประกันว่าระบบจะไม่เริ่มการแลกเปลี่ยน

และการแก้ไขแอพพลิเคชั่นที่ละเมิดไม่ได้เป็นการแก้ไข ไม่เฉพาะเจาะจงหากผู้ใช้ต้องการใช้ประโยชน์จากข้อบกพร่องนี้เพื่อทำให้ระบบปฏิบัติการไม่ตอบสนองโดยเจตนา การตอบสนองเป็นความรับผิดชอบของเคอร์เนล หาก Firefox ทำให้ตัวเองไม่ตอบสนองดังนั้นการแก้ไขก็คือแอปพลิเคชัน อย่างไรก็ตามมันไม่เพียง แต่ทำให้ตัวเองไม่ตอบสนองเท่านั้น แต่ยังทำให้ระบบปฏิบัติการทั้งหมดช้าลงและไม่ตอบสนอง ถึงระดับที่อาจใช้เวลาครึ่งชั่วโมงในการเข้าสู่ระบบ SSH SSH ไม่มีส่วนเกี่ยวข้องกับสิ่งใดและหากไม่สามารถใช้งานได้นั่นเป็นข้อผิดพลาดในเคอร์เนลไม่ใช่ในส่วนอื่น ๆ ของระบบ และไม่ใช่ข้อผิดพลาดมันเป็นข้อบกพร่องสองข้อ ข้อผิดพลาดอย่างหนึ่งคือการผกผันของลำดับความสำคัญโดยที่รอบนอกการสับเปลี่ยนทางรถไฟได้รับอนุญาตให้รบกวนกระบวนการอื่นนอกเหนือจากกระบวนการที่กระทำผิดและในตัวของมันเองนั้นไม่ดี ข้อผิดพลาดอื่น ๆ คือมันไม่ได้ ' ตรวจไม่พบว่ามีการสลับลูปและทำให้เกิดการสึกหรออย่างบ้าคลั่งใน HDD / SSD หรือที่เก็บข้อมูลใด ๆ เมื่อทำการสับเปลี่ยนปฏิบัติการนี่เป็นปัญหาที่น้อยกว่าเนื่องจากพวกเขาจะอ่านเฉพาะแผนที่หน่วยความจำที่ไม่ได้เขียนกลับไปที่ดิสก์ แต่ kswapd0 ยังคงถูกล็อคการอ่านสิ่งที่มันในเวลาเดียวกันจะถูกลบออกจากหน่วยความจำ

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

ไม่จำเป็นว่า Firefox ที่ทำให้เกิดปัญหาของคุณ แต่เป็นเบราว์เซอร์เริ่มต้นไม่ใช่ Chrome และทั้งคู่เป็นที่รู้จักอย่างกว้างขวางในการกระตุ้นให้เกิดปัญหานี้เนื่องจากพวกเขาจัดการกับหน่วยความจำที่มีอยู่ซึ่งเป็นสิ่งที่สูญเปล่ารวมถึงแคชและหน่วยความจำสลับซึ่งใน Linux ถือเป็น "หน่วยความจำที่มีอยู่" ดังนั้นเพื่อไม่ให้ได้ "หน่วยความจำที่พร้อมใช้" รับเสียมันใช้สำหรับแคชและสิ่งอื่น ๆ เห็นได้ชัดว่าการใช้ SWAP สำหรับ DISK CACHE นั้นเป็นไอเดียที่แย่มาก แต่เพื่อนทั้ง Firefox และ Chrome ตอบสนองต่อสิ่งนั้นด้วย

ดังนั้นสิ่งที่เรามีอยู่ที่นี่คือข้อบกพร่องเคอร์เนลสามตัวที่ทีมเคอร์เนลดูเหมือนจะไม่พิจารณาข้อบกพร่อง และข้อบกพร่องใน Firefox, Chrome และอนุพันธ์ทั้งหมดที่พวกเขาไม่ได้พิจารณาข้อผิดพลาด ฉันพยายามสร้าง Firefox บนแล็ปท็อป Fedora ของฉันเพื่อดูปัญหานี้และอาจแก้ไขได้ คาดเดาสิ่งที่ การสร้าง Firefox ด้วย GCC บนซีพียู 4 คอร์ที่มี 4GB ram ทำให้ SWAP LOOP พร้อม PRIORITY INVERSION ดังนั้นหนึ่งในแอปพลิเคชั่นที่ต้องเขียนใหม่คือ GCC ใน NetBSD สิ่งที่เกิดขึ้นเป็นเพียงแค่ 4 อินสแตนซ์ที่ทำงานอยู่ของ GCC จะช้ากว่าการใช้งานหนึ่งอินสแตนซ์ แต่จะไม่หยุดการทำงานของระบบ

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

หากคุณไม่มี swap และkswapd0ทำงานอยู่ระบบของคุณใช้ RAM เกือบทั้งหมดในขณะนั้น ถึงเวลาที่จะได้รับเครื่องมือที่ดีกว่าในการตรวจสอบการใช้งานหน่วยความจำ (หรือหน่วยความจำว่าง / ว่างในระบบ)

การแก้ไขที่แท้จริงคือการลดการใช้หน่วยความจำ (เรียกใช้กระบวนการที่มีการรั่วไหลของหน่วยความจำน้อยลงเรียกใช้กระบวนการน้อยลงข้ามการทำงานบางกระบวนการเลย จำกัด จำนวนเด็ก / กระบวนการทำงานของซอฟต์แวร์เซิร์ฟเวอร์บางตัว) หรือรับ RAM เพิ่มเติม หากความต้องการ RAM เกิดจากการรั่วไหลของหน่วยความจำคุณอาจเลือกใช้ swap แทน ลีนุกซ์น่าจะฉลาดที่จะเอาส่วนที่รั่วไหลออกมาเพื่อแลกเปลี่ยนเวลาที่เพียงพอ การสลับจะดีกว่าไม่มีอะไร แต่นั่นไม่ใช่สิ่งทดแทนที่แท้จริงสำหรับการมี RAM ในปริมาณที่เพียงพอ