[Gelistirici] r57490 - in playground/ozan/mudur: . bin

[Onur Küçük]

On Sun, 28 Dec 2008 02:33:47 +0200
Ozan Çağlayan <ozan at pardus.org.tr> wrote:

> Onur Küçük wrote:
> >
> >  Bende normal depo paketleriyle de X in gelmesi uzun sürüyor. Orada
> > fazlaca vakit kaybediyoruz, incelemek lazım niye uzun sürdüğünü.
> > Headstart kullanmamıza rağmen müdür bitmeden X görüntüsü geldiğini
> > görmedim hiç. Birşeyleri atlıyor olabiliriz.
> >   
> Ben biraz daha kurcaladım akşamüstü bu işleri, gözlemlerim şöyle:
> 
> anladığım kadarıyla servisleri başlatan dbus çağrısının *kendisi* 
> senkron ancak servis başlatma süreci asenkron, yani sysklogd'yi 
> başlatmak için dbus çağrısı yaptığımızda başlayana kadar beklemiyoruz 
> onu bekleyen comarjob.
> 
> genel bottlenecklere baktığımda,
> 
> 1. dbus başlatıldığında dbus soketini bekleyen waitBus çağrısı ~0.2s 
> sürüyor,
> 2. sysklogd başlatıldıktan sonra /dev/log'u bekleyen waitBus çağrısı 
> ~1.4s sürüyor,
> 3. headstart'tan sonra /tmp/.X11-unix/X0 soketini bekleyen waitBus 
> çağrısı ise en iyi ihtimalle bende ~4.8s sürüyor.

 of, çokmuş

 bunun sebebi de tahminen kdm açılana kadar yüklenen bilmem kaç tane so
dosyası, Qt si kdelib i derken. Bir de tabi as-needed kullanmadığımız
için alakalı alakasız bir sürü şey yükleniyor.

 Bunun uzun sürmesinin bir sebebi de X in KDM i değil, KDM in X i
başlatması. X KDM i açıyor olsaydı o socket bekleme işi bu kadar uzun
sürmezdi bence.

 xinit /usr/bin/xclock -- vt7 -br 

 çalıştıran bir betikle denemek lazım

 
> headstarttan sonra 5-6 kadar daha servis başlatılıyor ancak bu 
> servislerin başlatılma çağrıları kabaca atomik denebilecek sürelerde 
> sonlandığından müdür X soketini de beklemek zorunda kalıyor.
> headstart'ı başlatmayı yukarı çektim startNetwork'ten de önceye yine
> de çok bir şey farketmedi. Pratikte bizim X'i değil X'in bizi
> beklemesi lazım hızlı bir açılış için. X'i başlatabildiğimiz en erken
> noktada başlatmalıyız. Eğer X'in başlamasında bir engel yoksa,
> default runlevel'in ilk adımında bunu yaparak biraz vakit
> kazanabiliriz. Bunun için tek engel dbus, onu da makul bir yere çekip
> daha önce başlatabiliriz.

 X in startNetwork den sonra başlaması gerekiyor aslında.
mit-magic-cookie ip adresi / hostname gibi bilgilere göre
oluşturuluyor. X ağ ayarlanmadan başlarsa sıkıntı yaşayabiliriz. Gerçi
bunun için X i hostname kullanacak şekilde değiştiriyorduk (kdm
servisindeki XAUTHLOCALHOSTNAME bu işe yarıyor). Belki sadece hostname
ayarlamak bizi kurtarır.

 Ama bir taraftan da bu durum yeni X le değişmiş de olabilir. Fatih ne
dersin buna ?

> Aynı şey sysklogd için de geçerli. sysklogd'nin servis betiği waitBus 
> ile soketi beklediği halde, müdür servis betiklerinin sonlanmasını 
> beklemediği için o da ayrıca waitBus ile bekliyor. sysklogd'nin 
> soketinin yaratılması neden 1.5s gibi oldukça uzun bir sürede 
> gerçekleşiyor gerçekten anlamak zor. sysklogd çok temel bir hizmet 
> olduğundan onu da eğer bir engel yoksa boot runlevel'ında falan 
> başlatırsak o süreyi elimine edebiliriz.

 Bu denemeleri 2.6.25 le mi yapıyorsun yoksa 2.6.28... le mi ? Ekiga
ile bir socket sorunu yaşamıştık, yeni kernele geçince düzelmişti,
belki ilgili olabilir.

> Bir başka fikrim /var ve /tmp dizinlerinin bilgisayarın açılışında
> değil kapanışında temizlenmesi. Bunlar *volatile* dizinler olduğuna
> göre, sistemi kapattığında çoktan silinmiş olmalılar teorik bir bakış
> açısıyla ama biz bir sonraki açılışta temizliyoruz, ikisinin
> temizlenmesi 1 saniyeye yakın süre alıyor.

 Hmmm, olabilir bence



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