[Gelistirici] Pardus 2007-2008 performans farkı

Onur Küçük onur at pardus.org.tr
13 Oca 2009 Sal 00:44:56 EET


On Mon, 12 Jan 2009 23:04:49 +0200
Ozan Çağlayan <ozan at pardus.org.tr> wrote:

> Uzun zamandır 2008'in yüksek disk IO'su altında kullanılamaz hale 
> geldiğini savunuyorum ancak pek arka cikan olmuyor bana belki de daha 
> düşük konfigürasyonlu sistemlerde ya da başka parametrelere bağli
> olarak hissedilebilirliği artan bir sorun olabilir.
> 
> "Heavy Disk I/O harms desktop responsiveness"
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094
> http://bugzilla.kernel.org/show_bug.cgi?id=7372 
> <http://bugzilla.kernel.org/show_bug.cgi?id=7372>
> http://bugzilla.kernel.org/show_bug.cgi?id=12309
> 
> Özetle 2.6.18 ile über/süper çalışan desktop 2.6.22+ ile çok fena 
> olduğunu, büyük dosya kopyalamalar esnasında, sistemin kullanılamaza 
> yakın hale geldiğinden bahsediliyor. Tam olarak tanımlanamasa da bu 
> geçişte hem fedora, hem ubuntu hem de biz IO scheduler'ını CFQ'ya 
> geçirdik ve adamlar buna dikkat çekmişler, çoğu kişi server

 2007 de de CFQ idik. Olay CFQ da değil bence, Ingo nun yaptığı
scheduler değişikliklerinde. Küstürdüler Con Kolivas'ı, adam canavar
gibi scheduler yazıyordu bırakıp gitti :(

> kernel'ini yükleyince rahatlamış(deadline IO scheduler kullanıyor)
> sonra aynı rahatlamayı /sys kullanarak on-the-fly IO scheduler
> değiştirerek de tecrübe etmişler ancak bu rahatlamanın çok da büyük
> miktarda olmadığını savunanlar da var.
> 
> Kimileri de sadece IO scheduler'dan değil, yeni gelen NO_HZ hedesiyle 
> ayrıca ext3 ile de alakalı olabilir diyorlar.
> 
> Son yorumlarda gelen bir test kodu ise IO dan ziyade process
> scheduler'a atıyor suçu vs.vs.
> 
> Şimdi gözlemlerinizi merak ediyorum, benden başka bunun acısını çeken 
> var mı? Özellikle 'svn up' yaparken bilgisayarın başından kalkıyorum,
> o kadar söyleyeyim.

 Ölüyorum diyim, bilgisayar başından kalkacağım zamanlar svn up a
bırakıyorum bilgisayarı, cache gidecek korkusundan da resetlemeye
çekiniyorum.

 Ben Ingo'nun scheduler değişiklikleri ya da libata geçişinden
kıllanıyorum. AHCI modülü (her ne kadar AHCI sistemi teknik olarak
üstün olsa da) NCQ desteklemesine rağmen sorun yaşadığımda ilk
kapattığım şey, ve bir sürü aygıtı düzgün çalıştıramadığını gördüm.
AHCI siz bir initramfs ayarlayıp onunla denemekte fayda var. Fark
ederse bir de NCQ yu elle kapatıp denemekte fayda var, düzgün
becerilemezse NCQ da bottleneck olabilir.

> Ayrıca nasıl debug edebiliriz, elimizdeki debug araçları nelerdir bu 
> tarz bir problemin kaynağını tespit edebilmek için?

 Şu an aklıma gelmiyor ama vardır bir sürü araç, olmadı ufak bir iki
programcık yazarız ya da başlangıç olarak dd ile filecopy
kıyaslayabiliriz.

> Upstream kendi yolunda ilerliyor ve böyle iddialı bir sorunla 
> ilgileneceklerini çok fazla sanmıyorum kaliteli bir deney ortamı ve 
> sonuç sunulmazsa.

 Malesef

-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens




Gelistirici mesaj listesiyle ilgili daha fazla bilgi