Тестирование Linux'ов. Осень 2003. Тур 2. Про prelink

2003 г

Разговоры про prelink и его фантастическую способность к ускорению запуска Linux-приложений ведутся давно. Достаточно вспомнить ставший знаменитым тест Хосе Суареса. В итоге и у меня появилось желание посмотреть, что же это такое. А в рамках начавшегося мегатестирования - и померять, как этот самый prelink влияет на реальную работу.

Издевательству подвергался дистрибутив Archlinux (последняя стабильная версия, 0.5), который сам по себе заслуживает внимания (и оное надеюсь уделить ему в ближайшие дни). Насколько мне известно, собирается дистрибутив с флагами -O2 -march=i686, то есть без особых изысков. Тем не менее, субъективно он производит впечатление весьма быстрого.

Основные компоненты, которые я планировал подвергнуть прелинкингу - Qt и KDE, были установлены из прекомпилированных пакетов официальной части. Имелся среди пакетов (правда, уже в части неофициальной) и prelink, однако достаточно старой версии, и потому я решил собрать его вручную. На этом пути меня подстерегали некоторые трудности.

Для начала скачиваю prelink с места его постоянного проживания - ftp://people.redhat.com/jakub/prelink, - и распаковываю архив. Затем внимательно читаю ./configure --help и запускаю собственно конфигурирование:

$ ./configure --prefix=/usr

в ответ на что от меня требуют библиотеку libelf. Она также имеется среди пакетов Arch, однако чистоты эксперимента для собираю и ее. Скачиваю его последнюю (0.8.2) версию с http://www.stud.uni-hannover.de/~michael/software/, разворачиваю тарбалл и собираю обычным образом -

$ ./configure --prefix=/usr ;
$ make ;
$ make install

После чего повторяю процедуру конфигурирования prelink, по благополучном ее завершении запускаю make - и получаю сообщение об ошибке. Причем, что самое обидное и парадоксальное - на стадии сборки компонентов для архитектуры PPC, нужной мне, как зайцу стоп-сигнал. Я довольно долго ломал голову, как побороть эту напасть - снятием ли флагов оптимизации, или искоренением из make-файлов упоминаний о не-PC'шных архитектурах. И в конце концов в глубине кроны дерева портежей Gentoo обнаружил специально предназначенный к тому патч. Он залегает в отростке portage/sys-devel/prelink/files и носит имя prelink-20030505-glibc231.patch (к сожалению, более простого способа его получения в не-Gentoo-дистрибутивах я не обнаружил - разве что самому написать:-)). Несовпадение номеров версий патча и собственно prelink смущать тут не должно - все описанное проверено на собственной шкуре и работает.

Итак, налагаю патч:

$ patch -Np1 -i /path/prelink-20030505-glibc231.patch

после чего сборка prelink проходит безболезненно.

В результате я получаю исполняемый файл /usr/sbin/prelink и соответствующую ему man-страницу. По изучении которой нужно выполнить некоторые конфигурационные мероприятия. А именно - скопировать из каталога doc в дереве исходников prelink файл prelink.conf:

$ cp ~/prelink-src/doc/prelink.conf /etc

В него вносятся все пути к исполняемым файлам и библиотекам, которые планируется подвергнуть процедуре предварительного связывания. В итоге у меня он приобрел следующий вид:

-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/local/bin
-l /usr/X11R6/bin
-l /opt/qt/bin
-l /opt/kde/bin
-l /usr/libexec
-l /lib
-l /usr/lib
-l /usr/local/lib
-l /usr/X11R6/lib
-l /usr/X11R6/LessTif
-l /opt/qt/lib
-l /opt/kde/lib

Теперь можно, наконец, запустить процесс предварительного связывания. Делается это так:

$ prelink -avfmR

Смысл опций команды следующий: -a предписывает применить прелинкинг ко всем исполняемым файлам; -v - выводит подробную информацию о ходе процесса; -f - директива применять прелинкинг повторно, даже если эта процедура уже была выполнена; -m и -R - опции, страхующие от ошибок нехватки памяти и переполнения буфера (подробности, как обычно, - на man prelink).

