[devel] Оптимизируем hasher для работы с фиксированным репозиторием. I.

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Оптимизируем hasher для работы с фиксированным репозиторием. I.
_______________________________________________________________

Господа,
хочу поделиться своими оптимизациями для ускорения работы с hasher.
Эти оптимизации были заскриптованы в autoimports, полтора года как в работе.
Первая оптимизация специфическая, пригодится тем, кто одновременно
работает с несколькими процессами hasher' для одного и того же репозитория.
Вторая оптимизация пригодится практически всем майнтайнерам,
идейно очень проста, но техническая реализация сложнее.

К сожалению, со временем я начал забывать, как оно работает.
За неделю занятий промышленной археологией удалось заново разобраться.
Документирую, чтобы не пропало, в рассылке.

По условиям задачи у нас фиксированный репозиторий. Это означает,
что репозиторий не меняется без нашего ведома -- к примеру,
локальное зеркало ежедневного релиза Сизифа.

Первая оптимизация позволяет сэкономить дисковое пространство при
работе с несколькими процессами hasher для одного и того же репозитория.
Зачем это нужно? Самые первые версии autoimports были
последовательными и работали на моей домашней машине.
Это было очень долго, сборки шли сутками. Я перешел на параллельную
сборку сначала на машине basalt в 4 потока, а потом на машине altair.
На машине altair было 2cpu, 16ядер, 32 потока выполнения.

Но возникла другая проблема - видит око, да зуб неймет. Сборка все еще
была не так быстрой, как хотелось бы, так как не получалось загрузить все потоки
выполнения. После 8, ближе к 16 параллельным hsh занимаемый объем tmpfs не
вмещался в оперативку и скорость резко падала из-за своппинга
(Сейчас на altair 64Gb, 2Gb/поток).
И тут я заметил, что рабочие каталоги hasher'ов сами по себе настолько
тяжелые, что сравнимы по размеру со сборочным chroot,
а все тяжелые файлы из hasher/aptbox и hasher/cache - идентичны,
ведь сборка осуществляется относительно одного и того же репозитория.
Пришла идея хардлинковать эти общие тяжелые файлы в рабочих каталогах
hasher/aptbox и hasher/cache.

Соответствующий скрипт hsh-clone-workdir можно взять у меня из
hsh-clone-workdir.git. Это позволило сэкономить в tmpfs
в то время 640M на 1 копию hasher. При запуске в 24 потока это
дало 16G экономии, все влезло в оперативку, и сборка полетела.
Сейчас, так как и autoimports, и Сизиф подросли, это 723М экономии
 на 1 копию hasher при сборке для autoimports.

На чистом Сизифе сейчас это 570M экономии tmpfs на 1 копию hasher.
При работе с двумя hasher экономится 570M tmpfs, c 4 -- 1.7G tmpfs,
c 8 -- 3.9G tmpfs, c 16 -- 8.4G tmpfs.

Возможно, такой трюк пригодится и для arm.

Уголок статистики.

 du -sh hasher
 1,2G    hasher

 du -sh hasher/*
 482M    hasher/aptbox (330M pure Sisyphus)
 241M    hasher/cache
 491M    hasher/chroot

241M+491M=723М
723М

du -sh hasher/aptbox/var/lib/*
277M    hasher/aptbox/var/lib/apt
6,0M    hasher/aptbox/var/lib/rpm
200M hasher/aptbox/var/cache/apt

ls -lh hasher/cache/chroot/chroot.cpio
235M


-- 

I V