müdür...
25 July 06, Tuesday @ 19:19 Pardus'un yeni açılış sistemi "müdür" konusunda pek yazmadığımı farkettim. Paketçilere yönelik bir belge ile fikirleri ve bulguları anlatan İngilizce paper tadında bişi var, eh kod da açık, ama "neymiş la bu, baksam mı" diyenlere de ilk elden anlatmak lazım. Önce tabiki tarihçe:Herşey Çağlar'ın initng'yi denemesi, açılış süresini hızlandırdığını gördükten sonra geliştirme sürecine katılmasıyla başladı. Bunlar söz konusu projeyi geliştiren dondurmacı amcanın kodunu epey bir temizledilersede, bir gün Çağlar'ın bir sorusu üzerine koda baktığımda, neden sistem programları için bile C'nin iyi bir seçim olmayabileceğini gösteren bir ışık yandı kafamda.
1.0 de son anda çok sorun çıkartan açılış yerelleştirme desteği, ve /etc/init.d altındaki betiklerin çok basit işler için kullandıkları içinden çıkılmaz program yapılarını da görünce tasarımın ana çatısı yerine oturdu.
"Yüksek düşünceler için yüksek bir dil gerekir."
-- Aristophanes
Kabuğun (özellikle bash'in) "bir işi yap, ama iyi yap" diyen unix felsefesinin dışına çıktığını düşünüyorum. Bir man sayfasına bakın, bir sürü programlama elemanı göreceksiniz, ve hepsi de acayip senktakslara sahip. Programları borular aracılığıyla bağlamak için çok fazla şey var, ama temiz döngüler, liste ve sözlük gibi veritipleri, ya da mantıklı davranışları olan karşılaştırma operatörleri gibi şeyler olmadığı için bir program yazmak için de çok elverişsiz.
Genellikle kabuk programları awk, sed, cut, vs gibi gene kendi yetersizliklerini taşıyan başka araçlara gerek duyuyor ve iş çığrından çıkıyor.
Bunları gözlemledikten sonrası sıfırdan Python ile bir prototip yazma, ekibin bunu gözden geçirmesi, eksikleri tamamlama, test süreci ve pardus'a entegre etme, ve olayların gelişmesi...
Neler kazandık?
- Python sayesinde kod boyutu aynı özellikle tamamen sağladığı halde yirmide birine indi. Bakım ve geliştirme çok daha kolay hale geldi. Yerelleştirme desteği gettext ile basitçe halledildi.
- Hız kazancı
Herkesi etkileyen bu oldu sanırım, ben o kadar önemli bulmuyordum :)
Buradaki bulgularımız enteresan. Mesela aslolan şey betikleri paralel çalıştırmak değil, okuma/yazma IO işlemlerini en verimli olacak şekilde dizmek. Müdürün ana kısmı ihtiyacı olan modülleri bir seferde yükleyen ve başka araçlar, gereksiz geçici dosyalar vs kullanmayan tek bir program olduğu için burada disk IO'yu bölmemek açısından büyük avantaj sağladı.
Betikleri yeniden yazarken sağa sola saçılmış sleep'leri (ah bu hızlı ve kirli iş yapıp sonra öyle bırakan özgür yazılımcılar) kaldırıp mesela bir programın soket açması yada bir aygıtın /dev dosyasının oluşması bekleniyorsa direk bu durumun kontrol edilmesi baya bir hız ve sağlamlık sağladı :)
Bunların üzerine paralel betik çalıştırma fazla bir avantaj sağlamadı, zaten açılış ekranı için gereken servisi temel açılış işlemleri tamamlanır tamamlanmaz başlatıyoruz. Diğerleri daha sonra paralel yada seri çalışmış görünen bir etkisi olmuyor.
Eğer Pardus 1.1 alfa kurduysanız, 1.0 üzerindeki 20 saniye altındaki açılış süresinin her bilgisayarda yakalanamadığını, bazı makinalarda 30 saniye gibi çok büyük ^_^ sürelere çıktığını farketmişsinizdir. 1.1 final sürümü ile bu sorun düzelecektir. Kernel, udev gibi bazı temel bileşenler değiştiği için bazı ince ayarlar meme yapmış :)
Mesela kimi makinalarda grub.conf içindeki kernel satırındaki splash= parametresinden fadein'i çıkardığınızda süre 4-5 saniye kısalıyor, benim makinamda ise 0.5-1 saniye kadar bir etkisi oluyor.
Bir de çekirdeğe dahil ettiğimiz ama otomatik açmadığımız fcache özelliği var. Jen Axboe'nun bu yaması ayırdığınız bir partisyonu cache olarak kullanıyor ve buraya sıralı olarak kaydettiği okuma işlemlerini sunarak harddisklerin kafa hareketi sırasında (seektime) kaybettiği süreyi geri kazandırıyor. preload veya readahead'den daha iyi bir çözüm.
Denemek isterseniz (sonra bişileri bozdum diye bana gelmeyin, üretim sistemlerinde denemeyin, uyarmadı hiç demeyin):
/etc/fstab dosyanızda / partisyonu bağlayan satırda fcache_dev=3/1,fcache_prime=1 şeklinde iki opsiyon ekleyeceksiniz. Ordaki dev ls -l ile /dev deki hda2 hda3 (artık neyse) gibi aygıtlara bakınca gördüğünüz major ve minor aygıt numaraları, burayı kullanmadığınız bikaçyüz megabytelık bir partitiona ayarlayın (bunu nasıl yaparım diye soruyorsanız yapmayın, dert almayın).
Sonra bilgisayarı yeniden başlatın, giriş yapın, hatta sık kullandığınız 1-2 programı açın. Onlar da faydalansın :)
fstab'ı tekrar değiştirip fcache_prime'ı 0 yapın, sonra
mount -o remount /
komutunu vererek kullanıma alın. Sonra bilgisayarı yeniden başlatıp farka bakın.
Hızlı bir diskte müdür kısmında 1-2 saniye kadar olacaktır hızlanma tahminen, zaten diski iyi kullanıyor, kde ve cachelediğiniz programların açılış süreleri baya iyileşecektir. Cache performansı düşürse şu prime=1 işlemini tekrar yapın. İlerki sürümlerde bu yamanın stabilitesinin artmasıyla bu işlemi otomatik hale getireceğiz.
Aslında sistemi ve programları çok çok daha hızlı açabilmek ve kullanabilmek gerekir, peki bu niye yapılamıyor? Cevabı için buradaki why userspace sucks kısmını okuyun. Evet cevabı yine tembel xorg'cular, gnome'cular, hatta kde'ciler. Bazen amiga ve scene günlerini özlemiyor değilim.
Neyse... ben Firuzbey'imi aldım tatile kaçıyorum, zaten çok fazla yazmışım :)
