Z biegiem czasu zasoby naszego komputera się kurczą, a aplikacje uruchamiają się coraz dłużej. Włączenie przeglądarki internetowej trwa tak długo, że możemy spokojnie iść zaparzyć kawę. Codziennie korzystamy praktycznie z tych samych aplikacji. Rano uruchamiamy klienta poczty, aby odebrać świeżą porcję maili, a przez cały dzień surfujemy w sieci. Skoro te czynności wykonujemy regularnie, to czy nie możemy zmusić systemu, aby był przygotowany do uruchomienia na przykład Firefoksa? Oczywiście, że możemy. Pomogą nam w tym aplikacje Preload oraz Prelink.
Na zachętę powiem, że część aplikacji udało mi się przyspieszyć o ponad 50%! Zmiany jakie wprowadziły obie aplikacje są zauważalne.
Preload
Preload został napisany przez Behdada Esfahboda. Działa w systemie jako demon i zbiera statystyki na temat wykorzystywania aplikacji. Korzysta on z procesu Markowa. Zapisuje jakie pliki oraz aplikacje są najczęściej wykorzystywane a w wolnym czasie ładuje je do pamięci komputera, dzięki czemu ich ładowanie jest znacznie szybsze. Ponieważ część danych jest już w pamięci, aplikacja uruchamia się zdecydowanie szybciej. Mniej danych jest ładowana z dysku. Preload jest bardzo często wykorzystywany wraz z aplikacją Prelink.
Preload dostępny jest do pobrania ze strony preload.sourceforge.net. Dostępny jest również w postaci pakietów binarnych w popularnych dystrybucjach Linuksa. W Ubuntu wystarczy wydać polecenie:
sudo apt-get install preload
Uruchomienie aplikacji polega na wydaniu polecenia:
/etc/init.d/preload start
Konfiguracja demona znajduje się w pliku /etc/preload.conf i zawiera domyślne ustawienia, które powinny być dla nas odpowiednie. Niestety domyślnie ustawienia preloada nie uwzględniają nam aplikacji, które są zainstalowane w katalogu /opt dlatego powinno się je dopisać w pliku konfiguracyjnym do pozycji mapprefix oraz exeprefix. W opcji cycle ustalamy jak często preload ma odpytywać system, aby uaktualnić swój model aplikacji oraz bibliotek do zcachowania.
Demon na szczęście nie zabiera dużo pamięci. Na komputerze wyposażonym w 1,5 GB RAMu, zajął tylko 96620 kb. Działanie programu można oglądać przeglądając logi:
root@hell:/home/paszczak000# tail -f /var/log/preload.log [Sun Jul 6 16:02:45 2008] 86250kb available for preloading, using 360kb of it [Sun Jul 6 16:02:45 2008] readaheading 9 files [Sun Jul 6 16:03:05 2008] 86250kb available for preloading, using 360kb of it [Sun Jul 6 16:03:05 2008] readaheading 9 files [Sun Jul 6 16:03:26 2008] 86250kb available for preloading, using 360kb of it [Sun Jul 6 16:03:26 2008] readaheading 9 files [Sun Jul 6 16:03:46 2008] 86250kb available for preloading, using 360kb of it [Sun Jul 6 16:03:46 2008] readaheading 9 files [Sun Jul 6 16:04:07 2008] 86250kb available for preloading, using 552kb of it [Sun Jul 6 16:04:07 2008] readaheading 11 files
Natomiast w pliku /var/lib/preload/preload.state możemy obejrzeć jakie pliki zostały zcachowane przez preload.
PRELOAD 0.4 1120 MAP 131 10 0 950272 -1 file:///usr/lib/libstdc++.so.6.0.9 MAP 491 10 0 4096 -1 file:///usr/share/kadu/modules/translations/window_notify_pl.qm MAP 650 10 0 401408 -1 file:///usr/lib/libeel-2.so.2.22.2 MAP 803 10 0 73728 -1 file:///usr/share/fonts/type1/gsfonts/n019004l.pfb MAP 197 10 4096 4096 -1 file:///usr/lib/libscim-x11utils-1.0.so.8.2.3
Preload w znaczy sposób potrafi przyspieszyć start, niektórych aplikacji. Niestety nim zobaczymy jakieś efekty musi minąć troszkę czasu, aby demon nauczył się jakie programy oraz biblioteki powinien cachować w pamięci.
Prelink
Prelink został napisany przez Jakuba Jelineka. Aplikacje z jakich korzystamy w systemie korzystają ze współdzielonych bibliotek, które są ładowane do pamięci operacyjnej w trakcie działania programu. Za każdym razem taki program jest łączony z potrzebną mu biblioteką. Niestety w przypadku dużych aplikacji ten proces trwa długo.
Prelink potrafi tak zmodyfikować program wykonywalny, aby jego uruchamianie było zdecydowanie szybsze. W zwykłym systemie biblioteki rzadko są modyfikowane, zatem programy, które uruchamiamy za każdym razem w taki sam sposób linkują biblioteki. Prelink wykorzystuje ten fakt i dokonuje dynamicznego łączenia tylko raz, po czym zapisuje wyniki na stałe w pliku wykonywalnym programu. Taka operacja może skrócić czas uruchomienia aplikacji nawet o 50%! Niestety jeżeli biblioteki ulegną modyfikacją np. podczas aktualizacji systemu, należy ponownie wykonać prelinkowanie programu. Modyfikacje dokonane poleceniem prelink są w pełni odwracalne. Polecenie to posiada funkcję undo.
Konfiguracja aplikacji znajduje się w pliku /etc/prelink.conf. Zawiera ona spis ścieżek, programów jakie mają zostać poddane prelinkowaniu. Przykładowy plik konfiguracyjny wygląda następująco:
-b *.la -b *.png -b *.py -b *.pl -b *.pm -b *.sh -b *.xml -b *.xslt -b *.a -b *.js -b /lib/modules -b /usr/lib/locale -l /usr/local/sbin -l /sbin -l /usr/sbin -l /usr/local/bin -l /bin -l /usr/bin -l /usr/X11R6/bin -l /usr/games -l /usr/local/lib -l /lib
Przed uruchomieniem aplikacji należy sprawdzić, czy posiadamy na dysku odpowiednią ilość wolnego miejsca. W innym wypadku prelinkowanie całego może się skończyć obcięciem i tym samym zniszczeniem niektórych plików wykonywalnych, czego efektem będzie pad systemu. Proces prelinkowania rozpoczynamy wydaniem polecenia:
root@hell:/home/paszczak000# prelink -amR
Parametr -a prelinkuje wszystkie programy jakie zostały zapisane w pliku konfiguracyjnym, -m - oszczędza pamięć wirtualną a -R przyporządkowuje przypadkowe adresy, co skutkuje wzrostem poziomu bezpieczeństwa poprzez zwiększenie odporności na ataki z wykorzystaniem przepełnienia bufora (buffer overflow).
Przed usunięciem prelinka z systemu należy wykonać polecenie:
prelink -au
które przywróci nam w systemie oryginalne wersie aplikacji.
Wnioski
Niech liczby i wykresy mówią same za siebie. Testy przeprowadziłem na komputerze wyposażonym w dwa procesory Intel(R) Pentium(R) 4 CPU 3.40GHz, 1,5 GB pamięci RAM, zalogowanych czterech użytkowników w środowisku KDE oraz dwóch w GNOME. System to Ubuntu 8.04.1.

