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?
Jawaban:
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.
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
-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.
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.
Jika Anda membutuhkan pengujian HDD yang lebih ketat, Anda dapat menggunakan Bonnie ++ .
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.
hdparm+ ddatau hanya bonnie++atau semuanya 3.
(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:
Dan seterusnya.
Berikut daftar alat yang paling mudah dijalankan di bagian atas dan lebih sulit / lebih teliti / lebih baik di bagian bawah:
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 .
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:
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.
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.
postgresql-contribpaket.
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.
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).
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.
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.)