Cara memeriksa kinerja hard disk


Jawaban:


425

Metode terminal

hdparm adalah tempat yang bagus untuk memulai.

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda akan memberikan informasi juga.

dd akan memberi Anda informasi tentang kecepatan tulis.

Jika drive tidak memiliki sistem file (dan hanya itu ), gunakan of=/dev/sda.

Kalau tidak, pasang di / tmp dan tulis kemudian hapus file hasil tes.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Metode grafis

  1. Pergi ke Sistem -> Administrasi -> Utilitas Disk.
    • Atau, jalankan utilitas disk Gnome dari baris perintah dengan menjalankan gnome-disks
  2. Pilih hard disk Anda di panel kiri.
  3. Sekarang klik tombol “Benchmark - Measure Drive Performance” di panel kanan.
  4. Jendela baru dengan grafik terbuka. Anda akan menemukan dan dua tombol. Salah satunya adalah "Mulai Hanya Baca Tolok Ukur" dan satu lagi adalah "Mulai Baca / Tulis Tolok Ukur". Ketika Anda mengklik tombol siapa pun itu mulai melakukan pembandingan terhadap hard disk.

uji

Cara benchmark disk I / O

Artikel

Apakah ada sesuatu lagi yang Anda inginkan?


10
Saya akan merekomendasikan pengujian /dev/urandomserta /dev/zeroinput ddketika menguji SSD karena kompresibilitas data dapat memiliki efek besar pada kecepatan menulis.
Ian Mackinnon

3
Tidak ada "Sistem -" di Ubuntu 12.04 Unity saya. Atau setidaknya saya belum menemukannya. Dan saya tidak melihat alat disk itu juga di dalam Pengaturan Sistem ... O_o Tapi saya akhirnya berhasil menjalankannya: / usr / bin / palimpsest
Fran Marzoa

6
Perhatikan bahwa sejak 12.10 itu hanya disebut Disk dan dapat ditemukan melalui Unity.
Paul Lammertsma

1
Pada Gnome ini telah pindah ke Aplikasi -> System Tools -> Preferences -> Disk Utility. Bagi mereka yang menggunakan yang membenci Unity.
Ken Sharp

2
Sistem /tmpfile sering menggunakan ramdisk hari ini. Jadi menulis ke /tmptampaknya menguji memori Anda, bukan subsistem disk Anda.
Zoredache

99

Suominen benar, kita harus menggunakan semacam sinkronisasi; tetapi ada metode yang lebih sederhana, conv = fdatasync akan melakukan pekerjaan:

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

28
Ini jawaban menggunakan perintah / opsi yang berbeda dari yang lain. Saya melihat itu adalah jawaban yang layak untuk posnya sendiri.
Alaa Ali

2
Mengapa Anda menggunakan 384k sebagai ukuran blok?
Diego F. Durán

1
@Diego Tidak ada alasan. Itu hanya sebuah contoh. Anda bisa menggunakan yang lain. (antara sekitar 4k ... 1 jt) Tentu saja ukuran balok yang lebih besar akan memberikan kinerja yang lebih baik. Dan tentu saja mengurangi jumlah hitungan ketika Anda menggunakan bs besar, atau itu akan memakan waktu satu tahun untuk menyelesaikannya.
Tele

itu tidak dapat diandalkan oleh alat mark bench seperti iozone dan nomor sysbench jauh lebih rendah
MSS

1
Berhati-hatilah dengan menggunakan nol untuk data tulis Anda - beberapa sistem file dan disk akan memiliki jalur kasus khusus untuk itu (dan data kompresibel lainnya) yang akan menyebabkan angka patokan sangat tinggi ...
Anon

50

Saya tidak akan merekomendasikan menggunakan /dev/urandomkarena ini berbasis perangkat lunak dan lambat seperti babi. Lebih baik mengambil potongan data acak di ramdisk. Pada pengujian hard disk acak tidak masalah, karena setiap byte ditulis sebagaimana adanya (juga pada ssd dengan dd). Tetapi jika kita menguji kolam zfs dedupped dengan nol murni atau data acak, ada perbedaan kinerja yang sangat besar.

