การแปลบทความจัดทำขึ้นในวันเริ่มต้นหลักสูตร .
มีคำถามเกิดขึ้นเป็นระยะๆ เกี่ยวกับคำแนะนำของ Gluster เกี่ยวกับการปรับแต่งเคอร์เนล และความจำเป็นในการทำเช่นนี้หรือไม่
ความต้องการดังกล่าวไม่ค่อยเกิดขึ้น ในปริมาณงานส่วนใหญ่ เคอร์เนลทำงานได้ดีมาก แม้ว่าจะมีข้อเสีย ในอดีต เคอร์เนลของลีนุกซ์เต็มใจที่จะใช้หน่วยความจำจำนวนมากหากได้รับโอกาส รวมถึงการแคชเป็นวิธีหลักในการปรับปรุงประสิทธิภาพ
ในกรณีส่วนใหญ่ วิธีนี้ใช้ได้ดี แต่ภายใต้ภาระหนักอาจทำให้เกิดปัญหาได้
เรามีประสบการณ์มากมายกับระบบที่ใช้หน่วยความจำมากเช่น CAD, EDA และอื่น ๆ ซึ่งเริ่มทำงานช้าลงภายใต้ภาระงานจำนวนมาก และบางครั้งเราก็พบปัญหาใน Gluster หลังจากสังเกตการใช้หน่วยความจำและเวลาแฝงของดิสก์อย่างรอบคอบเป็นเวลาหลายวัน เราก็พบว่ามีโอเวอร์โหลด iowait ขนาดใหญ่ เคอร์เนลผิดพลาด (เคอร์เนลโอ๊ะ) ค้าง ฯลฯ
บทความนี้เป็นผลมาจากการทดลองปรับแต่งหลายครั้งในสถานการณ์ต่างๆ ต้องขอบคุณพารามิเตอร์เหล่านี้ ไม่เพียงแต่การตอบสนองโดยรวมจะดีขึ้นเท่านั้น แต่คลัสเตอร์ก็มีความเสถียรอย่างมากเช่นกัน
เมื่อพูดถึงการปรับแต่งหน่วยความจำ สิ่งแรกที่ต้องดูคือระบบย่อยหน่วยความจำเสมือน (VM, หน่วยความจำเสมือน) ซึ่งมีตัวเลือกมากมายที่อาจทำให้คุณสับสน
vm.swappiness
พารามิเตอร์ vm.swappiness กำหนดว่าเคอร์เนลใช้ swap (swap, paging) มากน้อยเพียงใดเมื่อเทียบกับ RAM มันถูกกำหนดไว้ในซอร์สโค้ดว่า "แนวโน้มที่จะขโมยหน่วยความจำที่แมป" ความรวดเร็วสูงหมายความว่าเคอร์เนลจะมีแนวโน้มที่จะสลับหน้าที่แมป ค่า Swapness ต่ำหมายถึงตรงกันข้าม เคอร์เนลจะเพจน้อยลงจากหน่วยความจำ กล่าวอีกนัยหนึ่งมูลค่าที่สูงขึ้น vm.swappinessยิ่งระบบจะใช้ swap มากเท่าไร
การใช้การแลกเปลี่ยนจำนวนมากเป็นสิ่งที่ไม่พึงปรารถนา เนื่องจากบล็อกข้อมูลจำนวนมากถูกโหลดและยกเลิกการโหลดลงใน RAM หลายคนแย้งว่าค่า swapiness ควรมีค่ามาก แต่จากประสบการณ์ของฉัน การตั้งค่าเป็น "0" จะทำให้ประสิทธิภาพดีขึ้น
คุณสามารถอ่านเพิ่มเติมได้ที่นี่ -
แต่อีกครั้ง ควรใช้การตั้งค่าเหล่านี้ด้วยความระมัดระวังและหลังจากทดสอบแอปพลิเคชันเฉพาะแล้วเท่านั้น สำหรับแอปพลิเคชันการสตรีมที่มีโหลดสูง ควรตั้งค่าพารามิเตอร์นี้เป็น "0" เมื่อเปลี่ยนเป็น "0" การตอบสนองของระบบจะดีขึ้น
vm.vfs_cache_pressure
การตั้งค่านี้ควบคุมหน่วยความจำที่ใช้โดยเคอร์เนลสำหรับการแคชไดเร็กทอรีและอ็อบเจ็กต์ inode (dentry และ inode)
ด้วยค่าดีฟอลต์ที่ 100 เคอร์เนลจะพยายามทำให้แคช dentry และ inode ว่างบนพื้นฐาน "ยุติธรรม" สำหรับ pagecache และ swapcache การลด vfs_cache_pressure ทำให้เคอร์เนลเก็บแคช dentry และ inode เมื่อค่าเป็น "0" เคอร์เนลจะไม่ล้างแคชของเดนทรีและไอโหนดเนื่องจากแรงดันหน่วยความจำ และสิ่งนี้สามารถนำไปสู่ข้อผิดพลาดหน่วยความจำไม่เพียงพอได้อย่างง่ายดาย การเพิ่ม vfs_cache_pressure มากกว่า 100 ทำให้เคอร์เนลจัดลำดับความสำคัญของการล้างข้อมูลแบบเดนทรีและไอโหนด
เมื่อใช้ GlusterFS ผู้ใช้จำนวนมากที่มีข้อมูลจำนวนมากและไฟล์ขนาดเล็กจำนวนมากสามารถใช้ RAM จำนวนมากบนเซิร์ฟเวอร์ได้อย่างง่ายดายเนื่องจากการแคชแบบ inode/dentry ซึ่งอาจนำไปสู่การลดประสิทธิภาพเนื่องจากเคอร์เนลต้องประมวลผลโครงสร้างข้อมูลในระบบ พร้อมหน่วยความจำ 40 GB การตั้งค่านี้สูงกว่า 100 ช่วยให้ผู้ใช้จำนวนมากได้รับแคชที่ยุติธรรมยิ่งขึ้นและปรับปรุงการตอบสนองของเคอร์เนล
vm.dirty_background_ratio และ vm.dirty_ratio
พารามิเตอร์แรก (vm.dirty_background_ratio) กำหนดเปอร์เซ็นต์ของหน่วยความจำที่มีเพจสกปรก หลังจากเข้าถึงแล้วจำเป็นต้องเริ่มล้างเพจสกปรกในพื้นหลังไปยังดิสก์ จนกว่าจะถึงเปอร์เซ็นต์นี้ จะไม่มีการล้างเพจไปยังดิสก์ และเมื่อการรีเซ็ตเริ่มต้นขึ้น การรีเซ็ตจะทำงานในเบื้องหลังโดยไม่ขัดจังหวะกระบวนการทำงาน
พารามิเตอร์ที่สอง (vm.dirty_ratio) กำหนดเปอร์เซ็นต์ของหน่วยความจำที่สามารถครอบครองโดยหน้าสกปรกก่อนที่จะเริ่มบังคับแฟลช เมื่อถึงเกณฑ์นี้ กระบวนการทั้งหมดจะซิงโครนัส (ถูกบล็อก) และไม่ได้รับอนุญาตให้ดำเนินการต่อจนกว่า I/O ที่ร้องขอจะเสร็จสมบูรณ์จริง ๆ และข้อมูลอยู่ในดิสก์ ด้วย I/O จำนวนมาก สิ่งนี้ทำให้เกิดปัญหาเนื่องจากไม่มีการแคชข้อมูล และกระบวนการทั้งหมดที่ทำ I/O จะถูกบล็อกเพื่อรอ I/O สิ่งนี้นำไปสู่กระบวนการหยุดทำงานจำนวนมาก โหลดสูง ระบบไม่เสถียร และประสิทธิภาพต่ำ
การลดการตั้งค่าเหล่านี้จะทำให้ข้อมูลถูกล้างลงดิสก์บ่อยขึ้นและไม่ได้จัดเก็บไว้ใน RAM สิ่งนี้สามารถช่วยให้ระบบที่ใช้หน่วยความจำสูงซึ่งเป็นเรื่องปกติที่จะล้างแคชเพจ 45-90 GB ลงในดิสก์ ส่งผลให้แอปพลิเคชันส่วนหน้ามีความหน่วงแฝงมาก ลดการตอบสนองและการโต้ตอบโดยรวม
"1"> /proc/sys/vm/pagecache
แคชเพจคือแคชที่เก็บข้อมูลของไฟล์และโปรแกรมปฏิบัติการ นั่นคือเพจเหล่านี้มีเนื้อหาจริงของไฟล์หรืออุปกรณ์บล็อก แคชนี้ใช้เพื่อลดจำนวนการอ่านดิสก์ ค่า "1" หมายความว่า 1% ของ RAM ใช้สำหรับแคช และจะมีการอ่านจากดิสก์มากกว่าจาก RAM ไม่จำเป็นต้องเปลี่ยนการตั้งค่านี้ แต่หากคุณหวาดระแวงเกี่ยวกับการควบคุมแคชของเพจ คุณก็สามารถใช้ได้
"กำหนดเวลา" > /sys/block/sdc/queue/scheduler
ตัวกำหนดตารางเวลา I/O เป็นคอมโพเนนต์เคอร์เนลของ Linux ที่จัดการคิวการอ่านและการเขียน ตามทฤษฎีแล้ว ควรใช้ "noop" สำหรับ smart RAID controller เนื่องจาก Linux ไม่รู้อะไรเกี่ยวกับรูปทรงเรขาคณิตของดิสก์ ดังนั้นการปล่อยให้คอนโทรลเลอร์ซึ่งรู้จักรูปทรงของดิสก์เป็นอย่างดีประมวลผลคำขอได้เร็วเท่ากับ เป็นไปได้. แต่ดูเหมือนว่า "เส้นตาย" จะปรับปรุงประสิทธิภาพ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับตัวกำหนดตารางเวลาได้ในเอกสารซอร์สโค้ดของเคอร์เนล Linux: linux/Documentation/block/*osched.txt. และฉันยังเห็นการเพิ่มขึ้นของความเร็วในการอ่านระหว่างการดำเนินการแบบผสม (การดำเนินการเขียนจำนวนมาก)
"256" > /sys/block/sdc/queue/nr_requests
จำนวนคำขอ I/O ในบัฟเฟอร์ก่อนที่จะส่งไปยังตัวกำหนดตารางเวลา ขนาดคิวภายในของตัวควบคุมบางตัว (queue_ความลึก) มีขนาดใหญ่กว่า nr_requests ของตัวกำหนดตารางเวลา I/O ดังนั้นตัวกำหนดตารางเวลา I/O จึงมีโอกาสน้อยที่จะจัดลำดับความสำคัญและรวมคำขออย่างเหมาะสม สำหรับตัวกำหนดเส้นตายและ CFQ จะดีกว่าเมื่อ nr_requests เป็น 2 เท่าของคิวภายในของตัวควบคุม คำขอการผสานและการจัดลำดับใหม่ช่วยให้ตัวกำหนดตารางเวลาตอบสนองได้ดีขึ้นภายใต้ภาระงานจำนวนมาก
echo "16" > /proc/sys/vm/page-cluster
พารามิเตอร์ page-cluster ควบคุมจำนวนหน้าที่เขียนไปยัง swap ในครั้งเดียว ในตัวอย่างข้างต้น ค่านี้ถูกกำหนดเป็น "16" ตามขนาดแถบ RAID ที่ 64 KB มันไม่สมเหตุสมผลกับความรวดเร็ว = 0 แต่ถ้าคุณตั้งค่าความรวดเร็วเป็น 10 หรือ 20 การใช้ค่านี้จะช่วยคุณได้เมื่อขนาดแถบ RAID เป็น 64K
blockdev --setra 4096 /dev/<ชื่อผู้พัฒนา> (-sdb, hdc หรือ dev_mapper)
การตั้งค่าอุปกรณ์บล็อกเริ่มต้นสำหรับคอนโทรลเลอร์ RAID จำนวนมากมักส่งผลให้ประสิทธิภาพการทำงานแย่มาก การเพิ่มตัวเลือกข้างต้นจะตั้งค่าการอ่านล่วงหน้าสำหรับเซ็กเตอร์ 4096 * 512 ไบต์ อย่างน้อยที่สุด สำหรับการสตรีม ความเร็วจะเพิ่มขึ้นโดยการเติมดิสก์แคชบนชิปด้วยการอ่านล่วงหน้าในช่วงที่เคอร์เนลใช้เพื่อเตรียม I/O แคชสามารถมีข้อมูลที่จะร้องขอในการอ่านครั้งต่อไป การดึงข้อมูลล่วงหน้ามากเกินไปอาจทำให้ I/O แบบสุ่มไม่ทำงานสำหรับไฟล์ขนาดใหญ่ หากใช้เวลาดิสก์ที่อาจเป็นประโยชน์หมดไปหรือโหลดข้อมูลนอกแคช
ด้านล่างนี้เป็นคำแนะนำเพิ่มเติมเล็กน้อยในระดับระบบไฟล์ แต่ยังไม่ได้รับการทดสอบ ตรวจสอบให้แน่ใจว่าระบบไฟล์ของคุณทราบขนาดของแถบและจำนวนดิสก์ในอาร์เรย์ ตัวอย่างเช่น นี่คืออาร์เรย์ 5K Stripe Raid64 ของดิสก์ XNUMX ตัว (จริง ๆ แล้ว XNUMX ตัว เนื่องจากใช้ดิสก์ XNUMX ตัวสำหรับพาริตี) คำแนะนำเหล่านี้อิงตามสมมติฐานทางทฤษฎีและรวบรวมจากบล็อก/บทความต่างๆ โดยผู้เชี่ยวชาญ RAID
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))สำหรับไฟล์ขนาดใหญ่ ให้พิจารณาเพิ่มขนาดแถบที่แสดงด้านบน
คำเตือน! ทุกสิ่งที่อธิบายไว้ข้างต้นเป็นเรื่องส่วนตัวสำหรับแอปพลิเคชันบางประเภท บทความนี้ไม่รับประกันการปรับปรุงใด ๆ หากไม่มีการทดสอบแอปพลิเคชันที่เกี่ยวข้องล่วงหน้าโดยผู้ใช้ ควรใช้เฉพาะเมื่อจำเป็นในการปรับปรุงการตอบสนองโดยรวมของระบบ หรือหากต้องการแก้ปัญหาปัจจุบัน
วัสดุเพิ่มเติม:
อ่านเพิ่มเติม
ที่มา: will.com