Bagaimana saya bisa membandingkan HDD saya?

51

Saya telah melihat perintah untuk membandingkan HDD seseorang seperti ini menggunakan dd:

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"

Adakah metode yang lebih baik untuk melakukannya daripada ini?

slm
sumber
terkait: askubuntu.com/questions/87035/…
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件

Jawaban:

62

Saya biasanya menggunakan hdparmtolok ukur HDD saya. Anda dapat membandingkan kedua bacaan langsung dan yang di-cache. Anda akan ingin menjalankan perintah beberapa kali untuk menetapkan nilai rata-rata.

Contohnya

Ini bacaan langsung.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

Dan inilah bacaan cache.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Detail

-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.

Menggunakan dd

Saya juga telah menggunakan dduntuk jenis pengujian ini. Salah satu modifikasi yang akan saya buat untuk perintah di atas adalah menambahkan bit ini ke akhir perintah Anda ; rm ddfile,.

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Ini akan menghapus ddfilesetelah perintah selesai. CATATAN: ddfile adalah file sementara yang tidak perlu Anda simpan, ini adalah file yang ddsedang ditulis ( of=ddfile), ketika HDD Anda sedang dimuat.

Melampaui

Jika Anda membutuhkan pengujian HDD yang lebih ketat, Anda dapat menggunakan Bonnie ++ .

Referensi

slm
sumber
1
Saya suka hdparmjuga, untuk tolok ukur cepat. Satu-satunya downside adalah itu hanya pembacaan bandwidth dan kinerja berbagai jenis perangkat blok (misalnya RAID, iSCSI) bisa sangat asimetris. Untuk membandingkan kinerja 'sebelum' dan 'setelah' pada kotak yang sama, ddberfungsi dengan baik juga.
Alexios
@ Alexios - ya terima kasih telah menyebutkan itu. Ya, Anda biasanya harus menggunakan paling tidak hdparm+ ddatau hanya bonnie++atau semuanya 3.
slm
Alih-alih sinkronisasi yang dipertanyakan gunakan iflag = direct oflag = langsung ketika seharusnya (misalnya linux dengan sistem file yang mendukung direct io).
22

