IOPS neden önemlidir?


32

IOPS ve verimin ne olduğunu biliyorum Verim, MB / s veri akışını ölçer ve IOPS saniyede kaç G / Ç işlemi gerçekleştiğini söyler.

Anlamadığım şey, neden birçok depolama hizmetinin sağladıkları IOPS'yi gösterdiğidir. Verimlilik yerine IOPS'yi bilmek istediğim bir senaryoyu gerçekten göremiyorum.

IOPS neden önemlidir? AWS neden depolama koşullarını IOPS'da gösteriyor? IOPS iş hacminden (MB / s) daha alakalı nerede?


DÜZENLE:

Bazı insanlar bu soruyu, sanki rastgele erişimin ne olduğunu ve performansı nasıl etkilediğini ya da HDD ve SSD'nin nasıl çalıştığını sorduğumu soruyorlar ... bu bilginin, depolama davranışında yeni olan insanlar için yararlı olduğunu düşünmeme rağmen, çok odaklanılıyor. bunun için ve sorunun amacı değil, soru şu: "Bir IOPS numarası gördüğümde ne kadar yeni bilgi alırım, bir çıktı (MB / s) numarası görmezdim?"



3
Büyük veri taşımak istiyorsanız, verimi önemsiyorsunuz. Çok sayıda küçük veriyi r / w'ye ihtiyacınız varsa, daha fazla IOPS'ye ihtiyacınız var. eg1 Aygıttan MB veri okuyabilen tek bir işlem varsa, daha yüksek verim elde etmek için yalnızca 1 işlem gerekir. eg2 Düzinelerce dosya özniteliği okumanız gerekiyorsa, her seferinde büyük miktarda veriye bakmazsınız, ancak küçük veri parçaları almak için çok fazla işlem yapmanız gerekir. Verimlilik düşük olur, ancak çok fazla operasyon yapmanız gerekir.
TafT

Yanıtlar:


32

çıktı

Verimlilik, dosyaları kopyalamak gibi şeyler yaparken kullanışlıdır. Neredeyse başka bir şey yaparken, rastgele okur ve sizi sınırlayacak diskte yazar.

IOPS

IOPS genellikle her veri paketinin boyutunu belirtir. Örneğin, AWS GP2, 16 KiB yük kapasitesiyle 10.000 IOPS yapabilir . Bu 160MiB / sn'ye kadar çoğalıyor. Ancak, tam taşıma kapasitesi boyutunu her zaman kullanmanız muhtemel değildir, bu nedenle gerçek iş hacmi muhtemelen daha düşük olacaktır. NB KiB, 1024 bayttır, KB ise 1000 bayttır.

Çünkü IOPS, size toplam işlem hacmini veren bir paket boyutu da belirtir. Oysa yüksek verim, yüksek IOPS'ye sahip olduğunuz anlamına gelmez.

Senaryolar

Bu senaryoları göz önünde bulundurun:

  • PC'nizi önyükleyin. Bilgisayarınızdaki bir SSD ile dönen disk arasındaki farkı düşünün; bu, birçok kişinin ilk elden deneyime sahip olduğu bir şeydir. Dönen bir disk ile önyükleme süresi bir dakika olabilir, oysa SSD ile bu süre 10 - 15 saniyeye kadar düşebilir. Bunun nedeni, bilgi talep edildiğinde daha yüksek IOPS’nin daha düşük gecikmeye neden olmasıdır. Dönen diskin verimi oldukça iyi, 150 MB / sn, ancak SSD'nin daha yüksek olmasına rağmen bunun daha hızlı olmasının nedeni bu değil - bilgi döndürme işleminin düşük gecikmesi.
  • Bir işletim sistemi güncellemesi yapmak. Diskin her yerine gidiyor, dosya ekliyor ve ekliyor. Düşük IOPS'niz olsaydı, verimden bağımsız olarak yavaş olurdu.
  • Bir veri tabanı çalıştırmak, örneğin büyük bir veri tabanından küçük miktarda veri seçmek. Dizinden okuyacak, birkaç dosyadan okuyacak, sonra bir sonuç verecektir. Yine bilgi toplamak için diskin her yerine gidiyor.
  • PC'nizde bir oyun oynuyor. Büyük olasılıkla diskin her tarafından çok sayıda doku yükler. Bu durumda, IOPS ve verim büyük olasılıkla gereklidir.

LTO Teyp

Bir an için bir teyp yedekleme sistemi düşünün. LTO6 400 MB / sn yapabilir, ancak (burada tahmin ediyorum) muhtemelen rastgele bir GİB bile yapamıyorum, GİB başına saniye kadar düşük olabilir. Öte yandan, eğer bir IOPS kasete bir veri paketi okumak veya yazmak olarak tanımlanırsa, muhtemelen bir sürü ardışık IOPS yapabilir.

Bir işletim sistemini kapalı banttan başlatmaya çalıştıysanız, uzun sürebilirdi, eğer işe yaradıysa. Bu nedenle IOPS genellikle verimden daha faydalıdır.

Bir depolama cihazını anlamak için muhtemelen rastgele veya sıralı IOPS ve IO büyüklüğü olup olmadığını bilmek istersiniz. Bundan verim elde edebilirsiniz.

AWS

AWS'nin, tüm depolama türleri için hem IOPS hem de verim rakamlarını bu sayfada yayınladığını unutmayın . Genel amaçlı SSD (gp2), maksimum 160 MB / sn veren 10.000 16KiB IOPS yapabilir. Hazırlanan IOPS (io1), maksimum 320 MB / sn veren 20.000 16KiB IOPS'dir.

GP2 birimlerinde GB başına 30IOPS sağlandığını, bu nedenle 10.000 IOPS alabilmek için 333.33GB birime ihtiyacınız olduğunu unutmayın. İo1 hacimlerinin benzer bir sınırlaması olup olmadığını hatırlamıyorum (bu tür bir şeyin test edildiği ortak sınavları yaptığımdan bu yana), ancak yaptıklarından şüpheleniyorum ve öyleyse muhtemelen GB başına 60IOPS.

Sonuç

Yüksek sıralı verim yararlıdır ve bazı durumlarda performansı sınırlayan faktördür, ancak çoğu durumda yüksek IOPS'nin daha önemli olması muhtemeldir. Tabii ki hala IOPS'dan bağımsız olarak makul bir performansa ihtiyacınız var.


IOPS'nin rasgele erişim performansını ölçtüğünü biliyorum, ancak aslında ne kadar hızlı yaptığınızı göstermiyor ... 10000 IOPS yapıyor olabilirsiniz, ancak bu ne kadar yavaş veya hızlı olabilir, bilmenin tek yolu kaç tane olduğunu bilmektir. MB / s işlemi tüketiyor.
mFeinstein

IOPS genellikle veri yükü boyutunu belirtir. AWS 16KiB diyor. Böylece 16KiB / s'de 10.000 G / Ç size 160 MB / sn verir.
Tim

2
16KB'deki 10000 IOPS, 8KB'de 20000 IOPS'ye çevirmeyecek (belki de ~ 11000). Bu, bir sürücüyü / iş yükünü değerlendirmek için hem IOPS hem de verimi bilmesi gerektiği anlamına gelir.
boot4life

4
Sadece bilgili olmak için, hala 1 IOPS, 1 IOP değil. S çoğul değildir
Matthew Steeples 24:17

1
Başkalarını düşünemiyorum. Yüksek IOPS olan birçok şey yüksek verimlilik sağlar, ancak çoğu durumda IOPS nedeniyle işlem hacmi kullanışsızdır. Başka bir örnek, ilişkisel bir veritabanı olabilir, ancak bu bir yazılım değildir. Bu sorudan başka ne istediğinizi bilmiyorum, sanırım kavramı size tamamen açıklandı. Yüksek arama süresi veya gecikme süresi olan herhangi bir şey muhtemelen düşük IOPS'ye sahiptir, ancak verim ayrılabilir ve bazı durumlarda yüksek olabilir.
Tim

57

Bunun nedeni, sıralı işlemin çoğu G / Ç etkinliğinin gerçekleştiği yer olmamasıdır.

Rastgele okuma / yazma işlemleri normal sistem faaliyetini daha iyi temsil eder ve bu genellikle IOPS tarafından bağlanır.

Sunucularımdan birinden müşterilerimize porno akışı (veya CDN'imize yükleme) doğada daha sıralıdır ve buradaki verimin etkisini göreceksiniz.

Ancak, pornoları kataloglayan ve sitedeki kullanıcı aktivitesini izleyen veritabanını korumak, doğada rastgele olacak ve altta yatan depolamanın yapabildiği küçük I / O işlemleri / saniye sayısıyla sınırlı olacaktır.

Veritabanlarını en üst düzeyde kullanabilmek için 2.000 IOPS'a ihtiyacım olabilir, ancak etkinlik türü nedeniyle yalnızca disk düzeyinde 30 MB / sn verim görebilir. Diskler 1200 MB / s kapasitesine sahiptir, ancak IOPS ortamdaki sınırlamadır.

Bu, bir depolama sisteminin kapasite potansiyelini açıklamanın bir yoludur. Bir SSD, 80.000 IOPS ve 600MB / s verim yapabilir. Bu kapasiteyi 6 normal 10k SAS diskiyle elde edebilirsiniz, ancak bu yalnızca 2.000 IOPS civarındadır.


Bana, IOPS'nin sistemimin MB / sn'nin işe yaramayacağı performansı hakkında bir fikir vereceği bir örnek verebilir misiniz?
mFeinstein

@mFeinstein Yukarıdaki porno örneğe bakın.
ewwhite

33
Porno örneği lol için +1
mFeinstein

2
Ayrıca, bir işletim sistemi muhtemelen birkaç küçük rasgele erişim gerçekleştirmektedir. Sıra çıktısı işe yaramaz. İşletim sistemini bir SSD'de, en azından PC'lerde çalıştırmak için bir neden.
sudo

3
Sık sık ~ 2MB / sn yapan tamamen kullanılmış diskler görüyorum. Bunun nedeni% 100 rastgele G / Ç'dir. Bazen, inanılmaz perf kazanımları muhtemelen disk üzerine sırayla verileri yerleştirerek olur (örneğin parçalanma, veritabanlarında indeksleme).
boot4life

6

İken ewwhite cevabı tamamen doğrudur, ben sadece fark perspektifte önemli neden yardım put için biraz daha somut sayılar sağlamak istedim.

Daha önceden doğru bir şekilde belirtildiği gibi, akışsız uygulamaların çoğu öncelikle sıralı olmayan disk işlemleri gerçekleştirir, bu nedenle IOPS teorik tepe verimine ek olarak önemlidir.

Bir iş arkadaşınız ve ben daha önce kullandığımız HDD'leri değiştirmek için geliştirme sistemlerimizde ilk olarak SSD'leri kurduğumuzda, bunun neden önemli olduğunu vurgulayan bazı performans ölçümleri yaptık:

SATA HDD Sonuçları:

Sıralı Okuma Verimi: ~ 100 MB / s
Sıralı Olmayan Okuma Verimi (2k blok, IIRC): ~ 1 MB / s

PCIe bağlı SSD Sonuçları:

Sıralı Okuma Verimi: ~ 700 MB / s
Sıralı Olmayan Okuma Verimi (2k blok, IIRC): ~ 125 MB / s

Örnekte açıkça görebileceğiniz gibi, sadece her cihaz için maksimum verim listelemek, bunların nasıl karşılaştırıldığına dair son derece yanlış bir resim verecektir. SSD, büyük dosyaları sırayla okurken HDD kadar sadece 6-7x kadar hızlıdır, ancak diskin farklı bölümlerinden küçük veri parçalarını okurken 100x'ten daha hızlıdır. Tabii ki, HDD’lerde, bu sınırlama, genel olarak, HDD’lerin, r / w kafasını istenen parçaya fiziksel olarak taşıması ve daha sonra, SSD’lerin hareket etmesi için fiziksel parçaların olmaması durumunda, istenen verilerin kafa altında dönmesini beklemesi gerektiği içindir.

Derleme sürelerimiz, maksimum verim miktarının basit bir karşılaştırmasından önerilenden çok daha çarpıcı bir şekilde gelişti. Önceden 30 dakikadan fazla süren kurulumlar, yaklaşık bir dakika içinde bitmiştir, çünkü büyük bir yapı sırasındaki disk G / Ç, tek tek çok büyük olmayan ve fiziksel olarak tüm diske dağılmış birçok ayrı kaynak dosyayı okumak ve yazmaktan ibarettir. .

Hem çıkış hem de IOPS numaraları sağlayarak, belirli bir iş yükünün belirli bir depolama aygıtında nasıl performans göstereceği hakkında daha iyi bir fikir edinebilirsiniz. Sadece parçalanmamış büyük miktarda veri akışı yapıyorsanız, maksimum verime oldukça yaklaşırsınız. Bununla birlikte, disk üzerinde sırayla depolanmayan çok sayıda küçük okuma ve / veya yazma yapıyorsanız, IOPS ile sınırlandırılırsınız.


IOPS'yi de ölçmediniz mi?
mFeinstein

3

Bir GÇ işlemi gerçekleştirmek için sürücü (ler) bir dizi işlemden geçmelidir. Mekanik bir sabit disk için ihtiyaç duydukları.

  1. Doğru parçaya gidin ve doğru başlığı seçin.
  2. Tabağın doğru konuma dönmesini bekleyin.
  3. Aslında veriyi aktar.

3 için geçen süre, veri bloğunun büyüklüğüne bağlıdır, ancak 1 ve 2 için geçen süre, isteğin boyutundan bağımsızdır.

Başlık verimi ve GİB rakamları aşırı vakaları temsil etmektedir. Başlık ekleme rakamları, her bir işlemin büyük bir veri bloğu içerdiği durumu temsil eder, bu nedenle sürücü, zamanının çoğunu gerçekte hareketli veriler olarak geçirir.

Başlık IOP'leri, veri bloklarının çok küçük olduğu bir durumu temsil eder, bu yüzden çoğu zaman kafaları aramak ve plakların dönmesini beklemek için harcanır.

Birçok iş yükü için bloklar, transfer edilecek blok sayısının blokların boyutundan çok daha önemli olduğu için yeterince küçüktür.


2

IO hacimleri üzerinde deneyimleyebileceğiniz iki tür darboğaz vardır (ya da genel olarak IO).

Gerçek performans gerçekten, mevcut bant genişliği ya da benzeri birimcost * boyutuyla ölçeklendirilen taşınan verinin hacmine dayanan bir bileşeni içerecek şekilde ölçülür, fakat aynı zamanda, sabit disk, ağ ya da istekler ile ilişkili bir ek yük de vardır. sayısız başka şeyler.

unitcost * size + ek yük. çizginin denklemi.

Unitcost büyükse veya boyut büyükse, o zaman cep telefonu şebekeleri gibi bu hacimlere göre şarj etmek mantıklı olur, diğer yandan genel giderler çok daha kritiktir.

Bunun basit bir denemesini kendiniz yapabilirsiniz, birkaç 1GB dosya içeren bir dizin oluşturabilirsiniz (veya pratik olan her ne ise, onu okumak / yazmak birkaç saniye sürecek kadar büyük bir şey olabilir) ve ardından milyonlarca 100 baytlık dosya içeren bir klasör oluşturabilirsiniz. (not, bu 0.1GB veri) ve daha sonra tüm bölümleri farklı diskler / diskler arasında söylemeye devam etmeye başladığınızda veriminize ne olduğunu görün; Küçük şeyler için dosya sayısı.

Amazon'un her iki şarj modelinin de farkında olduğunu ve altyapılarının yeteneklerini daha iyi temsil ettiğini buldum.

Mağazanın yine de bir “döngü” içinde transfer edebileceği ammount ile büyük ölçüde ilgili olan bir GİB'nin boyutunda bir sınır vardır, bu nedenle büyük talepler size birden fazla IOPS'ye mal olabilir.

Amazonlar'dan IOPS ve maliyetlendirme ile ilgili güzel bir parça var ve optimizasyonlardan geçirdikleri 'tasarruflar'

G / Ç Karakteristikleri ve İzlenmesi

Hepsini okumayın ama bu alanı merak ediyorsanız ilginç görünüyor.


2

Sorunuza cevap vermek

"Bir IOPS numarası gördüğümde, bir verim (MB / s) numarası göremediğim için hangi yeni bilgileri alırım?"

doğrudan, belirtilen kuyruk derinliği ve dosya boyutundaki G / Ç işleminin saniyede kaç depolama yapabileceğidir . Aşağıdaki formülü kullanarak verimi belirtilen koşullarda hesaplayabilirsiniz:

IOPS * dosya boyutu = Çıkış

Depolama testleri, dosya boyutuna ve sıra derinliğine bağlı olarak farklı sayıda IOPS üretebilir. Kuyruk derinliği = 1 veya 2 olduğunda, denetleyici önbelleklemenin avantajlarından yararlanmazken, kuyruk derinliği 32, 256, 512 sayısı birkaç kez artar ve çok fazla değişmez. 128KB dosya boyutunda IOPS sayısı 4KB dosyalarının yanında daha düşük olabilir, ancak hesap çıktı - daha yüksek.

Bir depolamanın performansını değerlendirmenin en iyi yolu, birkaç farklı blok büyüklüğü ve sıra derinliğinde IOPS ve verimlilik testleri aramaktır.


IOPS’yi bir miktar verim ile karıştırdığınızı düşünüyorum ... Verim sürekli erişimin bir eş anlamlısı değildir, ancak toplam MB / sn'lik depolama belirli bir zamanda işleyebildi. SSD aynı verime sahip olacak, sürekli erişim için olacak ... Rasgele erişim için verim olduğu gibi ... Genelde HDD'ler için arama süresinden dolayı çok daha az.
mFeinstein

Bu nedenle cevabınıza, başlangıçta sürekli erişime ve sonunda da rasgele erişime atıfta bulunduğunuzu eklemelisiniz, çünkü IOPS, rastgele erişimle de eşanlamlı değildir ... ölçüm
mFeinstein

@mFeinstein Cevabı değiştirdim, bir göz at.
Eugene

1

Genel olarak konuşursak, IOPS’nin iş çıktısından zordur. Çok fazla sayıda IOPS'niz varsa, çoğu zaman yeterli verim elde edersiniz.

Klasik sabit disklerde, eksen sayısı sınırlayıcı faktördür, çünkü kafa her sürücüde fiziksel olarak hareket ettirilmelidir: ve çok yavaş. SSD'ler çok daha iyi IOPS kapasitesine sahiptir.

Tek bir kullanıcınız varsa, büyük bir dosyayı ağa kopyaladığınızda, verileri almak için yalnızca bir düzine aramanız olabilir ve geri kalanı yalnızca diskten akış halinde olacaktır.

Bununla birlikte, bir veritabanına çarpıyorsanız veya çok fazla eşzamanlı kullanıcınız varsa, IOPS skyrocketingiyle aynı anda depolama alanınızın farklı bölümlerine erişmeniz gerekir.

İlişkisel bir veritabanında paralel olarak 10 satırın güncellenmesi yüzlerce IO üretilmesine neden olabilir: indeksleri okumak, verileri okumak, günlük dosyasını eklemek, endeksleri ve verileri güncellemek. Çoğu işletim sistemi ve veritabanı, mümkün olduğunda GÇ’leri önbelleğe alarak ve geciktirerek / gruplandırarak GÇ sayısını sınırlamak için çok çaba harcar.


1

Ben de kendi soruma cevap vereceğim çünkü çoğu cevabın konu dışında çok şey gittiğini ve cevabın çok daha basit olacağını düşünüyorum:

Yalnızca depolama aygıtlarınızın verimliliğine bakarsanız, olup bitenleri kaçırabilirsiniz ... Düşük performans varsa (düşük MB / sn) yavaş bir cihaza ya da bir HDD’de veya başka bir cihaza rastgele erişime sahip olabilirsiniz. Bu, rastgele erişimi güzel bir şekilde ele almaz.

IOPS'ye bakarak ve her bir G / Ç işleminin yığın boyutunu bilerek, depolama aygıtının ne kadar erişebileceğini ve bu IOPS'lerin veriminin ne olduğunu (yığın boyutu * IOPS) öğrenebilirsiniz.

Bu nedenle, yüksek IOPS'lere baktığımızda, depolama cihazınızın çok fazla rastgele erişime sahip olduğu sonucuna varabilirsiniz, bu düşük verim ile gelse bile .... veya belki de düşük IOPS'ye bakıyorsunuzdur; rölantide.

Böylece, IOPS'ye bakarak, verimin gerçekte ne anlama geldiğine dair bir kavrayış bulabiliriz, ikisi de birbirlerini tamamlar.


IOPS = Saniyedeki Girdi / Çıktı, çoğul değil, S izlemenin ihmal edilmemesi gerekiyor. :)
Eugene

1
Teşekkürler O değil çoğul hakkında, nasıl olduğunu ... sesler gibi bazı insanlar "G / Ç işlemi" için kısa olarak GİB atıfta gördük var Ama değiştirecektir yüzden evet, bu, karışıklığa neden olabilir
mFeinstein
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.