Pertanyaan Cara memeriksa kinerja hard disk


Cara memeriksa kinerja hard drive (Baik melalui terminal atau GUI). Kecepatan tulis. Kecepatan baca. Ukuran dan kecepatan cache. Kecepatan acak.


260
2017-12-12 00:22


asal


Pertanyaan serupa telah ditanyakan unix.stackexchange.com/questions/108838/… , stackoverflow.com/questions/1198691/… dan serverfault.com/questions/219739/ ... . - Anon


Jawaban:


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 kemudian), gunakan of=/dev/sda.

Jika tidak, pasang pada / tmp dan tulis kemudian hapus file output pengujian.

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.
    • Alternatif lain, luncurkan utilitas disk Gnome dari baris perintah dengan menjalankan gnome-disks
  2. Pilih hard disk Anda di sebelah kiri.
  3. Sekarang klik "Benchmark - Ukur Kinerja Drive" di panel kanan.
  4. Jendela baru dengan bagan terbuka. Anda akan menemukan dan dua tombol. Salah satunya adalah untuk "Mulai Baca Saja Benchmark" dan satu lagi adalah "Mulai Baca / Tulis Patokan". Ketika Anda mengklik tombol siapa pun mulai pembandingan hard disk.

test

Bagaimana tolok ukur disk I / O

Artikel

Adakah yang lebih Anda inginkan?


342
2017-12-12 00:34



Saya akan merekomendasikan pengujian /dev/urandom sebaik /dev/zero sebagai masukan untuk dd ketika menguji SSD sebagai kompresibilitas data dapat memiliki efek besar pada kecepatan tulis. - Ian Mackinnon
Tidak ada "Sistem ->" pada Ubuntu 12.04 Unity saya. Atau setidaknya saya belum menemukannya. Dan saya tidak melihat alat disk itu tidak dalam Pengaturan Sistem ... O_o Tapi saya benar-benar berhasil menjalankannya: / usr / bin / palimpsest - Fran Marzoa
Perhatikan bahwa sejak 12.10 itu hanya disebut Disk dan dapat ditemukan melalui Kesatuan. - Paul Lammertsma
Pada Gnome ini telah dipindahkan ke Aplikasi -> System Tools -> Preferences -> Disk Utility. Untuk mereka yang menggunakan yang membenci Kesatuan. - Ken Sharp
Itu /tmp filesystem sering menggunakan ramdisk hari ini. Jadi menulis untuk /tmp tampaknya akan menguji memori Anda, bukan subsistem disk Anda. - Zoredache


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

73
2017-08-18 18:31



Ini adalah jawaban yang menggunakan perintah / opsi yang berbeda dari yang lain. Saya melihat ini adalah sebuah jawaban yang layak untuk mempostingnya sendiri. - Alaa Ali
Mengapa Anda menggunakan 384k sebagai ukuran blok? - Diego F. Durán
@Diego Tidak ada alasan. Itu hanya sebuah contoh. Anda dapat menggunakan yang lain. (antara sekitar 4k ... 1M) Tentu saja, blocksize yang lebih besar akan memberikan kinerja yang lebih baik. Dan tentu saja mengurangi jumlah hitung saat Anda menggunakan bs besar, atau butuh waktu satu tahun untuk menyelesaikannya. - Tele
itu tidak dapat diandalkan oleh alat mark bench seperti nomor iozone dan sysbench jauh lebih rendah - MSS


Saya tidak akan merekomendasikan penggunaan /dev/urandom karena perangkat lunak berbasis dan lambat sebagai babi. Lebih baik mengambil sepotong data acak di ramdisk. Pada pengujian hard disk secara acak tidak masalah, karena setiap byte ditulis sebagaimana adanya (juga pada SSD dengan dd). Tetapi jika kita menguji kumpulan zfs yang diredupkan 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 menyingkirkan efek cache. Itu dapat dengan mudah dilakukan oleh:

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

dengan metode yang Anda dapatkan hasilnya:

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

sehingga disk datarate hanya 104857600 / 0,441 = 237772335 B / dt -> 237MB / s

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

Patok banding yang bagus,


42
2017-12-06 23:18





Jika Anda ingin memonitor disk membaca dan menulis kecepatan real-time Anda dapat menggunakan iotop alat.

Ini berguna untuk mendapatkan informasi pasti tentang bagaimana kinerja suatu disk untuk aplikasi atau tugas tertentu. Output akan menunjukkan Anda membaca / menulis kecepatan per proses, dan kecepatan baca / tulis total untuk server, sangat mirip top.

Untuk menginstal iotop:

sudo apt-get install iotop  

Untuk menjalankannya:

sudo iotop

30
2017-09-17 14:24





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 dengan itu!)

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

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

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


23
2018-02-03 16:13





Tulis kecepatan

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