Sudut pandang lain harus dimasukkan waktu sinkronisasi; semua sistem file modern menggunakan caching pada operasi file.

Untuk benar-benar mengukur kecepatan disk dan bukan memori, kita harus menyinkronkan sistem file untuk menghilangkan efek caching. Itu dapat dengan mudah dilakukan oleh:

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

dengan metode itu Anda mendapatkan output:

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

jadi datarate disk hanya 104857600 / 0.441 = 237772335 B / s -> 237MB / s

Itu lebih dari 100MB / s lebih rendah dibandingkan dengan caching.

Selamat melakukan benchmarking,


3
Berhati-hatilah dengan menggunakan nol untuk data tulis Anda - beberapa disk (seperti SSD) dan beberapa sistem file akan memiliki jalur case khusus untuk itu. Ini menghasilkan angka patokan sangat tinggi saat menggunakan nol buffer. Pola data yang sangat kompresibel lainnya juga dapat mendistorsi hasil ...
Anon

36

Jika Anda ingin memonitor kecepatan baca-tulis disk Anda dapat menggunakan alat iotop .

Ini berguna untuk mendapatkan informasi yang tepat tentang bagaimana kinerja disk untuk aplikasi atau tugas tertentu. Output akan menunjukkan Anda kecepatan baca / tulis per proses, dan total kecepatan baca / tulis untuk server, mirip dengan top.

Untuk menginstal iotop:

sudo apt-get install iotop  

Untuk menjalankannya:

sudo iotop

28

Jika Anda menginginkan keakuratan, sebaiknya gunakan fio. Membutuhkan membaca manual ( man fio) tetapi itu akan memberi Anda hasil yang akurat. Perhatikan bahwa untuk akurasi apa pun, Anda perlu menentukan dengan tepat apa yang ingin Anda ukur. Beberapa contoh:

Kecepatan BACA berurutan dengan blok besar (ini harus mendekati angka yang Anda lihat dalam spesifikasi untuk drive Anda):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Kecepatan MENULIS berurutan dengan blok besar (ini harus mendekati angka yang Anda lihat dalam spesifikasi untuk drive Anda):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Acak 4K baca QD1 (ini adalah angka yang benar-benar penting untuk kinerja dunia nyata kecuali Anda tahu pasti):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Campuran acak 4K, baca dan tulis QD1 dengan sinkronisasi (ini adalah nomor kasus terburuk yang harus Anda harapkan dari drive Anda, biasanya kurang dari 1% dari jumlah yang tercantum dalam lembar spesifikasi):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Tambah --sizeargumen untuk menambah ukuran file. Menggunakan file yang lebih besar dapat mengurangi angka yang Anda peroleh tergantung pada teknologi drive dan firmware. File kecil akan memberikan hasil "terlalu bagus" untuk media rotasi karena kepala baca tidak perlu terlalu banyak bergerak. Jika perangkat Anda hampir kosong, menggunakan file yang cukup besar untuk hampir mengisi drive akan memberi Anda perilaku kasus terburuk untuk setiap tes. Dalam hal SSD, ukuran file tidak terlalu menjadi masalah.