Особо подчеркну необходимость опции -v. Я бы даже советовал отправить вывод команды (вернее, ее сообщений об ошибках) в файл:

$ prelink -avfmR 2> prelink.log

Без этого трудно узнать, какие программы подверглись прелинкингу, а какие - нет. Ибо те, что были собраны с опцией non-PIC (или, напротив, без опции --with=pic), предварительно связанными быть не могут. У меня в этот черный список попало некоторое количество KDE-приложений, что, возможно, и отразилось на результатах тестирования, приводимых ниже.

Выход из этого положения - простой, но занудный: пересобрать все, что попало в prelink.log. И тут уж, разумеется, впредь не забывать, что любая программа, в выводе ./configure --help которой отмечается доступность опции --with-pic, должна конфигурироваться именно с ее участием. Для гарантии чего флаг -fPIC можно добавить в список значений переменной CFLAGS. А после этого - повторить процедуру прелинкинга, для чего, собственно, и требуется упоминаемая выше опция -f - без нее программы повторно прелинкованы не будут.

Однако прежде я решил провести серию измерений на умолчальных сборках. Они выполнялись на следующем железе:

• Pentium4/2,53 (шина 533 Mhz, без Hyper Treading'а);
• "Мама" Albatron PX845PE ProII;
• память - 2x512MB, DDR PC333;
• видео - от того же Albatron'а, GeForce 4 440MX;
• HDD - Seagate Barracuda IV, 3 шт. - 40 Гбайт на 1 мастере, 80 Гбайт на 1 слейве, 80 Гбайт на 1 мастере;
• CD-R/RW Teac - скоростей не помню, смотреть лень, да и рояля не играет;
• всякое прочее типа клавы, мыши и прочего, к делу не относящегося.

Раскладка дисковых разделов:

• корневой (500 Мбайт) - на 1-м мастере;
• /boot (50 Мбайт) на нем же;
• /var и /usr (1 и 10 Гбайт, соответственно) там же, оба logical (все прочие - primary);
• два swap-раздела по 1 Гбайт - на 1-м слейве и втором мастере;
• /home - 160 Гбайт без двух на soft-RAID из 1-го слейва и 2-го мастера.

Система, как уже было сказано, - Archlinux 0.5, с ядром, поднятым до 2.4.22, gcc 3.0, glibc 2.3.2, binutils 2.14 с www.gnu.org, XFree86 4.3.0, KDE 3.1.4, установленные из пакетов. Графический режим - 1280x1024, 16 bit, стандартный X-сервер, без драйверов nvidia. Больше, пожалуй, добавить нечего.

Измерялась скорость запуска самого KDE и следующих KDE-приложений: konqueror'а как браузера и его же как файлового менеджера (с моими профилями), текстового редактора kate, почтовика kmail и KWord из комплекта KOffice.

Методика: сначала, после перезагрузки системы, запускалось KDE с измерением времени. Затем в сеансе KDE замерялось время запуска перечисленных приложений в указанном порядке. После этого - выход из сеанса и перезагрузка, после чего процедура повторялась второй раз. Результаты приведены в таблице.

Таблица

Тест	W/o prelink			With prelink			With/Without
Программа	1st	2nd	Avg	1st	2nd	Avg	Avg
KDE	17,94	18,16	18,05	19,13	19,19	19,16	1,06
Konqueror-Web	2,16	1,78	1,97	1,25	1,57	1,41	0,72
Konqueror-FM	2,12	1,78	1,95	1,87	1,84	1,86	0,95
Kate	1,91	1,85	1,88	1,69	1,62	1,66	0,88
Kmail	2,03	2,06	2,05	1,69	1,91	1,80	0,88
KWord	1,91	1,72	1,82	1,47	1,38	1,42	0,79

Можно видеть, что хотя прелинкованное KDE запускается чуть медленнее, чем до prelink, каждое отдельно взятое KDE-приложение стартует несколько (на 5-28%) быстрее - вывод о том, стоит ли игра свеч, предлагается сделать самостоятельно. Однако можно точно констатировать, что представленные измерения далеко не дотягивают до результатов Хосе - возможно, именно вследствие того, что не все компоненты Qt и KDE подверглись прелинкингу.