Prelink и Preload для ускорения запуска программ в Linux

[@peter23]

Ок, обновлю график.

[@INSTE]

Серьезно взялся за техническое писательство :)

[@IamFM]

ось Y должна быть всё же с нуля внизу начинатся, а не с 92. Иначе это просто обманка — данные отличаются на проценты, а стобцы — в разы.

[@braintorch]

Если уж на то пошло, то и тестировать нужно не одну программу, а несколько разноплановых приложений.

[@burdakovd]

Да, график лжет, такая подача материала для рекламы хороша=)

Но если иллюстрировать им не фразу «prelink офигенно уменьшает время работы», а «выигрыш от использования preload значительно меньше, чем от использования prelink» то этот график пойдёт.

Хотя и тест очень сферический, запуск php -v чуть более чем полностью состоит из загрузки php в память, в то время как нормальные программы выполняют после своего запуска хоть какую-то работу (в идеале время потраченное на запуск намного меньше времени работы)

[@make_luv]

preload в opensuse 11.3 с desktop-ядром устанавливается сам

[@crwin]

а почему нет отдельно preload на графике?

[@topbanana]

Глянул на график — в 2 раза ускорение, супер! Присмотрелся, всего-то ~ 9%… Не наглядно как-то.

[@ivlis]

Да, на графике наглое надувательство!

[@uve]

У меня eclipse будет быстрее 2 часов загружаться?

[@onk]

врядли
только jvm стартанет быстрее в лучшем случае

[@snakeye]

Из графика создаётся впечатление, что прирост скорости будет более чем в 2 раза. На самом деле, он меньше 10%

[@peter23]

Спасибо за корректировку, добавил ссылку на Ваш комментарий в пост.

[@vasilisc]

Есть мнение что Prelink больше не нужен
www.google.ru/#q=Prelink++DT_GNU_HASH&hl=ru

[@wRAR]

Because these lookups have to be done whether or not the shared libraries involved have been prelinked, prelinking and DT_GNU_HASH are complementary and systems can do both.
Конкретную ссылку можете дать?

[@BlackStream]

буквально, вчера наткнулся на статью habrahabr.ru/blogs/linux/20901/
там более подробно расписано о preload.
проверил — действительно стало немного шустрей работать.

[@ozware]

это для вебсерверов может быть полезным или только для desktop'ов?

точнее что можно prelink'овать и preload'ить на вебсервере?

[@DLag]

То что часто запускается.
/ КО

[@ozware]

ну тогда к вебсерверам это не применимо, т.к. там все запускается только один раз и постоянно висит в памяти

[@wRAR]

По preload я тоже пока не понял, есть ли в нём смысл при не перезагружающейся машине.

[@naryl]

При не перезагружающейся — есть. Вы ведь браузер, текстовые радакторы, терминалы, плееры и т.д. постоянно запускаете. На сервере — смысла нет, т.к. там всё запускается всего один раз и без всяких preload'ов из памяти не выгрузится.

[@peter23]

Однако, например, на сервере мониторинга — актуально. Тот же Nagios постоянно запускает пинги и прочие тесты.

[@MiyuHogosha]

Но скрипты и приложения могут запускаться для каждого запроса?

[@wRAR]

"-f — Вынуждает повторить предварительное связывание для файлов, которые уже подвергались ему. Это необходимо, т.к. программа prelink прекращает обработку существующих старых связанных файлов, зависимые библиотеки которых могли измениться."

-f --force
Force re-prelinking even for already prelinked objects whose dependencies are unchanged.

[@peter23]

Спасибо за исправление, добавил ссылку на Ваш комментарий в пост.

[@SpooNesT]

Взглянул на график и с первого взгляда показалось, что увеличивает скорость более, чем в 2 раза. Но потом посмотрел на шкалу в миллисекундах и понял, что не в 2, а скорее в 1,1 раза. Совсем несущественно.

[@SpooNesT]

во блин. не обновил страничку. Про график уже отписали. Не успел

[@afi]

ммм… что-то мне это напоминает… кажется, тоже на «pre» начинается

[@ekungurov]

Насколько использование prelink безопасно? Есть шансы, что всё поломается при следующем обновлении?

[@peter23]

Ничего не поломается, но после обновления prelink необходимо запустить снова.

[@lybin]

Спасибо, preload уже давно пользуюсь!

[@xappymah]

Тестирование в статье — чистая и наглая спекуляция.

Утверждаю это, как человек, посвятивший год жизни проблеме времени стартапа приложений (решение этой проблемы в некотором частном случае было темой моего диплома) и сломавший немало копий только на тестировании времени старта.

В комментариях выше уже говорилось про график, начинающийся не от нуля, а также малое количество протестированных приложений.
Но хотелось бы прояснить еще пару моментов.

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

Во-вторых, существуют термины «холодного» и «горячего» старта, то есть когда приложение незакешировано в памяти (до первого запуска) и закешировано, соответсвенно. Разница между холодным и горячем стартом приложения может измеряться секундами, а то и десятками секунд в зависимости от размеров приложения. Соответственно, если автор не гарантировал холодный старт, то тест, вообще говоря, абсолютно ничего не показывает.

Кроме того, немного искажена информация о Preload.
Он не просто бездумно кеширует часто-используемые файлы и библиотеки.
Он изучает последовательности загружаемых приложений и библиотек, чтобы в следующий раз, когда вы запускаете программу А, он догадался сразу загрузить библиотеки В и С, которые обычно грузятся сразу после А.

Поэтому, более показательным был бы пример с полной загрузкой системы (я, например, после использования Preload заметил явное визуальное ускорение в загрузке KDE).

[@seleko]

нюню… спецы по сусе (от новелла) на форумах пишут, что смысла особого в прелоаде нет. в чём на собственной практике убедился изучив чего он там кеширует и тд… к примеру в сусе, имо, не очень внятные настройки. они кагбе не «самозатачивающиеся» отнюдь. самому менять это можно конечно, я даже сделал…
но особо выйгрыша не получил и забил. не так часто ребутится комп.

[@MiyuHogosha]

Это как форточный prefetch. Чем картофельные, тем заметнее.

[@Pompeius_Magnus]

>>Можно назначить его на запуск по cron.

А как его добавить в расписание cron?
Он разве не только со скриптами работает?