[Gelistirici] mudur ile ilgili mevcut sorunlar ve açılış sürecinin iyileştirilmesi

[Ozan Çağlayan]

Selam,

mudur ile ilgili bir optimizasyon ve iyileştirme sürecine girmemiz 
gerektiğini düşünüyorum. Bu bağlamda gözlemlerimi aktarıyor ve çılgın 
fikirlerinizi, farklı farklı insanlardan gelecek über çözümleri buraya 
toplayıp biraz beyin fırtınası yapalım diyorum.

Öncelikle mevcut hatalarımız:
    - Uzak dosya sistemi bağlarken 2008 müdürünün CTRL+C'yi handle 
edememesi,
       http://bugs.pardus.org.tr/show_bug.cgi?id=7524

    - Udev başlatıldığı sırada dosya sistemi salt-okunur bağlandığından, 
udev'in rule-generatorları ile "o evrede" ürettiği hiçbir kuralın 
/etc/udev/rules.d altına yazılamıyor olması. Bunun bir sonucu bazı 
makinelerde persistent bir şekilde ağ arabirimlerinin isimlendirilememesi,
       http://bugs.pardus.org.tr/show_bug.cgi?id=8458

Bunlar dışında sık karşılaşılan durum(lar):
    - Bir sebepten dolayı müdür bir evrede sorunla karşılaştığında 
müdür'ün sonlanarak "Bakım için root parolanızı girin veya CTRL+D ile 
devam edin" diyerek kullanıcıyı çaresiz bırakması. Burada müdür belli 
başlı bir kaç check yaparak sorunu tespit edip düzeltmeye çalışabilir. 
(comar-rdb betiğini çalıştırır, fsck yapar,..) Ya da bu opsiyon grub'a 
eklenebilir.

----

Burada ise mudur=debug ile yaptığım bazı süre analizlerinden bahsedeyim. 
Testleri Asus eeepc 901 ile yaptım:

- /dev içeriği dolduruluyor evresinde 5-6 saniye harcanıyor,

- Yeni çekirdek ile ilk açılışta depmod çalışıyor ve yine 5-6 saniye 
çalışıyor. Ancak bu bir defaya mahsus bir şey. depmod -a yerine depmod 
--quick kullanmak bu süreyi de azaltabilir mi? quick neye göre yeni 
modül olup olmadığına bakıyor?

- Bundan sonra kaydadeğer bir kaybımız yok. Servislerin başlatılması 
gerçekten iyi sayılabilecek sürelerde gerçekleşiyor. Ancak bir istisna 
var, o da irqbalance. Arkadaşın işini bitirmesi açılış esnasında 6-7 
saniye alıyor, sistem açıldıktan sonra konsoldan time ile 
çalıştırdığımda ise 11 saniye civarında. Kendisi oneshot bir servis yani 
başlayıp, işini halledip bitiyor.

Burada paralel servis başlatmanın önemli bir getirisi olduğunu görüyoruz 
aslında. irqbalance ve buna benzer kendi başına, bağımlılığı ve kendine 
bağımlı servis olmayan servisler asenkron olarak başlatılabilirse çok 
güzel bir performans artışı yaratılabilir. irqbalance çalıştırılıp sonra 
onun 6 saniye dönmesi beklenmeden kdm geliyor olsa bunun kimseye bir 
zararı dokunmaz gibime geliyor.

Kapanışa gelince, kapanışta tmpfs'in ayrılması kaydadeğer bir süre 
alıyor. Tam bakamadım ama anladığım kadarıyla ilk defada unmount 
edemediği için onu kullanan processleri öldürüp, 2 saniye uyuyup tekrar 
unmount etmeye çalışıyor. Bu diğer bölümler için de geçerli. Bu sleep'e 
gerçekten ihtiyacımız var mı?

Şimdilik bu kadar, iyi geceler :)

-- 

Ozan Çağlayan
<ozan_at_pardus.org.tr>