(Ini adalah pertanyaan yang sangat populer - Anda dapat melihat variasi di https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 dan https://askubuntu.com/q / 87035/740413 )

Apakah ada metode yang lebih baik [daripada dd] ke [disk benchmark]?

Ya tetapi mereka akan membutuhkan waktu lebih lama untuk menjalankan dan membutuhkan pengetahuan tentang bagaimana menginterpretasikan hasil - tidak ada angka tunggal yang akan memberi tahu Anda semuanya sekaligus karena berikut ini mempengaruhi jenis tes yang harus Anda jalankan:

  • Apakah Anda tertarik dengan kinerja I / O yang acak, berurutan, atau campuran keduanya?
  • Apakah Anda membaca dari atau menulis ke disk (atau campuran keduanya)?
  • Apakah Anda khawatir tentang latensi, throughput, atau keduanya?
  • Apakah Anda mencoba memahami bagaimana kinerja berbagai bagian dari hard disk yang sama (umumnya mempercepat lebih cepat lebih dekat ke pusat disk berputar)?
  • Apakah Anda tertarik pada kinerja sistem file yang diberikan saat menggunakan disk Anda atau apakah Anda ingin hasil yang lebih dekat dengan kinerja mentah disk dengan melakukan I / O langsung ke perangkat blok?
  • Apakah Anda tertarik dengan kinerja ukuran I / O tertentu?
  • Apakah Anda mengirimkan I / O secara sinkron atau tidak sinkron?
  • Berapa banyak I / O yang Anda kirimkan (kirimkan terlalu sedikit dengan cara yang salah dan semua I / O bisa di-cache sehingga Anda akhirnya menguji kecepatan RAM Anda daripada kecepatan disk)?
  • Seberapa kompresibel isi data yang Anda tulis (mis. Hanya data nol yang sangat kompresif dan beberapa sistem file / disk bahkan memiliki jalur cepat khusus untuk hanya data nol yang mengarah ke angka yang tidak dapat diperoleh dengan konten lain)?

Dan seterusnya.

Berikut daftar alat yang paling mudah dijalankan di bagian atas dan lebih sulit / lebih teliti / lebih baik di bagian bawah:

  1. dd (membaca atau menulis berurutan, hanya menunjukkan throughput, dapat dikonfigurasi untuk menggunakan sistem file atau perangkat blok, dapat dikonfigurasi untuk mem-bypass cache blok / menunggu I / O benar-benar selesai)
  2. hdparm (hanya baca sekuensial, hanya menunjukkan throughput, tidak pernah menggunakan sistem file, dapat dikonfigurasi untuk mem-bypass blok cache, uji cache hanya membaca ulang mulai 2 MBytes)
  3. Tolok ukur Disk Utility GNOME (mudah dijalankan, tidak pernah menggunakan sistem file, grafis tetapi membutuhkan instalasi penuh GNOME, memberikan nomor latensi dan jumlah throughput untuk berbagai jenis I / O tetapi beban kerja tulis sebenarnya adalah melakukan baca / tulis / fsync per ukuran sampel).
  4. fio (dapat melakukan hampir semua hal dan memberikan hasil yang terperinci tetapi membutuhkan konfigurasi dan pemahaman tentang bagaimana menafsirkan hasil tersebut) Inilah yang dikatakan Linus tentang hal itu:

    Greg - dapatkan kode FIO Jens. Itu melakukan hal yang benar, termasuk menulis konten pseudo-acak yang sebenarnya, yang menunjukkan jika disk melakukan beberapa "de-duplikasi" (alias "optimalkan untuk benchmark):

    [ https://github.com/axboe/fio/ ]

    Ada lagi yang dicurigai - lupakan Bonnie atau alat tradisional lainnya.

Sumber: komentar yang tersisa di Google Plus untuk Greg Kroah-Hartman oleh Linus Torvalds .

Segera
sumber
11

dengan alat IOPS

Jika Anda tidak perlu repot untuk membaca semua ini, saya hanya akan merekomendasikan alat IOPS . Ini akan memberi tahu Anda kecepatan dunia nyata tergantung pada ukuran blok.


Kalau tidak - ketika melakukan benchmark IO saya akan melihat hal-hal berikut:

  • blocksize / cache / IOPS / direct vs buffered / async vs sync
  • Baca tulis
  • utas
  • latensi
  • Pemanfaatan CPU

  • Blokir mana yang akan Anda gunakan : Jika Anda ingin membaca / menulis 1 GB dari / ke disk, ini akan cepat jika Anda melakukan satu operasi I / O. Tetapi jika aplikasi Anda perlu menulis dalam 512 byte potongan di seluruh harddisk dalam potongan non-sekuensial (disebut acak I / O meskipun tidak acak) ini akan terlihat berbeda. Sekarang, basis data akan melakukan I / O acak untuk volume data dan I / O berurutan untuk volume log karena sifatnya . Jadi, pertama-tama Anda harus jelas apa yang ingin Anda ukur. Jika Anda ingin menyalin file video besar yang berbeda daripada jika Anda ingin menginstal Linux.

    Blocksize ini memengaruhi hitungan operasi I / O yang Anda lakukan. Jika Anda melakukan mis. Operasi baca 8 (atau menulis, tidak dicampur) secara berurutan, penjadwal I / O OS akan menggabungkannya. Jika tidak, cache controller akan melakukan penggabungan. Praktis tidak ada perbedaan jika Anda membaca 8 blok berurutan dari 512 byte atau satu 4096 byte. Satu pengecualian - jika Anda berhasil melakukan sinkronisasi IO langsung dan menunggu 512 byte sebelum Anda meminta 512 byte berikutnya. Dalam hal ini, meningkatkan ukuran blok seperti menambahkan cache.

    Anda juga harus menyadari bahwa ada IO sinkronisasi dan asinkron: Dengan sinkronisasi IO Anda tidak akan mengeluarkan permintaan IO berikutnya sebelum yang sekarang kembali. Dengan async IO, Anda dapat meminta, misalnya, 10 keping data dan kemudian menunggu begitu tiba. Utas basis data yang jelas biasanya akan menggunakan sinkronisasi IO untuk log dan async IO untuk data. Alat IOPS menangani hal itu dengan mengukur semua ukuran blok yang relevan mulai dari 512 byte.

  • Apakah Anda membaca atau menulis : Biasanya membaca lebih cepat daripada menulis. Tetapi perhatikan bahwa caching bekerja dengan cara yang berbeda untuk membaca dan menulis:

    • Untuk menulis, data akan diserahkan ke controller dan jika itu cache, itu akan mengakui sebelum data ada di disk kecuali cache penuh. Dengan menggunakan alat iozone, Anda dapat menggambar grafik indah dari efek cache (efek cache CPU dan efek cache buffer). Cache menjadi kurang efisien semakin banyak yang telah ditulis.

    • Untuk membaca, baca data disimpan dalam cache setelah pembacaan pertama. Pembacaan pertama memakan waktu paling lama dan caching menjadi lebih dan lebih efektif selama waktu aktif. Cache yang mencolok adalah cache CPU, cache sistem file OS, cache pengontrol IO, dan cache penyimpanan. Alat IOPS hanya mengukur pembacaan. Ini memungkinkannya untuk "membaca semua tempat" dan Anda tidak ingin ia menulis daripada membaca.

  • Berapa banyak utas yang akan Anda gunakan : Jika Anda menggunakan satu utas ( menggunakan dd untuk tolok ukur disk ) Anda mungkin akan mendapatkan kinerja yang jauh lebih buruk daripada dengan beberapa utas. Alat IOPS memperhitungkan ini dan membaca beberapa utas.

  • Seberapa penting latensi bagi Anda : Melihat pada database, latensi IO menjadi sangat penting. Setiap perintah masukkan / perbarui / hapus SQL akan ditulis ke dalam jurnal basis data ("log" dalam basis data basis data) pada komit sebelum diakui. Ini berarti database yang lengkap mungkin menunggu untuk operasi IO ini selesai. Saya tunjukkan di sini cara mengukur waktu tunggu rata-rata (menunggu) menggunakan alat iostat .

  • Seberapa penting pemanfaatan CPU untuk Anda : CPU Anda dapat dengan mudah menjadi penghambat kinerja aplikasi Anda. Dalam hal ini Anda harus tahu berapa banyak siklus CPU yang terbakar per byte baca / tulis dan optimalkan ke arah itu. Ini bisa berarti memutuskan untuk / terhadap memori flash PCIe tergantung pada hasil pengukuran Anda. Sekali lagi alat iostat dapat memberi Anda perkiraan kasar tentang pemanfaatan CPU oleh operasi IO Anda.

Thorsten Staerk
sumber
1
Skrip iops bagus, saya benar-benar bingung bahwa itu bukan apt atau pip. Tapi itu berhasil.
ThorSummoner
Alat iops tampaknya ditinggalkan. Juga, itu hanya mengukur membaca dan tidak mencetak angka statistik (misalnya stddev / kuantitatif).
maxschlepzig
Alat iops sederhana dan itulah yang Anda butuhkan untuk mencapai keterbandingan. Ini pada dasarnya adalah pembungkus untuk syscall baca, dilakukan secara acak pada file (semuanya adalah file). Percaya atau baca sumbernya - sudah selesai dan kode tidak perlu diperbarui. Pikirkan tentang hal ini - apakah Anda benar-benar menginginkan alat lain seperti IOMeter dengan ribuan baris kode yang masing-masing dapat diperdebatkan? Dan apa yang Anda lakukan dengan versi baru? Apakah Anda harus melakukan kembali semua tolok ukur?
Thorsten Staerk
8

Jika Anda telah menginstal PostgreSQL, Anda dapat menggunakan tolok ukur pg_test_fsync mereka yang sangat baik . Ini pada dasarnya menguji kinerja sinkronisasi tulis Anda.

Di Ubuntu Anda menemukannya di sini: /usr/lib/postgresql/9.5/bin/pg_test_fsync

Hal yang hebat tentang itu, adalah bahwa alat ini akan menunjukkan kepada Anda mengapa SSD perusahaan bernilai $ ekstra.

Olav Grønås Gjerde
sumber
2
Pada Debian tersedia dalam postgresql-contribpaket.
TranslucentCloud
5

Anda dapat menggunakan fio- alat generasi IO Multithreaded . Itu dikemas oleh beberapa distribusi, misalnya Fedora 25, Debian dan OpenCSW.

Alat fio sangat fleksibel, dapat dengan mudah digunakan untuk membandingkan berbagai skenario IO - termasuk yang bersamaan. Paket ini disertai dengan beberapa contoh file konfigurasi (lih. Mis /usr/share/doc/fio/examples.). Ini benar mengukur hal-hal, yaitu juga mencetak standar deviasi dan statistik kuantitatif untuk beberapa angka. Hal-hal yang tidak dipedulikan oleh beberapa alat pembandingan populer lainnya.

Contoh sederhana (urutan skenario sederhana: sekuensial / acak X baca / tulis):

$ 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

Panggilan:

# 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
[..]

Perhatikan bahwa [global]bagian ini memiliki standar global yang dapat ditimpa oleh bagian lain. Setiap bagian menggambarkan pekerjaan, nama bagian adalah nama pekerjaan dan dapat dipilih dengan bebas. Secara default, pekerjaan yang berbeda dimulai secara paralel, sehingga contoh di atas secara eksplisit membuat serialisasi pelaksanaan pekerjaan dengan wait_forkunci. Juga, fio menggunakan ukuran blok 4 KiB - yang dapat diubah juga. Contoh tersebut secara langsung menggunakan perangkat mentah untuk pekerjaan membaca dan menulis, jadi, pastikan Anda menggunakan perangkat yang tepat. Alat ini juga mendukung penggunaan file / direktori pada sistem file yang ada.

Alat Lainnya

The hdparmutilitas menyediakan patokan membaca sangat sederhana, misalnya:

# hdparm -t -T /dev/sdz

Ini bukan pengganti alat tolok ukur canggih seperti fio, itu hanya harus digunakan untuk pemeriksaan masuk akal pertama. Misalnya, untuk memeriksa apakah drive USB 3 eksternal dikenali secara salah sebagai perangkat USB 2 (Anda akan melihat ~ 100 MiB / dtk ~ ~ 30 MiB / dtk).

maxschlepzig
sumber
1
Jawaban ini pada dasarnya adalah versi berbeda dari jawaban ringkasan unix.stackexchange.com/a/138516/134856 (tetapi dengan bagian fio yang diperluas). Saya sobek karena memang memberikan ringkasan fio tetapi cukup panjang dan Anda dapat lolos dengan menghubungkan ke fio.readthedocs.io/en/latest/fio_doc.html#job-file-format ...
Anon
PS: Saya sarankan menambahkan direct = 1 ke bagian global dari pekerjaan Anda sehingga Anda mem-bypass cache halaman Linux dan hanya melihat kecepatan disk (tetapi karena iodepth Anda hanya 1 ... [masukkan diskusi tentang mengirimkan disk I / O] ). Lebih mudah menggunakan stonewall ( fio.readthedocs.io/en/latest/… ) secara global untuk membuat semua pekerjaan berjalan berurutan.
Anon
1

Seperti yang ditunjukkan di sini , Anda dapat menggunakan gnome-disks(jika Anda menggunakan Gnome).

Klik ke drive yang ingin Anda uji dan klik pada "Opsi partisi tambahan" (roda). Lalu Benchmark Partition. Anda akan mendapatkan rata-rata baca / tulis dalam MB / s dan waktu akses rata-rata dalam milidetik. Saya merasa sangat nyaman.

Sören
sumber
1

Agak kasar, tapi ini bisa digunakan:

find <path> -type f -print0 | cpio -0o >/dev/null

Anda dapat melakukan beberapa hal menarik dengan teknik ini, termasuk caching semua file /libdan /usr/bin. Anda juga dapat menggunakan ini sebagai bagian dari upaya pembandingan:

find / -xdev -type f -print0 | 
sort -R --from0-file=- | 
timeout "5m" cpio -0o >/dev/null

Semua nama file pada root ditemukan, disortir secara acak, dan salin ke cache hingga 1 menit. Output dari cpio memberi tahu Anda berapa banyak blok yang disalin. Ulangi 3 kali untuk mendapatkan rata-rata blok per menit. (Catatan, operasi find / sort mungkin membutuhkan waktu yang lama - jauh lebih lama daripada salinannya. Akan lebih baik untuk men-cache find / sort dan gunakan splituntuk mendapatkan sampel file.)

Otheus
sumber