Sabit sürücünün performansı nasıl kontrol edilir (Terminal veya GUI üzerinden). Yazma hızı. Okuma hızı. Önbellek boyutu ve hızı. Rastgele hız
Yanıtlar:
hdparm başlamak için iyi bir yer.
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 bilgi de verecek.
dd size yazma hızı hakkında bilgi verecektir.
Sürücüde bir dosya sistemi yoksa (ve yalnızca o zaman ), kullanın of=/dev/sda.
Aksi takdirde, / tmp üzerine yerleştirin ve yazıp test çıktı dosyasını silin.
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
Daha fazla istediğin bir şey var mı?
/dev/urandomyanı sıra /dev/zerogirişleri de öneririm dd.
/tmpDosya sistemi genellikle bu gün Ramdiski kullanıyor. Yani yazmak /tmp, disk alt sisteminizi değil belleğinizi test ediyor gibi görünüyor.
Suominen haklı, bir çeşit senkronizasyon kullanmalıyız; ama daha basit bir yöntem var, conv = fdatasync işi yapacak:
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
Kullanmasını tavsiye etmem /dev/urandomçünkü yazılım tabanlı ve domuz kadar yavaş. Ramdisk üzerinde rastgele veri yığınını almak daha iyidir. Sabit disk testlerinde rastgele önemli değil, çünkü her bayt olduğu gibi yazılmıştır (ayrıca ssd'de de dd ile). Fakat eğer tekilleştirilmiş zfs havuzunu saf sıfır veya rastgele verilerle test edersek, büyük performans farkı vardır.
Başka bir bakış açısı senkronizasyon zamanı dahil etme olmalıdır; tüm modern dosya sistemleri dosya işlemlerinde önbelleklemeyi kullanır.
Disk hızını gerçekten ölçmek ve belleği değil, önbellekleme etkisinden kurtulmak için dosya sistemini eşitlemeliyiz. Bu kolayca yapılabilir:
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"
Bu yöntemle çıktı alırsınız:
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
bu yüzden disk veri hızı sadece 104857600 / 0.441 = 237772335 B / s -> 237MB / s
Önbellekle karşılaştırıldığında 100 MB / sn'den daha düşük.
Mutlu kıyaslama,
Diski izlemek ve gerçek zamanlı yazma hızını izlemek istiyorsanız, iotop aracını kullanabilirsiniz .
Bu, bir diskin belirli bir uygulama veya görev için nasıl performans gösterdiği hakkında kesin bilgi almak için kullanışlıdır. Çıktı size işlem başına okuma / yazma hızını ve sunucuya çok benzeyen toplam okuma / yazma hızını gösterecektir top.
İotop'u kurmak için:
sudo apt-get install iotop
Çalıştırmak için:
sudo iotop
Doğruluk istiyorsanız, kullanmanız gerekir fio. Kılavuzu ( man fio) okumayı gerektirir, ancak size doğru sonuçlar verecektir. Herhangi bir doğruluk için tam olarak ne ölçmek istediğinizi belirtmeniz gerektiğini unutmayın. Bazı örnekler:
Büyük bloklarla sıralı OKUMA hızı (bu, sürücünüzün teknik özelliklerinde gördüğünüz sayıya yakın olmalıdır):
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
Büyük bloklarla sıralı WRITE hızı (bu, sürücünüzün teknik özelliklerinde gördüğünüz sayıya yakın olmalıdır):
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
Random 4K, QD1'i okuyor (bu, kesinlikle daha iyisini bilmiyorsanız, gerçek dünya performansı için gerçekten önemli olan sayıdır):
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
Karışık rastgele 4K, QD1'i senkronize ile okuyup yazıyor (bu, sürücünüzden beklemeniz gereken en kötü durum numarası, genellikle teknik özellik sayfasında listelenenlerin% 1'inden az):
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
--sizeDosya boyutunu artırmak için argümanı arttırın . Daha büyük dosyalar kullanmak, sürücü teknolojisine ve bellenime bağlı olarak aldığınız sayıları azaltabilir. Küçük dosyalar, dönme medyası için "çok iyi" sonuçlar verir çünkü okuma kafasının bu kadar hareket etmesi gerekmez. Cihazınız neredeyse boşsa, sürücüyü neredeyse doldurmak için yeterince büyük bir dosya kullanmak, her test için en kötü durum davranışını sağlayacaktır. SSD durumunda, dosya boyutu o kadar önemli değil.
Ancak, bazı depolama ortamları için dosyanın boyutunun kısa sürede yazılan toplam bayt kadar önemli olmadığını unutmayın. Örneğin, bazı SSD'ler önceden silinmiş bloklarla daha hızlı bir performansa sahip olabilir veya yazma önbelleği olarak kullanılan küçük SLC flaş alanına sahip olabilir ve SLC önbelleği dolduğunda performans değişir. Başka bir örnek olarak, Seagate SMR HDD'leri oldukça yüksek bir performansa sahip yaklaşık 20 GB PMR önbellek alanına sahiptir, ancak tam dolduğunda doğrudan SMR alanına yazmak performansı orijinalinden% 10'a kadar düşürebilir. Ve bu performans kaybını görmenin tek yolu, mümkün olduğunca çabuk 20+ GB yazmak. Tabii ki, bunların hepsi iş yükünüze bağlıdır: Yazma erişiminiz cihazın dahili önbelleği temizlemesine izin veren uzunca bir gecikmeyle doluysa, daha kısa test dizileri, gerçek dünya performansınızı daha iyi yansıtacaktır. Çok fazla GÇ yapmanız gerekiyorsa, her ikisini de artırmanız gerekir.--io_sizeve --runtimeparametreler. Bazı ortamların (örneğin, çoğu flaş aygıtının) bu tür testlerden ekstra aşınma alacağına dikkat edin. Kanımca, herhangi bir cihaz bu tür testlerle başa çıkmayacak kadar zayıfsa, hiçbir durumda değerli veriyi tutmak için kullanılmamalıdır.
Ek olarak, bazı yüksek kaliteli SSD aygıtları, dahili SLC önbelleğinin, aynı adres alanına (yani, test dosyasına, yani test dosyasına) ulaşması durumunda, test sırasında yeniden yazılan verileri değiştirmek için yeterli akıllıa sahip olduğu durumlarda daha akıllı aşınma dengeleme algoritmalarına sahip olabilir. toplam SLC önbelleğinden daha küçüktür). Bu tür cihazlar için, dosya boyutu tekrar önemli olmaya başlar. Gerçek iş yükünüze ihtiyacınız varsa, gerçek hayatta göreceğiniz dosya boyutlarını test etmek en iyisidir. Aksi halde, numaralarınız çok iyi görünebilir.
fioİlk çalıştırmada gerekli geçici dosyayı yaratacağını unutmayın . Kalıcı depolamaya yazmadan önce, verileri sıkıştırarak hile yapan cihazlardan çok iyi sayılar almamak için rastgele verilerle doldurulacaktır. Geçici dosya fio-tempfile.datyukarıdaki örneklerde çağrılacak ve mevcut çalışma dizininde saklanacaktır. Bu nedenle, önce test etmek istediğiniz cihaza monte edilmiş dizine geçmelisiniz.
İyi bir SSD'niz varsa ve daha da yüksek sayılar görmek istiyorsanız, --numjobsyukarıda artış yapın . Bu, okuma ve yazma için eşzamanlılığı tanımlar. Yukarıdaki örnekler, her adres numjobsiçin ayarlanır 1, böylece deney, tek dişli işlem okuma ve (bir sıra ile ayarlanmış mümkün olan yazma ilgili iodepth). Yüksek sonunda SSD'ler (örneğin Intel Optane) bile artırmadan yüksek sayılar almalısınız numjobsçok (örneğin 4yüksek spec numaralarını almak için yeterli olmalı) ama bazı "Atılgan" SSD'ler giderek gerektirir 32- 128Spec sayılarını almak için çünkü bu iç gecikme Cihazlar daha yüksek ancak genel çıkışlar delilik.
max_sectors_kb. Yukarıdaki örnek komutları 1 MB'lık blok boyutu kullanacak şekilde değiştirdim çünkü gerçek dünya donanımıyla çalışıyor gibi görünüyor. Ayrıca bunun fsyncokuma için önemli olmadığını da test ettim .
iodepthiçin 1gerçek dünya programları genellikle algoritmaları kullanıyoruz tam da rastgele erişim / böyle derinlik ise, derinlik Sonuç olarak herhangi 1 daha yüksek çalışmaz mantık için "çok düşük" senin G / Ç aygıt kötü. Bazı SSD cihazlarının 32'den daha yüksek derinlikten fayda sağlayacağı doğrudur. Ancak, okuma erişimi gerektiren ve 32'den daha yüksek olanları tutabilen herhangi bir gerçek dünya iş yüküne işaret edebilir misiniz ? TP; DR: yüksek gecikme cihazı ile delicesine yüksek okuma benchmark numarasını çoğaltmak istiyorsanız kullanın, iodepth=256 --numjobs=4ancak bu rakamları gerçek olarak görmeyi asla beklemeyin.
bonnie ++, linux için bildiğim en önemli referans aracıdır.
(Şu anda üzerinde Windows tabanlı makinemizi test etmek için bonnie ++ ile işyerinde linux livecd hazırlıyorum!)
Önbellekleme, senkronizasyon, rastgele veri, diskte rastgele konum, küçük boyutlu güncellemeler, büyük güncellemeler, okuma, yazma vb. İle ilgilenir. dosya sistemi acemi için çok bilgilendirici olabilir.
Ubuntu'da yer alıp almadığı hakkında hiçbir fikrim yok, ancak kaynağından kolayca derleyebilirsiniz.
Yazma hızı
$ 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
Blok boyutu aslında oldukça büyük. 64k ve hatta 4k gibi daha küçük boyutlarda deneyebilirsiniz.
Okuma hızı
Bellek önbelleğini temizlemek için aşağıdaki komutu çalıştırın
$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
Şimdi yazma testinde oluşturulan dosyayı okuyun:
$ 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
bonnie ++ kullanımı hakkında bazı ipuçları
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
Biraz daha fazlası: BASİT BONNIE ++ ÖRNEK .
Bütünlüğü kontrol edin, sahte flaş sürücüleri tespit edin ve performansını üç çekimde yapın.
Bu cevaba daha fazlası .