Параллельная сборка пакетов

У вас новый современный многоядерный процессор? Много дешевой по нынешнем меркам оперативки? Тогда мы идем к вам! :slight_smile:

Файл /etc/make.conf следующих версий Calculate Linux пополнятся ещё одной интересной опцией параллельной сборки пакетов:

EMERGE_DEFAULT_OPTS="--jobs=4"

где:

  • jobs - максимальное количество параллельно собираемых пакетов

Итак, что делает эта опция? Представьте себе процесс сборки пакета. Сперва идет загрузка файла, затем распаковка, после конфигурация и наконец компиляция. В этот момент идет максимальная нагрузка на процессор, которая может меняться в зависимости от языка и размера пакета. После компиляции пакет устанавливается, обновляются настройки портежей и удаляются распакованные исходники. Процесс установки пакетов в общих чертах можно представить синусоидой.

Кому как не гентушникам могла придти в голову мысль запустить параллельный процесс установки пакетов! Несложно представить что из этого получится. Примерно тот же эффект, что и при параллельной загрузке системы. Возможно как раз для этого был изменен подход в сборке пакетов, когда служебная информация в конце сборки пакетов выводилась на экран. Ведь во время параллельной сборки вы уже не увидите процесс компиляции (трехмерных терминалов еще не придумали :).

Выигрыш во времени зависит от количества одновременно собираемых пакетов. Мне удалось добиться уменьшения времени компиляции более чем в 2 раза. При этом я продолжал работать за компьютером, не чувствуя существенных замедлений (возможно из-за nice, который по умолчанию установлен в значение 20).
Безусловно выигрыш будет и на одноядерном процессоре.

К сожалению открыть второе дыхание distcc при помощи нескольких потоков нам не удалось. Прирост скорости не достаточно существенный, т.к. компьютеры не удаётся загрузить. Если кому-нибудь удалось добиться большего от distcc, поделитесь рецептом. Поддержку не сложно будет добавить в Calculate Linux 10.4.

Если выставить количество процессов более 4, emerge может сбить порядок сборки пакетов, из-за чего компиляция может прерваться ошибкой. Возможно в следующих версиях sys-apps/portage это поправят.

Результаты тестов

Для проведения теста было взято время компиляции CLD 10.4 i686 на основе CLS 10.4. Процессор AMD Phenom™ 9850 Quad-Core Processor, 4 Гб ОЗУ.

# Сборка без параметра --jobs:
8 ч. 14 м.
# Сборка с --jobs=2:
5 ч. 56 м. (на 28% быстрее)
# Сборка с --jobs=4:
5 ч 31 м. (на 33% быстрее)
# Сборка с jobs>=8 привела к ошибкам, связанным с нарушенным порядком компиляции пакетов.

В итоге параллельная сборка сократила время компиляции на треть. Параметр load-average, который часто указывают для ограничения загрузки системы можно не использовать, т.к. работать можно и при неограниченном количестве потоков (jobs).

load-average - максимальная нагрузка?
А в каких попугаях эта нагрузка выражена?

“–load-average=4”

4 чего? Процесса, метра, литра, niceness :-)?

Наберите top и посмотрите справа “load average: 0.05, 0.03, 0.00”. Это общая нагрузка на систему в целом.

:slight_smile:

Получается что “load average” в простейшем случае можно прикинуть по 1 на процессор (ядро)?

На нашем сервере одно время load-average превышал сотню, в то время как процессор был загружен на 50%. Виной тому была нехватка оперативной памяти, повлекшая активное использование свопа.
Сейчас я ставил сборки дистрибутива без каких либо ограничений. Такое ощущение, что большие тормоза добавляются увеличением приоритета компилятора, нежели параллельной сборкой. Именно поэтому в оверлее мы меняем значение PORTAGE_NICENESS на 19. На время сборки сказывается незначительно (в пределах 5%), а вот на удобство работы при этом - очень заметно.

Сейчас я допишу в статью результаты тестов.

Думаю стоит еще привести для справки к результатам тестирования и значение параметра MAKEOPTS, с которым происходила сборка системы.

Во всех тестах MAKEOPTS="j5". Собственно он по умолчанию устанавливается кол-во ядер + 1.

Возможно стоит попробовать увеличить и кол-во потоков для сборки? Думаю тогда работать на компе во время сборки системы будет не очень комфортно, но скорость тоже увеличится. :slight_smile:

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

думаю, что параллельная сборка мало связанных друг с другом пакетов вроде, к примеру, slim и firefox не будет производиться с ошибками. Кстати, не пробовал, но нельзя ли запускать сборку двух прог параллельно в двух вкладках терминала, не ковыряясь в make.conf? Emerge ругаться не будет?

думаю, что параллельная сборка мало связанных друг с другом пакетов вроде, к примеру, slim и firefox не будет производиться с ошибками.

Emerge сам отслеживает зависимости, отслеживая очередность сборки. Но по видимому не все ebuild-ы корректно указывают все зависимости. От этого иногда случаются ошибки. При сборке в 4 потока вероятность ошибки минимальна.

Кстати, не пробовал, но нельзя ли запускать сборку двух прог параллельно в двух вкладках терминала, не ковыряясь в make.conf? Emerge ругаться не будет?

Практически это одно и тоже.

могу ошибаться но параметр должен быть число процессоров Х 2+1
то есть если два яра то получится
EMERGE_DEFAULT_OPTS="–jobs=5"