A poniżej tabela z czasami uruchamiania konkretnych aplikacji podana w sekundach.
| Aplikacja | Suchy start | Preload | Preload/Prelink |
| OpenOffice Writer | 15,3 | 6,3 | 5,3 |
| Thunderbird | 12,1 | 7,8 | 7,6 |
| Firefox | 7,1 | 4,6 | 3,2 |
| Gedit | 5,3 | 4,7 | 4,2 |
| Konqueror | 4,9 | 3,3 | 2,3 |
| Gnome Terminal | 4,2 | 4,1 | 4,0 |
| Gajim | 3,3 | 3,1 | 2,5 |
| Kwrite | 3,2 | 3,1 | 2,9 |
| Konsole | 3,1 | 3,0 | 2,6 |
| Kadu | 2,2 | 2,2 | 1,8 |
Jak widać - warto korzystać z preloadu oraz prelinka.
Linki
- Drastically Speed up your Linux System with Preload
- Preload (sourceforge.net)
- HOWTO: Mount / in RAM and load apps instantly
- Preload (wikipedia.org)
- Wprowadzenie do Prelink w Gentoo















Bawiłem się nimi nie raz i zmiany nie były zauważalne. Mogę nawet powiedzieć nieco wulgarnie, że cała zabawa “^g dała”.
Popieram Livio 100 % również testowałem ten pakiet.
No to macie pecha :D
Ja jak tylko na starym kompie się będę bawił to wypróbuję to cudo :]
U mnie uruchomienie gedit trwa: 3,7 s, a gnome terminala: 3,2 s. No oczywiście bez jakiś pro ani tym bardziej preloadów, Kamil i kto ma tu pecha? Odpowiedz sobie sam :P
Jak były mierzone czasy startu poszczególnych aplikacji?
Przydalby sie jeszcze osobny wykres dla samego prelinkowania.
@Franek, tylko, że ja testowałem to na kompie gdzie pracowało jeszcze 6 osób :)
@lazy_bum, stoperem :]
To podawaj czasy (user time). Kogo interesuje, w celach porownawczych, ile w rzeczywistosci (real time) trwa uruchomienie danej aplikacji. Jak bedziesz mial 100 userow to i tak user time powinien byc podobny. Polecam man time
Znam man time i tak dalej. Ale użytkownika raczej interesuje jak szybko mu wyskoczy okienko na ekranie i może się nim pobawić ;-)
Ale jak będę w pracy to mogę zrobić testy :)
1,6 GHz + 2 GB RAMu z wylaczonym SWAP i bez preloadera openoffice writer laduje mi sie ~3-6 sek
U mnie działa. C2D 1.6GHz, 3GB RAM + preload + vm.swappiness=10
OpenOffcie:
1. Pierwsze odpalenie oowriter po starcie systemu: ~6sek.
2. Drugie odpalenie po zamknięciu oowriter: ~2sek
Gnome-terminal:
1. ~3-4sek
2. ~1sek
Gedit:
1. ~3-4sek
2. ~1-2sek
Dla tych, którym nie działa (i z <1GB RAM?): poeksperymentujcie dodatkowo z vm.swappiness - w Gutsym tego nie ruszałem (default 60), ale w Hardym zmieniłem na 10 (swap używany dużo rzadziej).
Dla tych z <512MB RAM preload raczej bym odradzał, ale zmniejszenie vm.swappiness jak najbardziej.
u mnie również znacznie przyspieszyło [c2d 1.6GHz / 2GB]
Co do SWAPu to ja korzystam z niego tylko wtedy jak obrabiam zdjęcia. W innym wypadku RAM w zupełności wystarcza.
“Jelineka”??? no bez przesady.
to pisałem ja, Jarząbek, 8 lipieca.
Dodaj komentarz