Linux - การปรับแต่ง RAID คอนโทรลเลอร์สำหรับฮาร์ดแวร์ในโลกแห่งความเป็นจริง (scsi และ cciss)

ระบบลีนุกซ์ส่วนใหญ่ที่ฉันจัดการจะมีคอนโทรลเลอร์ RAID สำหรับฮาร์ดแวร์ (ส่วนใหญ่เป็นHP Smart Array ) พวกเขากำลังทำงาน RHEL หรือ CentOS ทั้งหมด

ฉันกำลังมองหาที่ปรับได้ในโลกแห่งความจริงเพื่อช่วยเพิ่มประสิทธิภาพการตั้งค่าที่รวมตัวควบคุม RAID ของฮาร์ดแวร์ด้วยดิสก์ SAS (สมาร์ทอาเรย์, Perc, LSI, ฯลฯ ) และแคชสำรองแบตเตอรี่หรือแฟลชสำรอง สมมติว่า RAID 1 + 0 และแกนหมุนหลายอัน (4+ ดิสก์)

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

ในอดีตฉันได้ทำการเปลี่ยนแปลงการจัดตารางเวลา I / Oเมื่อเร็ว ๆ นี้การเลือกdeadlineและตัวตั้งnoopเวลาเพื่อปรับปรุงประสิทธิภาพภายในแอปพลิเคชันของฉัน เมื่อเวอร์ชัน RHEL ดำเนินไปฉันได้สังเกตเห็นว่าค่าเริ่มต้นที่คอมไพล์แล้วสำหรับอุปกรณ์บล็อก SCSI และ CCISS ก็เปลี่ยนไปเช่นกัน สิ่งนี้มีผลกระทบต่อการตั้งค่าระบบย่อยหน่วยเก็บข้อมูลที่แนะนำเมื่อเวลาผ่านไป อย่างไรก็ตามมันไม่นานมานี้ตั้งแต่ฉันเห็นคำแนะนำที่ชัดเจน และฉันรู้ว่าค่าเริ่มต้นของระบบปฏิบัติการนั้นไม่ดีที่สุด ตัวอย่างเช่นดูเหมือนว่าบัฟเฟอร์การอ่านล่วงหน้าเริ่มต้นที่ 128kb นั้นมีขนาดเล็กมากสำหรับการปรับใช้กับฮาร์ดแวร์ระดับเซิร์ฟเวอร์

บทความต่อไปนี้สำรวจผลกระทบด้านประสิทธิภาพของการเปลี่ยนแคชแบบอ่านล่วงหน้าและค่าnr_requestsในคิวบล็อก

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux- เหตุผลที่ต้องปรับแต่ง - สำคัญมาก ๆ
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

ตัวอย่างเช่นสิ่งเหล่านี้เป็นการเปลี่ยนแปลงที่แนะนำสำหรับตัวควบคุม HP Smart Array RAID:

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

มีอะไรอีกบ้างที่สามารถปรับได้อย่างน่าเชื่อถือเพื่อปรับปรุงประสิทธิภาพการจัดเก็บ?
ฉันกำลังมองหาตัวเลือก sysctl และ sysfs โดยเฉพาะในสถานการณ์การผลิต

ฉันพบว่าเมื่อฉันต้องปรับแต่งเพื่อลดความหน่วงแฝงเทียบกับปริมาณงานฉันได้ปรับ nr_requests ลงจากค่าเริ่มต้น (เป็นต่ำถึง 32) ความคิดที่เป็นชุดเล็กลงเท่ากับเวลาแฝงที่ต่ำกว่า

สำหรับ read_ahead_kb ฉันพบว่าสำหรับการอ่าน / เขียนตามลำดับการเพิ่มค่านี้ให้ปริมาณงานที่ดีขึ้น แต่ฉันพบว่าตัวเลือกนี้ขึ้นอยู่กับปริมาณงานและรูปแบบ IO ของคุณ ตัวอย่างเช่นในระบบฐานข้อมูลที่ฉันเพิ่งปรับไปฉันเปลี่ยนค่านี้ให้ตรงกับขนาดหน้า db เดียวซึ่งช่วยลดเวลาในการตอบสนองการอ่าน การเพิ่มหรือลดลงเกินกว่าค่านี้ได้พิสูจน์แล้วว่ากระทบต่อประสิทธิภาพในกรณีของฉัน

สำหรับตัวเลือกหรือการตั้งค่าอื่น ๆ สำหรับคิวอุปกรณ์บล็อก:

