Yüksek disk G / Ç neden sistem yanıt verebilirliğini / performansını azaltır?

Yüksek disk G / Ç'nin sistemi neden bu kadar yavaşlattığını tam olarak anlayamadım. Benim için garip çünkü yavaşlamanın sadece sabit / optik sürücü verilerine bağlı olan süreçleri etkilemesini beklerdim, ancak yavaşlama RAM'e yüklenen şeyleri bile etkiler. Ben burada iowait'ten bahsediyorum .

İşlemci neden başka işler yapmak yerine bekliyor? Herkes bu sınırlamayı ve neden Linux çekirdeğinde çözülmediğini açıklayabilir mi? Dışarıda bu sorunu olmayan bir çekirdek var mı?

[ not ] Bu performans alanında bazı ilerlemeler kaydedilmiştir . Birincisi, sonraki çekirdekler (benim durumumda 2.6.37) çok daha duyarlı.

— tshepang
kaynak

Xeno, en son sorduğunuzda bunun Linux çekirdeğinde nasıl çözüldüğünü tam olarak açıklamadı mı?

— Michael Mrozek

Düzenlemeler göz önüne alındığında, bence önceki sorunun sorunun düzeltilmesi için kaydedilen ilerlemeyle ilgili olması, bu sorunun sorunun neden var olduğu hakkında olması.

— Steven D

@mic Steven haklı. Önceki soru ile ne demek istediğimle ilgili uzun bir tartışmamız vardı. xeno'nun cevabı o kadar iyiydi ki, soruyu uyacak şekilde düzenledim ve orijinal soruyu burada tekrar sordum.

— tshepang

Anlıyorum, ama sorunuz diğeriyle çelişiyor gibi görünüyor; Burada "Bu sınırlamayı açıklayan ve neden Linux çekirdeğinde çözülemeyen var mı?" diyorsunuz, orada bu sorunu olmayan bir çekirdek var mı? ", ama xeno'nun cevabı" Bence çoğunlukla çözüldü."

— Michael Mrozek

@mic Pek değil. Çekirdek hala iowait yapıyor , yani hala bekliyor. Xeno'nun cevabını, daha fazla sistem duyarlılığı iyileştirildiğinden görüyorum . Ve soruda da belirttiğim gibi katılıyorum.

— tshepang

Yanıtlar:

İşletim sistemleri sanal belleği kullanır, böylece kullanılabilir fiziksel RAM'den daha fazla bellek kullanılabilir. Çekirdek fiziksel bellek sayfası için daha iyi bir kullanım olduğuna karar verdiğinde, içeriği diskte depolamak için "sayfalandırılabilir". Disk belleği dışındayken böyle bir sanal bellek sayfasına erişildiğinde, bir sayfa hatası oluşturur ve diskten RAM'e geri taşınır.

Disk gecikmesi milisaniye cinsinden, RAM gecikmesi nanosaniye cinsinden ölçüldüğü için sayfa hataları performans için bir felakettir. (1 milisaniye = bir milyon nanosaniye!)

Bellek yalnızca kullanıcı işlemleri tarafından değil, aynı zamanda dosya sistemi önbelleğe alma gibi şeyler için çekirdek tarafından da kullanılır. Dosya sistemi etkinliği sırasında, çekirdek son kullanılan verileri önbelleğe alır. Varsayım, aynı verilerin kısa süre içinde tekrar kullanılması ihtimalinin yüksek olması, bu nedenle önbelleğe almanın G / Ç performansını iyileştirmesi gerektiğidir.

Dosya sistemi önbelleği için kullanılan fiziksel bellek işlemler için kullanılamaz, bu nedenle dosya sistemi etkinliği sırasında daha fazla işlem belleği silinir ve sayfa hataları artar. Ayrıca, bellek sayfalarını diske ve diske taşımak için daha az disk G / Ç bant genişliği kullanılabilir. Sonuç olarak süreçler durabilir.

— Wim Coenen
kaynak

Bunun kir kadar eski olduğunu biliyorum, ancak nasıl geldiğine bağlı olarak, yüksek miktarda G / Ç çok fazla kesintiye neden olabilir ve sonuçta ortaya çıkan bağlam CPU zamanını boşa harcıyor.

— Bratchley

Anladığım kadarıyla IOwait, IO'nun kullanılabilir olmasını bekleyen bir işlemin değil, işlemcinin beklediği anlamına geliyor. İşlemciler sabit sürücülerden çok daha fazla hız kazandı, yani daha fazla kod daha hızlı bitecek ve daha sonra diskin okunması gerekecek. Sürücünün yeterince hızlı yapabileceğinden çok daha fazlasının okunması gerektiğinde, işlemcinin beklemesiyle sonuçlanırsınız. Diski kimin okuyup yazacağına karar verme şekli, çoğu durumda şimdi CFQ olan blok zamanlayıcı tarafından belirlenir. CFQ kullanıyorsanız ve sistem yanıt hızını artırmak için toplam IO süresinden daha azını kullanmak için bir işleme ihtiyacınız varsa kullanabilirsiniz ionice -c3 <processid>. Bu, sisteme yalnızca bu işleme ES'yi yalnızca başka hiçbir şeye ihtiyaç duymadığında vermesini söyler.

Bu hala ilginç ve iowait problemini daha iyi açıklıyor.

— xenoterracide
kaynak