Soru blok büyüklüğü ile IO arasındaki ilişki nedir?


Geçenlerde disk hakkında okudum ve bu da bana 3 farklı şüpheye neden oldu. Ve bunları bir araya getiremiyorum. Şaşkın olduğum üç farklı terim var block size, IO ve Performance.

Süperblock hakkında okuyordum slashroot ifadeyle karşılaştığımda

Daha büyük bir blok boyutuna sahipseniz, daha az IOPS gerçekleştirilecektir.   dosya sistemi.

Bundan anladığım kadarıyla, eğer 1024 KB veri okumak istersem, 4KB / 4096B blok boyutuna sahip bir disk (A demek), 64 KB blok büyüklüğünde bir diskten (Say B) daha fazla IO alacaktır.

Şimdi sorum şu: Bir AO'nun ne kadar daha fazla diske ihtiyacı var?

Bu verileri okumak için gereken IO talebinin sayısını anladığım kadarıyla, her IO isteğinin boyutuna da bağlı olacaktır.

  • So who is deciding what is the size of the IO request? Is it equal to the block size? Bazı insanlar, uygulamanızın IO talebinin büyüklüğüne yeterince karar verdiklerini, ancak OS'nin tek isteği birden fazla GÇ'de nasıl ayırdığını söylüyor. There must be a limit after which the request splits in more then one IO. How to find that limit ?
  • Is it possible that in both disk (A and B) the data can be read in same number of IO?
  • Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?
  • If the data is sequential or random spread, does CPU provides all block address to read once?

Ayrıca

IOPS sayısı = mümkün = 1 / (ortalama dönme gecikmesi + ort. arama süresi)

Verim = IOPS * IO boyutu

Bir disk için IOPS'nin yukarısından her zaman düzeltilecek, ancak IO boyutu değişken olabilir. Bu yüzden mümkün olan maksimum verimi hesaplamak için maksimum IO boyutuna ihtiyacımız var. Ve anladığım kadarıyla eğer bir diskten çıktıyı artırmak istersem, bir istekte gönderebileceğim maksimum veri ile istekte bulunurdum. Bu varsayım doğru mu?

Çok fazla sorudan dolayı özür dilerim ama bir süredir bu konu hakkında okudum ve tatmin edici bir cevap alamadım. Aynı konuda farklı görüşler buldum.


5
2017-07-11 09:00


Menşei




Cevaplar:


Bence Wikipedia makalesi Yeteri kadar iyi açıklar:

Yanıt süresi ve iş yükünün eş zamanlı özellikleri yoktur, IOPS aslında anlamsızdır.
  ...
  Ölçüm cihazları gibi, depolama cihazı üreticileri tarafından yayınlanan IOPS numaraları, gerçek dünya uygulama performansı ile doğrudan ilişkili değildir. ...

Şimdi sorularına:

Öyleyse, IO talebinin büyüklüğüne kim karar veriyor?

Bu, kendim gibi programcı olmayan birine cevap vermenin kolay ve zor bir sorudur.

Her zamanki gibi cevap tatmin edici değil ”değişir" ...

Bir uygulama tarafından disk depolamasıyla ilgili G / Ç işlemleri genellikle işletim sistemine sistem çağrılarıdır ve boyutları hangi sistem çağrısının yapıldığına bağlıdır.

Linux’a diğer işletim sistemlerinden daha çok aşinayım, dolayısıyla bunu referans olarak kullanacağım.

G / Ç işlemlerinin boyutu gibi open() , stat()  , chmod() ve benzeri neredeyse göz ardı edilebilir.
Bir dönen diskte, bu çağrıların performansı, esas olarak, disk aktüatörünün, kolu ne kadar hareket ettirmesi gerektiğine ve kafa tablasındaki doğru pozisyonu okuyacağına bağlıdır.

Öte yandan, read() ve write() Aramalar başlangıçta uygulama tarafından belirlenir ve arasında değişebilir 0 ve 0x7ffff000 Tek bir G / Ç isteğinde (2,147,479,552) bayt ...

Tabii ki böyle bir sistem çağrısı, uygulama tarafından yapılmış ve OS tarafından alındığında, çağrı alacak zamanlanmış ve sıraya alındı (O_DIRECT bayrağı, sayfa önbelleğini ve arabellekleri by-pass etmek için kullanıldı ve doğrudan G / Ç seçildi).

Özet sistem çağrısının, ayrık olarak sıralanan temel dosya sistemi üzerindeki işlemlere eşleştirilmesi gerekir. bloklar (genellikle dosya sistemi oluşturulduğunda boyutu ayarlanır) ve sonunda disk sürücüsü ya da sabit disk sektörleri 512 veya 4096 bayt veya 2K, 4K, 8K veya 16K SSD hafıza sayfaları.

