ความสัมพันธ์ระหว่างดิสก์ IOPS และ sar tps


13

ฉันพยายามประเมินความต้องการของ IOPS ของแอปพลิเคชันของฉันที่ทำงานบน CentOS 6.2 แบบ 32 บิต ฉันเริ่มทำการวัดบนเครื่องที่มีดิสก์ SATA และฉันค่อนข้างสับสนกับความแตกต่างระหว่าง IOPS และ tps ที่วัดโดย sar

ตามดิสก์วิกิพีเดีย SATA ควรดำเนินการ 75-100 IOPS ยูทิลิตี้ iopingดูเหมือนจะยืนยันสิ่งนี้สำหรับการทดสอบการเข้าถึงแบบสุ่ม

# ./ioping -R /dev/sda
--- /dev/sda (device 931.0 Gb) ioping statistics ---
279 requests completed in 3.0 s, 92 iops, 371.3 kb/s
min/avg/max/mdev = 2.7 ms / 10.8 ms / 130.8 ms / 7.9 ms

แต่ค่า tps ที่สร้างโดย sar นั้นสูงกว่ามาก (/ dev / sda):

# iostat 1
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       0.17    0.00    2.02   14.86    0.00   82.96

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             559.00         0.00    142600.00          0     142600
dm-0          18433.00         0.00    147464.00          0     147464
dm-1              0.00         0.00         0.00          0          0
dm-2              0.00         0.00         0.00          0          0

ไม่คิดจริง ๆ ว่าการโหลดนี้เป็นแบบลำดับ (dd ที่มีขนาดบล็อกต่าง ๆ ) หรือการเข้าถึงแบบสุ่ม (ioping) ค่ายังคงเหมือนเดิม ฉันคิดว่าจริง ๆ แล้ว tps คือ IOPS และฉันคาดหวังว่ามันจะลดลงเมื่อถ่ายโอนชิ้นใหญ่

ดังนั้นค่า tps หมายความว่าอย่างไร และเกี่ยวข้องกับ IOPS อย่างไร


2
ฉันเชื่อว่าคุณเห็น IOPS ที่สูงขึ้นในค่า TPS เนื่องจากดิสก์แคช
ceejayoz

1
ตกลงฉันลองไฟล์ 10GB ผ่าน dd ด้วย 256kB block เพื่อเติมแคชจริงและหลังจากนั้นประมาณ 90 วินาทีต่อวินาทีลดลงเหลือ ~ 200 ดังนั้นคุณอาจจะถูก แต่ยังคง 80 และ 200 ค่อนข้างแตกต่าง ... เป็นไปได้ไหมว่าการอ่านและเขียน IOPS นั้นแตกต่างกัน? และมีวิธีใดในการหา IOPS ที่ต้องการจากค่านี้
pystole

1
คุณช่วยอธิบายได้ไหมว่าทำไมคุณถึงอยู่หลัง IOPS? การอ่านและการเขียนเป็นรองเท้าที่แตกต่างกันมากที่ถูกโยนลงไปในหม้อเดียวกันที่นี่
นิลส์

เหตุผลก็คือฉันต้องอธิบายข้อกำหนด HW ขั้นต่ำ ฉันมีเซิร์ฟเวอร์ที่รับข้อมูลผ่านเครือข่าย (เราสามารถสมมติบิตเรตคงที่ที่นี่) และเขียนข้อมูลที่ได้รับไปยังดิสก์ ข้อมูลถูกเขียนไปยังไฟล์ตามลำดับ แต่อาจมีหลายร้อย (เช่น 800) ไฟล์ในแบบคู่ขนาน ฉันพบว่าเมื่อมีลูกค้าจำนวนหนึ่งมาถึงจุดหนึ่ง ปริมาณงานที่แท้จริงของดิสก์ที่ฉันสามารถทำได้ประมาณ 25MB / s ซึ่งค่อนข้างต่ำลูกค้าน้อยที่มีบิตเรตที่สูงกว่าสามารถทำได้ 35MB / s ตามลำดับบริสุทธิ์ประมาณ 130MB / s ดังนั้นฉันเดา IOPS เป็นสิ่งที่สำคัญที่นี่ ...
pystole

คำตอบ:


6

ธุรกรรมคือคำสั่ง IO เดียว (เรียกบล็อก / เขียนบล็อก) ที่เขียนไปยังดิสก์ RAW (ในตัวอย่างของคุณ dm-0) เคอร์เนล linux พยายามเรียงลำดับคำสั่งเหล่านั้นให้เป็นลำดับที่ดีขึ้นหรือพยายามบีบอัดคำสั่งที่มีประสิทธิภาพมากขึ้น (เช่น: รับสองบล็อกพร้อมกันแทนที่จะได้รับหนึ่งบล็อกและรับบล็อกอื่นหลังจากนี้) นี่เป็นธุรกรรมที่ออกไปยังตัวควบคุมดิสก์ (tps สำหรับ sda)

ตัวควบคุมที่ดีนั้นมีตรรกะของตัวเองซึ่งจะลดจำนวนการทำธุรกรรมจริงได้อีก

ธุรกรรมอาจเป็นคำสั่ง SCSI "เขียน 2 GB ไปยัง crontoller 1 เป้าหมาย 2 lun 3 เริ่มต้นจากเซกเตอร์ 22) ในขณะที่คุณสามารถเห็นสิ่งนี้ไม่สามารถนำมาสัมพันธ์โดยตรงกับจำนวนผลผลิต

สิ่งที่คุณทำหลังจากนั้นคืออัตราการเขียนที่ยั่งยืน คุณมีปัจจัยที่ จำกัด อยู่ที่นี่:

  • การเชื่อมต่อไคลเอนต์: หากเครือข่ายเป็นกิกะบิตคุณจะไม่มีอินพุตมากกว่า 100 MB / s
  • ตัวควบคุมดิสก์: หากเป็นตัวควบคุม 3 Gb คุณจะไม่ได้รับปริมาณงานมากกว่า 300 MB / s
  • ดิสก์: ค้นหาค่าผู้ผลิตสำหรับประสิทธิภาพการเขียนที่ยั่งยืน
  • ระบบไฟล์: มีค่าใช้จ่ายเล็กน้อยเนื่องจากระบบปฏิบัติการต้องการประมวลผลข้อมูล - ทดสอบว่าใน RAM- ดิสก์ ...

สิ่งที่ฉันคาดเดาสำหรับระบบของคุณคือรับตัวควบคุมการจู่โจมฮาร์ดแวร์ที่ดีที่สามารถทำ RAID 10 หรือ 5 และรับดิสก์อย่างรวดเร็ว 6 (15k) อย่างน้อย 6 ตัว

สำหรับมืออาชีพให้ใช้ SAS แทน SATA


โอเคคุณพูดถูก IOPS ไม่มีเหตุผลสำหรับการเขียนเนื่องจากมีแคชจำนวนมากเรียงลำดับใหม่และรวมเข้าด้วยกัน ปิด ... ขอบคุณ
pystole

5

โปรดทราบว่าTPSค่าแสดงถึงการอ่านและการเขียนคุณสามารถใช้-xสวิตช์สำหรับมุมมองแบบขยายที่การอ่านและการเขียนแยกกัน (r / s = read IOPS, w / s = write IOPS):

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
vda               0.07    24.65    0.30   18.95    30.65   330.22    18.74     0.07    3.61   0.98   1.89

ใช่คุณถูก. แต่ในกรณีของฉันมีเกือบ 100% ของการเขียนอ่านไม่ได้เลย
pystole
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.