[Gelistirici] Müdür - Network

[S.Çağlar Onur]

Selamlar,

2009/12/27 Ozan Çağlayan <ozan at pardus.org.tr>:
> Gürer Özen wrote:
>> Firefox, OpenOffice.org gibi uygulamalar için çözüm preload. Özel bir ayar
>> gerektirmemesi lazım, dinamik olarak öğreniyor. Belki default olarak bu
>> uygulamaları yüklemesini sağlayacak bir state dosyasıyla dağıtılabilir.
>>
>> KDM biraz daha zor. Orada readahead'i denedim ben şimdi. X'in açılması ile KDM
>> login ekranı arasındaki süre 5 sn den 3 snye indi. Login ile desktop
>> arasındaki süre ise 32 sn den 25 sn ye indi. Ancak o sürede neredeyse hiç bir
>> yükleme yapmadı, aslında 5-6 sn sonunda tüm progress ikonları çıkmıştı, ancak
>> herhangi bi disk i/o yapılmayan uzun bir bekleme yaptı orada, gereksiz sleep
>> falan mı var acaba?
>>
>> Git'ten readahead kodunu çekip derledim. readahead ve readahead-collector
>> dosyalarını /sbin'e attım, readahead.conf'u /etc ye attım, /var/lib/readahead
>> dizinini oluşturdum. Sistemi init=/sbin/readahead-collector ile bu ettim ama
>> bu sırada audit servisini off konumda tuttum. Oluşan dosyadan .swap'ı çıkardım
>> (bunu readahead.conf'a eklemek lazım). /sbin/mudur.py içine setupUdev() den
>> önce şu satırı ekledim:
>>
>> run_async(["/sbin/readahead", "/var/lib/readahead/custom.early"],
>> fstdout="/dev/null")
>>
>> Bunu tam olarak entegre etmek istersek, müdür içinden mesela kurulumdan ve
>> büyük updatelerden sonra collector'u otomatik çalıştırmak ve normal bootlarda
>> da yukardaki satırı işletmek yeterli olacaktır.
>>
>> sreadahead özel bir kernel yaması falan istiyor, çok da iyi yöntem gibi
>> gelmedi bana. Sizler de denerseniz sonuçları bir karşılaştıralım.
>>
>
> Abi şöyle bi olay var, ortada 3 adet readahead var (readahead,
> sreadahead, ureadahead).
> sreadahead'i intelciler yazıyordu en son, rotational'dan ziyade SSD için
> azıcık optimize, kernel'de tracer yaması isteyen bir şey.
>
> readahead daha eski bir proje.
>
> ureadahead'i debiancilar yeni çıkarttı.

Depo loglarinda bir yerlerde mudur icin readahead destegi ve gerekli
betikler v.s. de olmali eger baska referans gerekirse, olmadi
arsivlerden de bulabilirsin sanirim. Zamaninda cok ciddi bir avantaj
getirmedigi icin bir sure deneyip sonra vazgecmistik (preload'u da
uzun sure kullandik ve attik).

> preload cephesindeyse bir fedora preload var, bir de suse preload var.
> suse preload'un opsiyonel kernel modülü var. Varoglu var.

Preload'a hic ihtiyaciniz olmamali. gnu-hash-style zaten bu sorunu
cozmek icin var, fedoranin halen kullaniyor olmasi cekirdeklerinde de
tux yamasini tasima israrlarindan farkli bir sey olmamali.

> Ben bunlara daldığım zaman süper demotive oluyorum 14bin ayrı fork
> olduğu için bir de denediğim sistemlerde çok fazla etkisini görmeyi pek
> başaramıyorum.
>
> GDM'in preloading desteği var, KDM'nin yok. Müdür'de X11 soketini
> bekleyen bir waitBus var, en son denemelerimde o süre 5 saniyeden bazen
> 1-2 bazen 2-3 aralığına inmişti preload ile.
>
> Vaktim olduğunda tekrar mutlaka bakacağım hep aklımda, preload desteği
> eklemiştim müdür'e zaten.

Bu arada eger "bir gun" daha buyuk bir hamle __yapilacaksa__ bu
hamlenin mudur'u optimize etmek veya yeniden yazmak degil de __bence__
uzerinden yeterince zaman gectiginden ve n tane dagitim da
kullandiginda olan upstart v.s. gibi bir sisteme gecmek olmasini
yeglerim. Mudur baska turlu bir init sisteminin yazilabilecegini
etrafa yeterince kanitladi ve event-driven her benzerinin de cikis
noktasi oldu coktan.

Comar ve sistem betiklerinin yanina nasil oturur v.s. uzerine hic
dusunmedim ama servislerin baslangic betiklerini yeniden yazmamak ve
bunlarin birbirine bagimliliklari gibi bir seri sorunu yaygin bir
yontemle cozduklerinden (ve fedora 12'de goruldugu uzere
performanslari da hic fena olmadigindan) bir seri is yukunu
hafifletebilirler.