Добрый день!

On Tue, 8 Sep 2020 03:12:33 +0300 Igor Vlasenko wrote:
> Оптимизируем hasher для работы с фиксированным репозиторием. II.
> ________________________________________________________________
> 
> При запуске hasher, если hasher/cache/ уже есть,
> то hasher проверяет, не изменился ли репозиторий, и если изменился,
> то обновляет hasher/cache/, иначе использует hasher/cache/.
> 
> По условиям задачи у нас фиксированный репозиторий. Это означает,
> что репозиторий не меняется без нашего ведома -- к примеру,
> локальное зеркало ежедневного релиза Сизифа.
> 
> Вторая оптимизация позволяет ускорять любые работы с hasher.
> 
> Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
> то сообщить об этом hasher'у опцией вроде --same-repository,
> чтобы он поверил человеку на слово, пропустил тяжелые проверки,
> и сразу использовал свой hasher/cache/.
> 
> Немного статистики.
> 
> Проведем с hasher'ом 1.4.4-alt1 простые бенчмарки на машине altair
> (2xXeon E5-2640v3). Репозиторий -- чистый Сизиф, рабочий каталог в tmpfs.
> (первые измерения отбрасываем, чтобы исключить I/O с жестким диском).
> Замеряем время hsh --initroot-only.
> 
>  mkdir $TMP/hasher
>  time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
> Запуск hasher без кеша. hasher создает свой workdir, делает initroot.
> 18,98s user 5,54s system 104% cpu 23,503 total
> 
>  time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
> Запуск hasher с cache/. hasher проверяет свой workdir, делает initroot.
>  6,36s user 2,73s system 103% cpu 8,805 total
> hasher-1.4.4, кстати, здесь быстрее (9сек), чем hasher-1.4.3 (10.5сек).
> Когда я начинал замеры, то пользовался установленным 1.4.3,
> но на всякий случай проверил, последняя ли это версия, обновился,
> и далее пользовался уже 1.4.4, в которой Дмитрий сумел уменьшить это
> время на 1.5 секунды.
> Не думайте об этих секундах свысока. Экономия в 1.5 секунды по
> сравнению с hasher-1.4.3 каждый раз при сборке или проверке установкой
> при пересборке питона для 1000+ исходных и 3500+ бинарных пакетов
> даст почти два часа ускорения сборки этой транзакции на x86_64.
> Мне же удалось сэкономить 8.3 секунды на initroot, выполняя его за 2.2с
> (0,033 total+2,131 total).
> Это близко к нижнему пределу. Если репозиторий, с которым проводилась
> сборка, не менялся, то по умолчанию (--without-stuff), hasher должен
> обновить chroot, а выполнить cpio --extract на hasher/.../chroot.cpio
> занимает
>  lz4 -d chroot.cpio | time cpio --extract [...]
> 0,16s user 0,95s system 74% cpu 1,486 total
> 
> Эта оптимизация естественно просится в сборочницу.
> Ведь в процессе сборки task'а репозиторий, с которым проводится
> сборка, не меняется. Даже если за это время Сизиф обновится,
> сборка все равно будет идти на старом репозитории.

Оптимизация хорошая и я думаю, что эта опция нам нужна в hasher,
т.к. будет полезна ряду пользователей.

Однако, хочу отметить, что репозиторий внутри таска тоже может
меняться: например, в таске есть пакеты A и B, A собирается перед B
и A находится в сборочных зависимостях B. Тогда после сборки A
репозиторий внутри таска изменится и B будет собираться уже в другом
окружении. Поэтому просто так на сборочнице включать эту опцию
нельзя.

Для корректного применения этой опции необходимо иметь возможность
построить граф сборочных зависимостей для каждого подзадания после
первого и определить, нет ли в нём пакетов, полученных
в предшествующих подзаданиях. Проблема в том, что, как уже
обсуждалось в данной рассылке, в общем случае это неразрешимая
задача, т.к. зависимости у нас есть не только явно на пакеты, но и
на другие объекты, например, библиотеки или модули pkg-config: это
плата, которую нам приходится платить за механизм автоматического
определения зависимостей.

> Секунды к секундам экономии дадут больше 8 часов ускорения
> пересборки питона или больше 3 часов ускорения пересборки perl.
> На одиночном таске это ускорение не так заметно. Пакеты наподобие
> hplip соберутся быстрее на минуту-полторы, но выстроившаяся
> очередь в сборочницу соберется существенно быстрее, ведь
> в очереди экономия суммируется.
> 
> К сожалению, эта оптимизации нет в нашем hasher'е. Она существует в
> виде моего приватного форка. В сборочнице для autoimports
> для ускорения работы с hasher initroot выполнялся только один раз,
> при старте. Полученный hasher_workdir в параллельных потоках
> клонировался (см. предыдущее письмо: subj часть. I.)
> и далее сборчница работала напрямую с hsh-rebuild и hsh-install.
> Свои изменения я оформил в 2 низкоуровневых патча, отключающих
> 2 тяжелые проверки с кешем hasher.
> Для пробы попытался провести более простой патч в апстрим hasher,
> https://bugzilla.altlinux.org/show_bug.cgi?id=36531
> Но не смог.
> Тогда я занимался переписыванием своей сборочницы для autoimports
> в полноценную дистрибутивную (локальную) сборочницу для всех желающих.
> Забросил это переписывание, когда понял, что, помимо сборочницы,
> придется, по сути, поддерживать собственный форк hasher,
> что явно было чересчур.
> 
> Впрочем, тогда я сам понимал и позиционировал в #36531 эти патчи как
> ускорение работы с клонированным hasher_workdir. Сейчас, разбираясь,
> я замерил задержки с оригинальным и клонированным hasher_workdir --
> они оказались одинаковыми, клонирование здесь не при чем,
> Переосмысливая, это просто общее ускорение работы hasher с
> фиксированным репозиторием. При этом вместо двух низкоуровневых
> опций возможно была бы уместнее одна высокоуровневая
> вроде --same-repository.
> 
> Кроме того, эти проверки в hasher, возможно, содержат какие-то
> логические ошибки. Вспомнилось, что полтора года назад при отладке
> внутри упомянутых проверок сравнивались списки пакетов, которые
> почему-то были различными при первом запуске без cache/ и втором
> запуске с cache/, при том, что репозиторий не менялся.
> Это приводило к выполнению ненужных тяжелых операций,
> которые я отключил вместе с проверками. Тогда я эти странности
> списал на неправильное клонирование, но бенчмарки показали,
> что это не так.
> 
> В общем, мне бы очень хотелось избавиться от своего форка hasher
> и получить ту же функциональность от пакета hasher в Sisyphus.
> 


Best regards,
Andrew Savchenko