max_sectors_kb = ฉันได้ตั้งค่านี้ให้ตรงกับสิ่งที่ฮาร์ดแวร์อนุญาตสำหรับการถ่ายโอนครั้งเดียว (ตรวจสอบค่าของไฟล์ max_hw_sectors_kb (RO) ใน sysfs เพื่อดูสิ่งที่ได้รับอนุญาต)

nomerges = สิ่งนี้ช่วยให้คุณปิดการใช้งานหรือปรับตรรกะการค้นหาสำหรับการรวมคำขอ io (การปิดตัวเลือกนี้สามารถช่วยคุณประหยัด cpu cycles ได้บ้าง แต่ฉันไม่เห็นประโยชน์ใด ๆ เมื่อทำการเปลี่ยนแปลงสิ่งนี้สำหรับระบบของฉันดังนั้นฉันจึงปล่อยให้เป็นค่าเริ่มต้น)

rq_affinity = ฉันยังไม่ได้ลองสิ่งนี้ แต่นี่คือคำอธิบายที่มาจากเคอร์เนลเอกสาร

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

scheduler = คุณบอกว่าคุณลองกำหนดเวลาและ noop ฉันได้ทดสอบทั้ง noop และ deadline แต่พบว่า winline win's out สำหรับการทดสอบที่ฉันทำล่าสุดสำหรับเซิร์ฟเวอร์ฐานข้อมูล

NOOP ทำงานได้ดี แต่สำหรับเซิร์ฟเวอร์ฐานข้อมูลของเราฉันยังคงสามารถปรับประสิทธิภาพกำหนดเวลาได้ดีขึ้น

ตัวเลือกสำหรับตัวกำหนดเวลาที่กำหนดเวลาอยู่ภายใต้ / sys / block / {sd, cciss, dm -} * / queue / iosched /:

fifo_batch = ชนิดของ like nr_requests แต่เฉพาะกับตัวกำหนดตารางเวลา กฎของหัวแม่มือคือการปรับนี้ลงเพื่อลดความหน่วงหรือเพิ่มขึ้นสำหรับปริมาณงาน ควบคุมขนาดแบตช์ของคำร้องขอการอ่านและเขียน

write_expire = ตั้งเวลาหมดอายุสำหรับการเขียนแบตช์เริ่มต้นคือ 5000ms การลดค่านี้อีกครั้งจะลดความหน่วงในการเขียนของคุณในขณะที่เพิ่มค่าจะเพิ่มปริมาณงาน

read_expire = ตั้งค่าเวลาหมดอายุสำหรับการอ่านแบตช์ที่เป็นค่าเริ่มต้นคือ 500ms ใช้กฎเดียวกันกับที่นี่

front_merges = ฉันมีแนวโน้มที่จะปิดและมันเปิดอยู่ตามค่าเริ่มต้น ฉันไม่เห็นความต้องการตัวกำหนดตารางเวลาในการสิ้นเปลือง cpu cycles ที่พยายามรวมการร้องขอ IO

writes_starved = เนื่องจากกำหนดเวลาจะมุ่งไปที่การอ่านค่าเริ่มต้นที่นี่คือการประมวลผล 2 อ่านแบตช์ก่อนที่จะประมวลผลแบทช์การเขียน ฉันพบว่าค่าเริ่มต้นของ 2 จะดีสำหรับภาระงานของฉัน

ยิ่งกว่าสิ่งใดทุกอย่างขึ้นอยู่กับปริมาณงานของคุณ

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

nr_requestsเมื่อ overtuned สามารถทำให้ RAID คอนโทรลเลอร์ของคุณท่วมได้ง่ายซึ่งทำให้ประสิทธิภาพลดลงอีกครั้ง

ในโลกแห่งความจริงที่คุณต้องดูศักยภาพ หากคุณกำลังเชื่อมต่อกับ SAN ให้ดูด้วยiostat, sarหรือสิ่งที่คุณชอบที่จะใช้และดูว่า I / O ขอเวลาบริการผ่านหลังคา แน่นอนว่าสิ่งนี้จะช่วยดิสก์ในเครื่องด้วยเช่นกัน: หากเวลาในการตอบสนองมีขนาดใหญ่มากลองปรับการตั้งค่าลิฟท์ I / O ของคุณโดยปรับลด max_requests และการตั้งค่าอื่น ๆ

FYI read_ahead_kbและblockdev --setraเป็นเพียงวิธีที่แตกต่างกันในการตั้งค่าเดียวกันโดยใช้หน่วยที่แตกต่างกัน (kB กับภาค):

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

ดังนั้น

blockdev --setra 65536 /dev/cciss/c0d0

ในตัวอย่างของคุณไม่มีผลกระทบ