Cara memeriksa kinerja hard drive (baik melalui terminal atau GUI). Kecepatan tulis. Kecepatan baca. Ukuran Cache dan kecepatan. Kecepatan acak.
Metode Terminal
hdparm
adalah tempat yang baik untuk memulai.
sudo hdparm -Tt /dev/sda/dev/sda:Timing cached reads: 12540 MB in 2.00 seconds = 6277.67 MB/secTiming 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 kemudian), gunakan of=/dev/sda
.
Jika tidak, pasang di / tmp dan tulis lalu hapus file output tes.
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s
Metode grafis
- >>Pergi ke sistem - administrasi - Utilitas Disk.
- Atau, Luncurkan Utilitas Disk Gnome dari baris perintah dengan menjalankan
gnome-disks
- Atau, Luncurkan Utilitas Disk Gnome dari baris perintah dengan menjalankan
- Pilih hard disk Anda di panel kiri.
- Sekarang klik tombol" Benchmark – Measure Drive Performance " di panel kanan.
- Jendela baru dengan bagan terbuka.Anda akan menemukan dan dua tombol. Salah satunya adalah untuk "start Read Only Benchmark" dan yang lainnya adalah "Start Read/Write Benchmark". Ketika Anda mengklik tombol siapa pun itu mulai benchmarking hard disk.
Cara benchmark disk I / O
Apakah ada sesuatu yang lebih Anda inginkan?
Suominen benar, kita harus menggunakan semacam sinkronisasi; tetapi ada metode yang lebih sederhana, conv=fdatasync akan melakukan pekerjaan itu:
dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output1024+0records in1024+0 records out402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s
Jika Anda ingin akurasi, Anda harus menggunakan fio
. Hal ini membutuhkan membaca manual (man fio
) tapi 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 dekat dengan nomor 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 tulis berurutan dengan blok besar (ini harus dekat dengan nomor 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 lebih baik 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 angka 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
Meningkatkan --size
argumen untuk meningkatkan ukuran file. Menggunakan file yang lebih besar dapat mengurangi angka yang anda dapatkan tergantung pada teknologi drive dan firmware. File kecil akan memberikan"terlalu bagus & quot; hasil untuk media rotasi karena kepala baca tidak perlu bergerak sebanyak itu. Jika perangkat Anda hampir kosong, menggunakan file yang cukup besar untuk hampir mengisi drive akan memberi Anda perilaku kasus terburuk untuk setiap pengujian. Dalam hal SSD, Ukuran file tidak terlalu menjadi masalah.
Namun, perlu diketahui bahwa untuk beberapa media penyimpanan ukuran berkas tidak sepenting jumlah byte ditulis selama periode waktu yang singkat. Misalnya, beberapa SSD memiliki kinerja yang jauh lebih cepat dengan blok yang telah dihapus sebelumnya atau mungkin memiliki area flash SLC kecil yang digunakan sebagai cache tulis dan kinerja berubah setelah cache SLC penuh (misalnya seri Samsung EVO yang memiliki cache SLC 20-50 GB). 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 memotong kinerja menjadi 10% dari aslinya. Dan satu-satunya cara untuk melihat penurunan kinerja ini adalah dengan terlebih dahulu menulis 20+ GB secepat mungkin dan melanjutkan tes yang sebenarnya segera setelahnya. Tentu saja, ini semua tergantung pada beban kerja Anda: jika akses tulis Anda penuh dengan penundaan gondrong yang memungkinkan perangkat membersihkan cache internal, urutan pengujian yang lebih pendek akan mencerminkan kinerja dunia nyata Anda dengan lebih baik. Jika Anda perlu melakukan banyak IO, Anda perlu meningkatkan keduanya --io_size
dan --runtime
parameter. Perhatikan bahwa beberapa media (misalnya sebagian besar murah Perangkat flash) akan mengalami pengujian seperti itu karena chip flash cukup buruk untuk Aus dengan sangat cepat. Menurut pendapat saya, jika ada perangkat yang cukup buruk untuk tidak menangani pengujian semacam ini, itu tidak boleh digunakan untuk menyimpan data berharga dalam hal apa pun. Yang mengatakan, jangan ulangi tes tulis besar untuk 1000 kali karena semua sel flash akan memiliki beberapa tingkat keausan dengan menulis.
Selain itu, beberapa perangkat SSD berkualitas tinggi mungkin memiliki algoritme perataan keausan yang lebih cerdas di mana Cache SLC internal memiliki kecerdasan yang cukup untuk menggantikan data di tempat jika ditulis ulang saat data masih dalam cache SLC. Untuk perangkat tersebut, jika file tes lebih kecil dari total SLC cache perangkat, tes penuh selalu menulis ke SLC cache saja dan Anda mendapatkan angka kinerja yang lebih tinggi daripada perangkat dapat mendukung untuk menulis lebih besar. Jadi untuk perangkat seperti itu, Ukuran file mulai menjadi masalah lagi. Jika Anda tahu beban kerja Anda yang sebenarnya yang terbaik untuk menguji dengan ukuran file yang Anda benar-benar akan melihat dalam kehidupan nyata. Jika Anda tidak mengetahui beban kerja yang diharapkan, menggunakan ukuran file uji yang mengisi sekitar 50% perangkat penyimpanan akan menghasilkan hasil rata-rata yang baik untuk semua implementasi penyimpanan. Tentu saja, untuk pengaturan RAID 50 TB, melakukan tes tulis dengan file tes 25 TB akan memakan waktu cukup lama!
Perhatikan bahwa fio
akan membuat file sementara yang diperlukan saat dijalankan pertama kali. Ini akan diisi dengan data pseudorandom untuk menghindari angka yang terlalu bagus dari perangkat yang mencoba menipu dalam tolok ukur dengan mengompresi data sebelum menulisnya ke penyimpanan permanen. File sementara akan dipanggil fio-tempfile.dat
dalam contoh di atas dan disimpan dalam direktori kerja saat ini. Jadi Anda harus terlebih dahulu mengubah ke direktori yang dipasang pada perangkat yang ingin Anda uji. The fio
juga mendukung penggunaan media langsung sebagai target pengujian tetapi saya pasti menyarankan membaca halaman manual sebelum mencobanya karena kesalahan ketik dapat menimpa seluruh sistem operasi Anda ketika seseorang menggunakan akses media penyimpanan langsung (misalnya secara tidak sengaja menulis ke perangkat OS alih-alih perangkat uji).
Jika Anda memiliki SSD yang bagus dan ingin melihat angka yang lebih tinggi, tingkatkan --numjobs
di atas. Itu mendefinisikan konkurensi untuk membaca dan menulis. Semua contoh di atas memiliki numjobs
set ke 1
jadi pengujiannya adalah tentang pembacaan dan penulisan proses berulir tunggal (mungkin dengan kedalaman antrian atau set QD dengan iodepth
). SSD kelas atas (misalnya Intel Optane 905p) harus mendapatkan angka tinggi bahkan tanpa meningkat numjobs
banyak (misalnya . 4
harus cukup untuk mendapatkan angka spesifikasi tertinggi) tetapi beberapa"Enterprise & quot; SSD perlu berkisar 32
-128
untuk mendapatkan Nomor spesifikasi karena latensi internal perangkat tersebut lebih tinggi tetapi throughput keseluruhannya gila. Perhatikan bahwa peningkatan numbjobs
untuk nilai tinggi biasanya meningkatkan hasil kinerja benchmark angka tetapi jarang mencerminkan kinerja dunia nyata dengan cara apa pun.
Saya tidak akan merekomendasikan menggunakan /dev/urandom
karena itu berbasis perangkat lunak dan lambat seperti babi. Lebih baik untuk mengambil sepotong data acak pada ramdisk. Pada pengujian hard disk acak tidak masalah, karena setiap byte ditulis apa adanya (juga pada ssd dengan dd). Tetapi jika kita menguji dedupped ZFS pool dengan nol murni atau data acak, ada perbedaan kinerja yang sangat besar.
Sudut pandang lain haruslah penyertaan 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. Yang 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 in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal 0m0.441suser 0m0.004ssys 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 benchmarking,
Jika Anda ingin memantau disk membaca dan menulis kecepatan secara real-time Anda dapat menggunakan iotop alat.
Hal ini berguna untuk mendapatkan informasi tentang bagaimana disk melakukan untuk aplikasi tertentu atau beban kerja. Output akan menunjukkan kecepatan baca / tulis per proses, dan total kecepatan baca / tulis untuk server, mirip dengan top
.
Instal iotop
:
sudo apt-get install iotop
Jalankan:
sudo iotop
Alat ini sangat membantu untuk memahami bagaimana disk melakukan untuk beban kerja tertentu dibandingkan tes yang lebih umum dan teoritis.
Kecepatan tulis
$ dd if=/dev/zero of=./largefile bs=1M count=10241024+0 records in1024+0 records out1073741824 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=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s
bonnie++ adalah utilitas benchmark utama yang saya tahu untuk linux.
(Saat ini saya sedang mempersiapkan livecd linux di tempat kerja dengan bonnie++ di atasnya 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 filesystem berbasis ram bisa sangat informatif bagi pemula.
Saya tidak tahu apakah itu termasuk dalam Ubuntu, tetapi Anda dapat mengompilasinya dari sumber dengan mudah.
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 di: CONTOH BONNIE++ SEDERHANA.
Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .