Yüksek disk G / Ç sırasında sistem performansını / yanıt verme yeteneğini artırma konusundaki ilerleme nedir?

Yüksek disk G / Ç olduğunda, sistem normalden çok daha yavaş ve daha az yanıt verme eğilimindedir. Linux çekirdeğinde bununla ilgili ilerleme nedir? Bu problem aktif olarak üzerinde çalışılıyor mu?

Bence çoğunlukla çözüldü. Ağır IO altındaki performansım 2.6.36'da iyileşti ve 2.6.37'de daha fazla iyileşmesini bekliyorum. Bu phoronix makalelerine bakın .

Wu Fengguang ve KOSAKI Motohiro bu hafta, "bellek baskısı ve çok sayıda kirli / geri yazma sayfası hatası altında yanıt vermiyor" hatası olarak adlandırdıkları bu yanıt verme sorunlarının bazılarını ele alacaklarına inandıkları yamaları yayınladılar. LKML'ye bu sorunu bildiren ve çekirdeğin vmscan'a uygulanan iki yamayı test eden kullanıcılardan Andreas Mohr başarılı olduğunu bildirdi. Andreas'ın problemi, USB 1.1 üzerinden bir katı hal sürücüsü bağlandığında EXT4 dosya sistemi yaparken sistemin tamamen yanıt vermemesidir (ve VT'ye geçiş 20+ saniye sürdü). Sisteminde / dev / zero dosyasından 300M yazarken sorun daha da kötüydü.

İşte hataya doğrudan bir bağlantı

Ayrıca Phoronix'ten

Neyse ki, testlerimizden ve bu sorunun düzeltildiğini görmek isteyen diğer Linux kullanıcılarının raporlarından, yayınlanan nispeten küçük vmscan yamaları sorunu daha iyi ele alıyor gibi görünüyor. Sistem çok büyük miktarda disk etkinliğini sürdürüyorsa, kullanıcı arayüzü (bizim durumumuzda GNOME) hala% 100 sıvı değildir, ancak kesinlikle eskisinden çok daha iyi ve şu anda Linux 2.6.35 çekirdeğinde bulunan şey.

Orada da Phoronix 2.6.36 sürüm duyuru

Görünüşe göre blok engeller ortadan kalkıyor ve bu da performansa yardımcı olmalı.

Uygulamada, engeller, yöneticilerin genellikle onları kapatmak ve risklerini almak için cazip hale gelene kadar, blok I / O performansını öldürmek için hoş olmayan bir üne sahiptir. Çağdaş donanım tarafından sağlanan etiketli kuyruk işlemleri mantıklı olarak iyi bir şekilde uygulanmalıdır, ancak bu özelliklerden yararlanma girişimleri genellikle zorluklar yaşamıştır. Bu nedenle, gerçek dünyada, bariyer operasyonunu vermeden önce I / O istek kuyruğunu boşaltarak, donanımın verileri kalıcı ortama vermesini sağlamak için bazı yıkama işlemleri atılarak bariyerler uygulanır. Kuyruk boşaltma işlemleri cihazı durduracak ve tam performans için gereken paralelliği öldürecektir; bariyer kullanımının acı verici olması şaşırtıcı değildir.

Adil I / O Programlaması ile ilgili bu LWN makalesi de var

IO'nun 2.6.28'de ext4'ün piyasaya sürülme zamanı hakkında büyük bir uyanış olduğunu söyleyebilirim. Aşağıdaki bağlantılar Linux Kernel Newbies Kernel sürümlerine aittir , Engelle ve Dosya Sistemleri bölümlerini gözden geçirmelisiniz. Bu elbette haksız bir duygu olabilir ya da sadece FS gelişimini izlemeye başladığım zaman, eminim baştan beri gelişiyor, ama ext4 sorunlarından bazılarının insanların IO yığınına sert bakmasına neden olduğunu hissediyorum, ya da ext4'ün tüm performans sorunlarını çözmesini beklemiş olabilirler ve daha sonra fark etmediklerinde problemlerin başka bir yerine bakmaları gerektiğini fark ettiler.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37