Namun, perhatikan bahwa untuk beberapa media penyimpanan ukuran file tidak sepenting total byte yang ditulis selama periode waktu yang singkat. Misalnya, beberapa SSD mungkin memiliki kinerja yang jauh lebih cepat secara signifikan dengan blok yang telah dihapus atau mungkin memiliki area flash SLC kecil yang digunakan sebagai cache tulis dan kinerja berubah setelah cache SLC penuh. Sebagai contoh lain, Seagate SMR HDD memiliki sekitar 20 GB area cache PMR yang memiliki kinerja cukup tinggi tetapi setelah penuh, menulis langsung ke area SMR dapat memangkas kinerja hingga 10% dari aslinya. Dan satu-satunya cara untuk melihat penurunan kinerja ini adalah pertama-tama menulis 20+ GB secepat mungkin. Tentu saja, ini semua tergantung pada beban kerja Anda: jika akses tulis Anda penuh dengan penundaan gondrong yang memungkinkan perangkat untuk membersihkan cache internal, urutan pengujian yang lebih pendek akan mencerminkan kinerja dunia nyata Anda lebih baik. Jika Anda perlu melakukan banyak IO, Anda harus meningkatkan keduanya--io_sizedan --runtimeparameter. Perhatikan bahwa beberapa media (mis. Sebagian besar perangkat flash) akan mendapatkan keausan tambahan dari pengujian tersebut. Menurut pendapat saya, jika perangkat apa pun cukup buruk untuk tidak menangani pengujian semacam ini, perangkat tersebut tidak boleh digunakan untuk menyimpan data berharga apa pun dalam kondisi apa pun.

Selain itu, beberapa perangkat SSD berkualitas tinggi mungkin bahkan memiliki algoritme leveling wear yang lebih cerdas di mana cache SLC internal memiliki cukup banyak kecerdasan untuk menggantikan data di tempat yang sedang ditulis ulang selama pengujian jika itu mengenai ruang alamat yang sama (yaitu, file uji lebih kecil dari total cache SLC). Untuk perangkat semacam itu, ukuran file mulai menjadi masalah lagi. Jika Anda membutuhkan beban kerja aktual, yang terbaik adalah mengujinya dengan ukuran file yang benar-benar akan Anda lihat di kehidupan nyata. Kalau tidak, angka Anda mungkin terlihat terlalu bagus.

Catatan yang fioakan membuat file sementara yang diperlukan saat dijalankan pertama kali. Itu akan diisi dengan data acak untuk menghindari terlalu banyak angka dari perangkat yang menipu dengan mengompresi data sebelum menulisnya ke penyimpanan permanen. File sementara akan dipanggil fio-tempfile.datdalam contoh di atas dan disimpan di direktori kerja saat ini. Jadi, Anda harus terlebih dahulu mengubah ke direktori yang dipasang pada perangkat yang ingin Anda uji.

Jika Anda memiliki SSD yang bagus dan ingin melihat angka yang lebih tinggi, tingkatkan di --numjobsatas. Itu mendefinisikan konkurensi untuk membaca dan menulis. Semua contoh di atas telah numjobsdiatur 1sehingga pengujiannya adalah tentang proses membaca dan menulis berurutan tunggal (mungkin dengan set antrian dengan iodepth). SSD kelas atas (mis. Intel Optane) harus mendapatkan angka tinggi walaupun tanpa menambah numjobsbanyak (mis. 4Harus cukup untuk mendapatkan nomor spesifikasi tertinggi) tetapi beberapa SSD "Perusahaan" perlu pergi 32- 128untuk mendapatkan nomor spesifikasi karena latensi internal perangkat lebih tinggi tetapi throughput keseluruhannya gila.


1
Saya baru saja menguji ulang beberapa perangkat. Menggunakan uji baca berurutan di atas (ukuran blok 2MB) saya mendapat 280 MB / s dari Samsung SSD 850 EVO dan 1070 MB / s dari Intel 910 SSD. Dengan ukuran blok 64k dan commandline yang identik saya dapatkan 268 MB / s dari 850 EVO dan 1055 MB / s dari 910 SSD. Setidaknya untuk perangkat jenis ini, menggunakan ukuran blok 2 MB tampaknya meningkatkan hasil sekitar 1-5% meskipun itu menyebabkan kernel untuk membagi permintaan ke perangkat keras. Saya kira bahkan dengan optimasi kernel, biaya pengiriman syscalls lebih buruk daripada membelah kernel.
Mikko Rantalainen

1
Setelah pengujian lebih lanjut tampaknya saya mendapatkan throughput sekuensial tertinggi menggunakan kekuatan 2 nilai yang kurang dari max_sectors_kb. Saya mengubah contoh perintah di atas untuk menggunakan ukuran blok 1 MB karena itu tampaknya bekerja dengan perangkat keras dunia nyata. Dan saya juga menguji itu fsynctidak masalah untuk membaca.
Mikko Rantalainen

1
Tergantung pada bagaimana drive terhubung, Anda mungkin menemukan bahwa iodepth Anda terlalu rendah. Anda harus menonton apa yang sebenarnya dikirim Linux ke perangkat dan seberapa dalam melakukannya ...
Anon

1
Aku mengatur iodepthuntuk 1untuk akses random justru karena program dunia nyata sering menjalankan algoritma / logika yang tidak bekerja dengan kedalaman lebih tinggi dari 1. Akibatnya, jika kedalaman tersebut "terlalu rendah" perangkat I / O Anda buruk. Memang benar bahwa beberapa perangkat SSD akan mendapat manfaat dari kedalaman lebih tinggi dari 32. Namun, dapatkah Anda menunjuk ke beban kerja dunia nyata yang memerlukan akses baca dan mampu mempertahankan iodepth lebih tinggi dari 32? TL; DR: jika Anda ingin mereproduksi beberapa angka patokan baca sangat tinggi dengan perangkat latensi tinggi, gunakan iodepth=256 --numjobs=4tetapi jangan pernah berharap untuk melihat angka seperti itu nyata.
Mikko Rantalainen

1
Sebagian besar program "dunia nyata" tidak benar-benar mengirimkan I / O (o_) secara langsung, apalagi secara serempak sehingga semua contoh kami berada dalam beban kerja yang tidak biasa untuk mendorong batas batas wilayah (seperti yang mereka katakan, patokan terbaik adalah beban kerja nyata Anda). Setelah mengatakan bahwa melakukan hal-hal seperti menjalankan beberapa mesin virtual sibuk dapat dengan mudah menghasilkan beban kerja dengan kedalaman gila yang tinggi tetapi di mana I / O sering terlihat acak dari perspektif disk dan merupakan contoh sederhana di mana Anda dapat melihat percepatan besar dari hal-hal seperti NVMe. PS: mengatur angka terlalu tinggi akan mengurangi throughput sehingga ada sweet spot ...
Anon

25

bonnie ++ adalah utilitas benchmark utama yang saya tahu untuk linux.

(Saat ini saya sedang menyiapkan livecd linux di tempat kerja dengan bonnie ++ untuk menguji mesin berbasis windows kami dengannya!)

Ini menangani caching, sinkronisasi, data acak, lokasi acak pada disk, pembaruan ukuran kecil, pembaruan besar, membaca, menulis, dll. Membandingkan usbkey, harddisk (rotary), solid-state drive dan ram-based filesystem bisa sangat informatif bagi pemula.

Saya tidak tahu apakah ini termasuk dalam Ubuntu, tetapi Anda dapat mengkompilasinya dari sumber dengan mudah.

http://www.coker.com.au/bonnie++/


Bonnie cacat untuk pembandingan disk dan dapat dengan mudah menghasilkan angka yang benar-benar mencerminkan aspek non-disk sistem Anda sehingga diperlukan perawatan tingkat tinggi jika Anda memilih untuk menggunakannya. Lihat Pembandingan Aktif Brendan Gregg: Bonnie ++ untuk detailnya.
Anon

22

Kecepatan tulis

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

Ukuran blok sebenarnya cukup besar. Anda dapat mencoba dengan ukuran yang lebih kecil seperti 64k atau bahkan 4k.


Kecepatan baca

Jalankan perintah berikut untuk menghapus cache memori

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Sekarang baca file yang dibuat dalam tes tulis:

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

Berhati-hatilah dengan menggunakan nol untuk data tulis Anda - beberapa sistem file dan disk akan memiliki jalur kasus khusus untuk itu (dan data kompresibel lainnya) yang akan menyebabkan angka patokan sangat tinggi ...
Anon

14

beberapa petunjuk tentang cara menggunakan Bonnie ++

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

Sedikit lebih banyak di: CONTOH BONNIE ++ CONTOH .


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.