- พารามิเตอร์พื้นฐานของ ZFS ถูกตั้งมาเป็นค่าประนีประนอมระหว่างการเข้าถึงแบบลำดับและแบบสุ่ม
- หากรู้ลักษณะของเวิร์กโหลดอย่างชัดเจน ก็สามารถจูนให้ดุดันมากขึ้นได้
- อธิบายความแตกต่างระหว่างการเข้าถึงแบบลำดับ vs การเข้าถึงแบบสุ่ม
- HDD มีประสิทธิภาพการเข้าถึงแบบสุ่มช้ากว่าแบบลำดับได้ตั้งแต่หลายสิบถึงหลายร้อยเท่า เพราะต้องขยับหัวอ่าน
- SSD แม้จะทำให้การเข้าถึงแบบสุ่มเร็วขึ้นมาก แต่การเข้าถึงแบบลำดับก็ยังมีประสิทธิภาพกว่าอยู่ดี
- เวิร์กโหลดที่อ่านไฟล์ขนาดใหญ่ตามลำดับจะมีลักษณะเอนเอียงไปทางการเข้าถึงแบบลำดับ
- เวิร์กโหลดที่อ่านไฟล์ขนาดเล็กหลายไฟล์บ่อย ๆ มักมีแนวโน้มเป็นการเข้าถึงแบบสุ่มสูง
- แนะนำวิธีวิเคราะห์เวิร์กโหลด
- อนุมานเชิงตรรกะจากโค้ด/โครงสร้าง
- คำนวณขนาด IO เฉลี่ยจาก throughput (bps) + จำนวน IO ต่อวินาที (iops)
- วิเคราะห์การกระจายของขนาด IO ด้วย
zpool iostat -r
- การตีความ
zpool iostat -r
ind: ขนาดของคำขอเชิงตรรกะแต่ละรายการagg: ขนาด IO จริงที่ถูกควบรวมแล้วและนำไปประมวลผล- หาก
agg ใหญ่กว่า ind แปลว่าการรวม IO ที่อยู่ติดกันทำได้ดี
- ผลการวิเคราะห์เวิร์กโหลดตัวอย่าง
- สัดส่วนการอ่านแบบ synchronous ประมาณ 76%
- การอ่านขนาด 32KiB หรือน้อยกว่าคิดเป็นมากกว่า 99%
- การเขียนแบบ asynchronous ก็มีสัดส่วนของ IO ขนาดเล็กสูงเช่นกัน
- โดยรวมเป็นเวิร์กโหลดที่มีลักษณะการเข้าถึงแบบสุ่มสูงมาก
zfs_prefetch_disable
- ZFS จะตรวจจับแพตเทิร์นการเข้าถึงแบบลำดับ แล้วโหลดบล็อกข้างเคียงเข้า ARC ล่วงหน้า
- ในเวิร์กโหลดแบบสุ่ม อัตราการ hit ของการ prefetch มักต่ำ จนอาจเพิ่ม IO ที่ไม่จำเป็น
- สามารถวัดประสิทธิภาพของ prefetch ได้ด้วย
arc_summary
- หากอัตราการ hit ต่ำ ก็อาจพิจารณา
zfs_prefetch_disable ได้
recordsize
- ค่าเริ่มต้นคือ 128K
- ในเวิร์กโหลดตัวอย่าง IO ส่วนใหญ่มีขนาดไม่เกิน 32KiB จึงอาจพิจารณาใช้
recordsize ที่เล็กลง
- การเลือกค่าที่เหมาะสมที่สุด
- สิ่งสำคัญคือต้องตัดสินใจจากการทำ benchmark
- ฐานข้อมูลอย่าง MySQL/Postgres มีกรณีการจูนที่ผ่านการพิสูจน์แล้วอยู่มาก
- โดยทั่วไปมักใช้
recordsize ที่ใกล้เคียงกับขนาด page ของฐานข้อมูล
ยังไม่มีความคิดเห็น