Cara memeriksa kinerja hard drive (Baik melalui terminal atau GUI). Kecepatan tulis. Kecepatan baca. Ukuran dan kecepatan cache. Kecepatan acak.
Jawaban:
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
gnome-disks
Apakah ada sesuatu lagi yang Anda inginkan?
/dev/urandomserta /dev/zeroinput ddketika menguji SSD karena kompresibilitas data dapat memiliki efek besar pada kecepatan menulis.
/tmpfile sering menggunakan ramdisk hari ini. Jadi menulis ke /tmptampaknya menguji memori Anda, bukan subsistem disk Anda.
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
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,
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
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.
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.
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.
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.
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
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 .
Periksa integritas, deteksi flash drive palsu dan uji kinerja, ketiganya dalam satu kesempatan.
Lebih lanjut tentang jawaban ini .