Baca kecepatan

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

17
2018-05-05 22:12





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 lagi di: SIMPLE BONNIE ++ EXAMPLE.


12
2017-09-28 19:02





Jika Anda ingin akurasi, Anda harus menggunakan fio. Ini membutuhkan membaca manual (man fio) tetapi ini akan memberi Anda hasil yang akurat. Perhatikan bahwa untuk akurasi apa pun, Anda perlu menentukan apa yang ingin Anda ukur. Beberapa contoh:

Kecepatan BACA sekuensial dengan blok-blok besar (ini harus dekat 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 WRITE sekuensial dengan blok-blok besar (ini harus dekat 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 pasti lebih baik):

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 pernah Anda harapkan dari drive Anda, biasanya 1-10% 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

Tingkatkan --size argumen untuk meningkatkan ukuran file. Menggunakan file yang lebih besar dapat mengurangi jumlah yang Anda peroleh tergantung pada teknologi drive dan firmware. File kecil akan memberikan hasil yang "terlalu bagus" untuk media rotasi karena kepala baca tidak perlu banyak bergerak. Jika perangkat Anda hampir kosong, menggunakan file yang cukup besar untuk hampir memenuhi drive akan membuat Anda mendapatkan perilaku terburuk untuk setiap tes. Dalam kasus SSD, ukuran file tidak begitu penting.

Perhatikan itu fio akan membuat file sementara yang diperlukan pada saat pertama dijalankan. Ini akan diisi dengan data acak untuk menghindari angka yang terlalu bagus dari perangkat yang menipu 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.


9
2018-01-01 18:14



Beberapa pengaturan fio agak aneh dan mungkin tidak optimal. Misalnya, memiliki ukuran blok besar (2Mbytes) ketika Anda melakukan I / O langsung dengan mesin I / O asinkron cenderung mengarah pada banyak pemisahan di kernel sehingga menciptakan overhead. Mengirim secara berkala fsyncKetika Anda hanya melakukan membaca juga terlihat tidak biasa. Saya setuju fio berguna tetapi saya akan merekomendasikan pembaca hati-hati menyelidiki parameter mana yang ingin mereka gunakan daripada hanya menyalinnya kata demi kata dari versi 20180102 jawaban di atas ... - Anon
@Anon: Anda benar, yang optimal untuk membaca berurutan akan cocok /sys/block/sd?/queue/max_sectors_kb karena mungkin lebih rendah dari batas perangkat keras sebenarnya yang biasanya jauh lebih dari 2MB dalam contoh di atas. Namun, saya berasumsi bahwa overhead kecil yang disebabkan oleh CPU tidak masalah dibandingkan dengan kecepatan perangkat I / O yang sebenarnya. Itu fsync adalah tidak ada operasi untuk dibaca sehingga tidak akan mempengaruhi hasil - Saya menyimpannya sehingga lebih mudah untuk memahami perbedaan antara baris perintah yang berbeda. Apakah Anda mengalami masalah mendapatkan hasil yang sesuai dengan spesifikasi pabrikan? - Mikko Rantalainen
Tidak juga, saya hanya memiliki (beberapa) pengalaman bekerja dengan fio dan Linux. Sebenarnya jika Anda menebak ukuran blok terbaik akan bijaksana untuk memulai dengan optimal_io_size jika tersedia (tetapi Anda dapat mengasumsikan 64Kbytes jika 0 - itulah yang kernel lakukan) .Tidak tepat, saya hanya memiliki (beberapa) pengalaman bekerja dengan fio dan Linux. Sebenarnya jika Anda menebak ukuran blok terbaik akan lebih bijaksana untuk memulai dengan optimal_io_size jika tersedia (tetapi Anda dapat mengasumsikan 64Kbytes jika 0 - itulah yang kernel lakukan). - Anon
Saya baru saja menguji ulang beberapa perangkat. Menggunakan tes baca sekuensial di atas (ukuran blok 2MB) Saya mendapat 280 MB / dtk dari SSD Samsung 850 EVO dan 1070 MB / d dari Intel 910 SSD. Dengan ukuran blok 64k dan commandline yang identik, saya mendapat 268 MB / s dari 850 EVO dan 1055 MB / dt dari 910 SSD. Setidaknya untuk jenis perangkat ini, menggunakan ukuran blok 2 MB tampaknya meningkatkan hasil sekitar 1-5% meskipun menyebabkan kernel membagi permintaan ke perangkat keras. Saya kira bahkan dengan optimasi kernel overhead mengirimkan lebih banyak syscalls lebih buruk daripada membelah di dalam kernel. - Mikko Rantalainen
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 tampaknya bekerja dengan perangkat keras dunia nyata. Dan saya juga menguji itu fsync tidak masalah untuk membaca. - Mikko Rantalainen