(Tipik olarak, okuma ve yazma aramaları genellikle en iyi performansla sonuçlanan temel diski ile gerçekten uyumlu olan 512B veya 4KB'ye ayarlanır.)

Talebin daha sonra bir G / Ç'de ayrıldığı bir sınır olmalıdır. Bu sınırı nasıl bulabilirim?

Evet, kılavuzda belgelenen Linux'ta bir sınır var. read() veya write() sistem çağrısı maksimum dönecektir 0x7ffff000 (2,147,479,552) bayt. Büyük dosyaları daha büyük okumak için ek sistem çağrılarına ihtiyacınız olacaktır.

Her bloğu okumak tek bir IO anlamına mı geliyor?

Anladığım kadarıyla, bir sistem çağrısının her gerçekleşmesi, bir IO olayı olarak sayılır.

Bir tek read() sistem çağrısı, 1 I / 0 olayı olarak sayılır ve ne X ne de Y IO'ları, sistem çağrısının bir dosya sisteminden X bloklarına erişme veya Y sabit diskten Y sektörlerini okumaya nasıl dönüştürüldüğüne / uygulanmasına bakılmaksızın sayılmaz.


2
2017-07-11 12:55



Cevap için çok teşekkürler. Açıkladığınızı anladığımı düşünüyorum, bu yüzden esasen, GÇ ile blok büyüklüğü arasında doğrudan bir ilişki olmaması. Ancak durum buysa, "Daha büyük blok büyüklüğü ile daha az IOPS gerekli" ifadesinin doğru olmadığını söylemek doğru olur mu? - Ankit Kulkarni


Bu ifadeyi çözmeye çalıştığınız anlaşılıyor:

"Dosya sisteminiz için daha büyük blok boyutuna sahipseniz daha az IOPS gerçekleştirilecektir."

Orijinal yazarın anlamını daha açık hale getirmek için bu ifadeyi yeniden yazmayı deneyeyim:

"Belirli bir dosyayı belirli bir boyutta okumak için (10 MB gibi), daha büyük bir blok boyutuyla biçimlendirilmiş bir dosya sistemi muhtemelen Daha küçük bir blok boyutu ile biçimlendirilmiş bir dosya sisteminden daha az sayıda okuma işlemi gerçekleştirmesi gerekir. "

İnşallahın orijinalinden biraz daha anlamlı olduğunu umarım.

Bu ifadeyi düzgün bir şekilde ayrıştırmak ve a) disk yerine "dosya sistemi" teriminin kullanılmasının nedenini anlamak ve b) "muhtemelen" sinir bozucu, veri oturanlar arasındaki tüm yazılım katmanları hakkında çok daha fazla bilgi edinmeniz gerekir. bir disk (veya SSD) ve userland uygulamalarında. Googling'i başlatmak için size birkaç işaret verebilirim:

Eğirme diskleri için:

  • sektör boyutu (disk) vs blocksize (dosya sistemi)

Önbelleğe alma hakkında bilgi edinin:

  • OS çekirdeğinde sayfa / arabellek önbelleği

  • Kullanıcı düzeyinde kütüphanelerde I / O önbelleğe alma (en önemlisi libc ve libc ++)

SSD'ler veya diğer flaş tabanlı depolama için, bazı ek komplikasyonlar vardır. Flash depolama biriminin Sayfa birimlerinde nasıl çalıştığını ve flash tabanlı depolamanın neden bir çöp toplama işlemi gerektirdiğini araştırmalısınız.


0



Cevap için teşekkürler chetan. medium.com/databasss/... Ancak, her bir sistem çağrısının bir IO olayı meydana gelmesi durumunda, her bir yanıtı @HBruijin yanıtlaması için makaleyi okuyun ve tek bir okuma IO çağrısı yapılıp yapılmadığını söyleyin, ~ 2 GB'a kadar okuyabilir (man7.org/linux/man-pages/man2/read.2.html#NOTES0) bu yüzden benim anlayışım "bir dosya sisteminin ne kadar blok büyüklüğüne sahip olacağı önemli değil" ve tüm bunlara bağlı olarak tek bir okunmuş çağrı ne kadar bayt olarak ayarlanacağıdır. Böylece IOPS blok boyutundan bağımsızdır. doğru mu anladı? - Ankit Kulkarni
@AnkitKulkarni problemi, yığının farklı katmanları için bilgi karıştırmak ve eşleştirmek ve bunu anlamaya çalışmak gibi görünüyor. İşaretlediğiniz read () manpage, C programında kullanılabilen bir kütüphane çağrısıdır ve doğrudan tek bir okuma sistemine eşlemek zorunda değildir. Genel olarak, unix i / o sistemi disk / ssd / controller-cache / device-drivers / virtual-memory-ve filesytem / user-level-library vb.'den birçok katman içerir. Ve sonuç kod diski için uygulama kodu eylemlerini ilişkilendirir. Her katmanın rolünü anlamalısınız. Başka bir deyişle, basit bir doğrudan haritalama yoktur. - chetan