ฉันเห็นคำสั่งเพื่อเปรียบเทียบ HDD ของคนเช่นนี้โดยใช้dd:
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"
มีวิธีที่ดีกว่านี้หรือไม่?
คำตอบ:
ฉันมักจะใช้hdparmเป็นเกณฑ์มาตรฐาน HDD ของฉัน คุณสามารถสร้างมาตรฐานทั้งการอ่านโดยตรงและการอ่านแคช คุณจะต้องเรียกใช้คำสั่งสองสามครั้งเพื่อสร้างค่าเฉลี่ย
นี่คือการอ่านโดยตรง
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
และนี่คือการอ่านแคช
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading through the buffer cache to the disk without
any prior caching of data. This measurement is an indication of how
fast the drive can sustain sequential data reads under Linux, without
any filesystem overhead. To ensure accurate measurements, the
buffer cache is flushed during the processing of -t using the
BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes.
For meaningful results, this operation should be repeated 2-3
times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading directly from the Linux buffer cache without
disk access. This measurement is essentially an indication of the
throughput of the processor, cache, and memory of the system under
test.
ฉันก็ใช้ddการทดสอบประเภทนี้เช่นกัน การดัดแปลงหนึ่งที่ฉันจะทำกับคำสั่งด้านบนคือการเพิ่มบิตนี้ที่ส่วนท้ายของคำสั่งของคุณ, ; rm ddfile.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
นี่จะเป็นการลบddfileคำสั่งหลังจากคำสั่งเสร็จสิ้น หมายเหตุ: ddfileเป็นไฟล์ชั่วคราวที่คุณไม่ต้องการเก็บไว้เป็นไฟล์ที่ddเขียนถึง ( of=ddfile) เมื่อวาง HDD ของคุณไว้ในโหลด
หากคุณต้องการการทดสอบ HDD ที่เข้มงวดมากขึ้นคุณสามารถใช้Bonnie ++ได้
hdparmเช่นกันสำหรับการวัดผลด่วน ข้อเสียเพียงอย่างเดียวคือมันเป็นเพียงมาตรฐานในการอ่านแบนด์วิดธ์และประสิทธิภาพของอุปกรณ์บล็อกหลายประเภท (เช่น RAID, iSCSI) อาจไม่สมดุลกันมาก สำหรับการเปรียบเทียบประสิทธิภาพ 'ก่อน' และ 'หลังจาก' ในกล่องเดียวกันddทำงานได้ดีเช่นกัน
hdparm+ ddหรือเพียงแค่bonnie++หรือทั้งหมด 3.
(นี่เป็นคำถามที่นิยมมาก - คุณสามารถดูรูปแบบของมันได้ที่https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726และhttps://askubuntu.com/q / 87035/740413 )
มีวิธีที่ดีกว่า [ดีกว่าวัน] เป็น [มาตรฐานดิสก์] หรือไม่?
ใช่ แต่พวกเขาจะใช้เวลานานในการรันและต้องการความรู้ในการตีความผลลัพธ์ - ไม่มีหมายเลขเดียวที่จะบอกคุณทุกอย่างในครั้งเดียวเพราะสิ่งต่อไปนี้มีอิทธิพลต่อประเภทของการทดสอบที่คุณควรใช้:
และอื่น ๆ
นี่คือรายการสั้น ๆ ของเครื่องมือที่ง่ายที่สุดที่จะเรียกใช้ที่ด้านบนและยาก / ละเอียดมากขึ้น / ดีขึ้นใกล้ด้านล่าง:
Greg - รับรหัส FIO ของ Jens มันทำสิ่งที่ถูกต้องรวมถึงการเขียนเนื้อหาหลอกแบบสุ่มจริงซึ่งแสดงว่าดิสก์ทำ "de-ซ้ำซ้อน" (aka "ปรับให้เหมาะสมสำหรับการวัดประสิทธิภาพ):
[ https://github.com/axboe/fio/ ]
มีอะไรสงสัย - ลืมเกี่ยวกับบอนนี่หรือเครื่องมือดั้งเดิมอื่น ๆ
ที่มา: แสดงความคิดเห็นทางด้านซ้ายบน Google Plus เกร็ก Kroah-ฮาร์ทแมนโดย Linus Torvalds
ถ้าคุณไม่ได้ใส่ใจที่จะอ่านทั้งหมดนี้ฉันต้องการเพียงแค่แนะนำเครื่องมือ IOPS มันจะบอกคุณความเร็วจริงในโลกขึ้นอยู่กับขนาดบล็อก
มิฉะนั้น - เมื่อทำเกณฑ์มาตรฐาน IO ฉันจะดูสิ่งต่อไปนี้:
การใช้งาน CPU
คุณจะใช้ขนาดบล็อกแบบใด : หากคุณต้องการอ่าน / เขียน 1 GB จาก / ไปยังดิสก์นี่จะรวดเร็วหากคุณดำเนินการ I / O ครั้งเดียว แต่ถ้าแอปพลิเคชันของคุณต้องการเขียน 512 ไบต์ในฮาร์ดดิสในส่วนที่ไม่ต่อเนื่อง (เรียกว่าสุ่ม I / O แม้ว่ามันจะไม่สุ่ม) สิ่งนี้จะดูแตกต่างกัน ตอนนี้จะทำฐานข้อมูลแบบสุ่ม I / O สำหรับไดรฟ์ข้อมูลและลำดับของ I / O สำหรับปริมาณการล็อกเนื่องจากธรรมชาติของพวกเขา ดังนั้นก่อนอื่นคุณต้องชัดเจนว่าคุณต้องการวัดอะไร หากคุณต้องการคัดลอกไฟล์วิดีโอขนาดใหญ่ที่แตกต่างจากถ้าคุณต้องการติดตั้ง Linux
ขนาดบล็อกนี้ส่งผลต่อการนับการดำเนินการ I / O ที่คุณทำ หากคุณทำเช่นการอ่าน (หรือเขียนแบบเรียงลำดับ 8 ครั้งไม่รวมกัน) ตัวกำหนดตารางเวลา I / O ของระบบปฏิบัติการจะรวมเข้าด้วยกัน หากไม่มีแคชของตัวควบคุมจะทำการผสาน ไม่มีความแตกต่างถ้าคุณอ่าน 8 บล็อกต่อเนื่อง 512 ไบต์หรืออัน 4096 ไบต์ ข้อยกเว้นหนึ่งข้อ - หากคุณทำการซิงค์โดยตรง IO และรอ 512 ไบต์ก่อนที่คุณจะขอ 512 ไบต์ถัดไป ในกรณีนี้การเพิ่มขนาดบล็อกเหมือนการเพิ่มแคช
นอกจากนี้คุณควรทราบว่ามีการซิงค์และ async IO: ด้วยการซิงค์ IO คุณจะไม่ออกคำขอ IO ถัดไปก่อนที่จะส่งคืนปัจจุบัน ด้วย async IO คุณสามารถขอข้อมูลได้ 10 ชิ้นจากนั้นรอเมื่อมาถึง เธรดฐานข้อมูลที่ไม่สม่ำเสมอจะใช้ sync IO สำหรับบันทึกและ async IO สำหรับข้อมูล เครื่องมือ IOPSดูแลโดยการวัดขนาดบล็อกที่เกี่ยวข้องทั้งหมดเริ่มต้นจาก 512 ไบต์
คุณจะอ่านหรือเขียน : โดยปกติการอ่านจะเร็วกว่าการเขียน แต่โปรดทราบว่าการแคชทำงานค่อนข้างแตกต่างกันในการอ่านและเขียน:
สำหรับการเขียนข้อมูลจะถูกส่งมอบให้กับคอนโทรลเลอร์และถ้าแคชข้อมูลจะรับทราบก่อนที่ข้อมูลจะอยู่ในดิสก์เว้นแต่ว่าแคชจะเต็ม การใช้เครื่องมือiozoneคุณสามารถวาดกราฟของเอฟเฟกต์แคชที่สวยงาม (เอฟเฟกต์แคช CPU และเอฟเฟกต์แคชบัฟเฟอร์) แคชจะมีประสิทธิภาพน้อยลงและยิ่งมีการเขียนมากขึ้น
สำหรับการอ่านข้อมูลการอ่านจะถูกเก็บไว้ในแคชหลังจากอ่านครั้งแรก การอ่านครั้งแรกใช้เวลานานที่สุดและการแคชจะมีประสิทธิภาพมากขึ้นในช่วงเวลาทำงาน แคชที่สังเกตเห็นได้คือแคช CPU, แคชระบบไฟล์ของระบบปฏิบัติการ, แคชคอนโทรลเลอร์ของ IO และแคชของหน่วยเก็บข้อมูล เครื่องมือ IOPSอ่านการวัดเท่านั้น การทำเช่นนี้ช่วยให้ "อ่านได้ทุกที่" และคุณไม่ต้องการให้เขียนแทนการอ่าน
คุณจะใช้หลายเธรด : หากคุณใช้หนึ่งเธรด ( ใช้ dd สำหรับการวัดประสิทธิภาพของดิสก์ ) คุณอาจได้รับประสิทธิภาพที่แย่กว่าการใช้เธรดหลายตัว เครื่องมือ IOPSคำนึงถึงเรื่องนี้และอ่านหลายกระทู้
ความสำคัญของเวลาในการตอบสนองต่อคุณ : ดูที่ฐานข้อมูลความหน่วงของ IO กลายเป็นเรื่องสำคัญอย่างยิ่ง คำสั่งแทรก / อัพเดต / ลบ SQL ใด ๆ จะถูกเขียนลงในฐานข้อมูลเจอร์นัล ("log" ในฐานข้อมูลศัพท์แสง) เมื่อทำการคอมมิทก่อนที่จะยอมรับ หมายความว่าฐานข้อมูลที่สมบูรณ์อาจกำลังรอการดำเนินการ IO นี้ให้เสร็จสมบูรณ์ ผมแสดงที่นี่วิธีการวัดเวลารอคอยเฉลี่ย (รอคอย) โดยใช้เครื่องมือ iostat
การใช้งาน CPU มีความสำคัญอย่างไรสำหรับคุณ : CPU ของคุณอาจกลายเป็นคอขวดสำหรับประสิทธิภาพการทำงานของแอปพลิเคชันของคุณ ในกรณีนี้คุณต้องรู้ว่าซีพียูรอบการเผาไหม้ต่อการอ่าน / เขียนและการเพิ่มประสิทธิภาพในทิศทางนั้น นี่อาจหมายถึงการตัดสินใจเกี่ยวกับหน่วยความจำแฟลช PCIe ขึ้นอยู่กับผลการวัดของคุณ เครื่องมือ iostatอีกครั้งสามารถประเมินคร่าวๆเกี่ยวกับการใช้งาน CPU โดยการปฏิบัติการ IO ของคุณ
หากคุณติดตั้ง PostgreSQL คุณสามารถใช้มาตรฐานpg_test_fsync ที่ยอดเยี่ยมได้ มันเป็นพื้นทดสอบประสิทธิภาพการซิงค์การเขียนของคุณ
บน Ubuntu คุณพบได้ที่นี่: /usr/lib/postgresql/9.5/bin/pg_test_fsync
สิ่งที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้คือเครื่องมือนี้จะแสดงให้คุณเห็นว่าทำไม SSD ขององค์กรถึงมีมูลค่าถึง $ พิเศษ
postgresql-contribแพ็คเกจ
คุณสามารถใช้fio- The เครื่องมือสร้างแบบมัลติเธรด IO มันถูกบรรจุโดยการแจกแจงหลายอย่างเช่น Fedora 25, Debian และ OpenCSW
เครื่องมือ fio นั้นมีความยืดหยุ่นสูงสามารถใช้เป็นเกณฑ์มาตรฐานสถานการณ์ IO ต่างๆได้อย่างง่ายดายรวมถึงสถานการณ์ที่เกิดขึ้นพร้อมกัน แพ็คเกจมาพร้อมกับไฟล์การกำหนดค่าตัวอย่าง (cf. เช่น/usr/share/doc/fio/examples) มันวัดสิ่งต่าง ๆ ได้อย่างถูกต้องเช่นมันยังพิมพ์ค่าเบี่ยงเบนมาตรฐานและสถิติเชิงปริมาณสำหรับบางตัวเลข สิ่งที่เครื่องมือเปรียบเทียบอื่น ๆ ที่เป็นที่นิยมไม่สนใจ
ตัวอย่างง่ายๆ (ลำดับของสถานการณ์จำลองง่าย ๆ : ลำดับ / สุ่ม X อ่าน / เขียน):
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
โทร:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
โปรดทราบว่า[global]ส่วนนั้นมีค่าเริ่มต้นทั่วไปที่สามารถแทนที่ได้โดยส่วนอื่น ๆ แต่ละส่วนอธิบายงานชื่อส่วนคือชื่องานและสามารถเลือกได้อย่างอิสระ โดยค่าเริ่มต้นงานที่แตกต่างจะเริ่มต้นในแบบขนานดังนั้นตัวอย่างข้างต้นอย่างชัดเจนอนุกรมการดำเนินงานกับ
wait_forคีย์ นอกจากนี้ fio ยังใช้ขนาดบล็อก 4 KiB ซึ่งสามารถเปลี่ยนแปลงได้เช่นกัน ตัวอย่างใช้อุปกรณ์ raw โดยตรงสำหรับงานอ่านและเขียนดังนั้นตรวจสอบให้แน่ใจว่าคุณใช้อุปกรณ์ที่เหมาะสม เครื่องมือนี้ยังรองรับการใช้ไฟล์ / ไดเรกทอรีบนระบบไฟล์ที่มีอยู่
hdparmยูทิลิตี้ให้เป็นมาตรฐานอ่านง่ายมากเช่น:
# hdparm -t -T /dev/sdz
มันไม่ใช่สิ่งทดแทนเครื่องมือการเปรียบเทียบที่ทันสมัยเช่น fio แต่ควรใช้สำหรับการตรวจสอบความน่าเชื่อถือครั้งแรก ตัวอย่างเช่นหากต้องการตรวจสอบว่าไดรฟ์ USB 3 ภายนอกได้รับการยอมรับอย่างผิด ๆ ว่าเป็นอุปกรณ์ USB 2 หรือไม่ (คุณจะเห็นอัตรา ~ 100 MiB / s เทียบกับ ~ 30 MiB / s อัตรา)
ตามที่อธิบายไว้ที่นี่คุณสามารถใช้gnome-disks(ถ้าคุณใช้ Gnome)
คลิกที่ไดรฟ์ที่คุณต้องการทดสอบและคลิกที่ "ตัวเลือกพาร์ติชันเพิ่มเติม" (ล้อ) Benchmark Partitionแล้วก็ คุณจะได้รับการอ่าน / เขียนโดยเฉลี่ยเป็น MB / s และเวลาเข้าถึงโดยเฉลี่ยในหน่วยมิลลิวินาที ฉันพบว่าสบายมาก
มันค่อนข้างหยาบ แต่ก็ใช้งานได้ดี:
find <path> -type f -print0 | cpio -0o >/dev/null
คุณสามารถทำสิ่งที่น่าสนใจด้วยเทคนิคนี้รวมถึงการแคชทั้งหมด/libและ/usr/binไฟล์ คุณสามารถใช้สิ่งนี้เป็นส่วนหนึ่งของความพยายามในการเปรียบเทียบ:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
พบชื่อไฟล์ทั้งหมดในรูทเรียงลำดับแบบสุ่มและคัดลอกลงในแคชนานถึง 1 นาที ผลลัพธ์จาก cpio จะบอกคุณว่ามีการคัดลอกบล็อกจำนวนเท่าใด ทำซ้ำ 3 ครั้งเพื่อรับบล็อกเฉลี่ยต่อนาที (หมายเหตุการดำเนินการค้นหา / เรียงลำดับอาจใช้เวลานาน - นานกว่าการคัดลอกมันจะเป็นการดีกว่าถ้าจะแคชการค้นหา / เรียงลำดับและใช้splitเพื่อรับตัวอย่างของไฟล์)