[devel] статистика [2]
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Сб Авг 25 01:23:57 MSD 2007
On Thu, Aug 23, 2007 at 05:23:04PM +0400, Alexey Tourbin wrote:
> 5) Теперь этот вывод несложно обработать скриптом print-uris-filter.awk,
> чтобы на выходе получить таблицу
> <src-rpm-basename> <inst-rpm-basename>
> Эта таблица означает, что для src.rpm пакета <src-rpm-basename>
> в билдрут будет ставиться собранный rpm пакет <inst-rpm-basename>.
>
> $ head .pR >.pR1
> $ PATH=$PWD:$PATH $TMPDIR/build/aptbox/apt-get -qq -y script ./print-uris.lua <.pR1 >.uris
> $ awk -f ./print-uris-filter.awk .uris |head
> 7colors-0.80-alt5.src.rpm glib-1.2.10-alt12.i586.rpm
> 7colors-0.80-alt5.src.rpm libORBit-0.5.17-alt3.i586.rpm
> 7colors-0.80-alt5.src.rpm ORBit-0.5.17-alt3.i586.rpm
> 7colors-0.80-alt5.src.rpm libfontenc-1.0.4-alt1.i586.rpm
> 7colors-0.80-alt5.src.rpm libfreetype-2.3.5-alt2.i586.rpm
> 7colors-0.80-alt5.src.rpm libXfont-1.2.8-alt2.i586.rpm
> 7colors-0.80-alt5.src.rpm bdftopcf-1.0.1-alt1.i586.rpm
> 7colors-0.80-alt5.src.rpm libdb1-1.85-alt5.i586.rpm
> 7colors-0.80-alt5.src.rpm db1-utils-1.85-alt5.i586.rpm
> 7colors-0.80-alt5.src.rpm libaudiofile-0.2.6-alt2.i586.rpm
> $ awk -f ./print-uris-filter.awk .uris |sort -u -k1,1
> 7colors-0.80-alt5.src.rpm glib-1.2.10-alt12.i586.rpm
> a2ps-4.13-alt3.src.rpm libfontenc-1.0.4-alt1.i586.rpm
> aalib-1.4-alt2rc5.src.rpm libX11-locales-1.1.3-alt3.i586.rpm
> abinit-4.6.5-alt1.src.rpm gcc-fortran-common-1.4.10-alt2.i586.rpm
> abiword-2.4.6-alt2.src.rpm libIDL-0.8.8-alt1.i586.rpm
> abook-0.5.6-alt1.src.rpm libtinfo-devel-5.6-alt3.i586.rpm
> abuse_sdl-0.7.0-alt4.src.rpm ca-certificates-2007.02.06-alt1.noarch.rpm
> acidrip-0.14-alt1.src.rpm ca-certificates-2007.02.06-alt1.noarch.rpm
> acl-2.2.39-alt1.0.src.rpm libattr-devel-2.4.32-alt1.0.i586.rpm
> $
>
> Теперь задача почти решена. Мы имеем вновь пришедшие пакеты
> <inst-rpm-basename>, и хотим узнать, какие <src-rpm-basename>
> подлежат пересборке. Это тривиальный join по этой таблице.
Займемся теперь вопросом, сколько же сизифовских пакетов придётся
тестировать пересборкой на каждый входящий src.rpm пакет. У меня
есть полная таблица, кусочек которой приведен выше. Введу новое
обозначение для полей таблицы:
<test-src-rpm-basename> <incoming-rpm-basename>
Это означает, что собравшийся в incoming'е пакет <incoming-rpm-basename>,
оказывается, встает в чрут для сборки <test-src-rpm-basename>. Значит,
вследствие прохождения <incoming-rpm-basename> нужно протестировать
пересборкой <test-src-rpm-basename>.
Я дополнил эту таблицу ещё одним полем:
<test-src-rpm-basename> <incoming-rpm-basename> <incoming-src-rpm-basename>
Последнее поле означает, какой src.rpm пакет собрался в incoming'е.
Это нужно для того, чтобы учитывать, что из одного src.rpm пакета
при сборке в среднем получается больше одного установочного пакета,
которые будут вставать в чрут. Это не должно искажать статистики.
Я выложил эту таблицу сюда (952K):
ftp://ftp.altlinux.org/pub/people/at/rebuild-map.bz2
Вот несколько случайных строчек этой таблицы:
$ perl -MList::Util=shuffle -e 'print +(shuffle<>)[1..10]' <rebuild-map
qmmp-0.1.3.1-alt1.src.rpm libxkbfile-devel-1.0.4-alt1.i586.rpm libxkbfile-1.0.4-alt1.src.rpm
emacs-apel-10.6-alt1.20050606.src.rpm emacs-devel-0.0.1-alt3.noarch.rpm emacs-devel-0.0.1-alt3.src.rpm
kde-styles-klearlook-0.9.9.2-alt1.1.src.rpm libXmu-devel-1.0.3-alt1.i586.rpm libXmu-1.0.3-alt1.src.rpm
k3b-i18n-full-1.0.3-alt3.src.rpm gccmakedep-1.0.1-alt1.i586.rpm gccmakedep-1.0.1-alt1.src.rpm
grip-3.1.3-alt5.src.rpm libjpeg-6b-alt8.i586.rpm libjpeg-6b-alt8.src.rpm
wmmemload-0.1.6-alt3.src.rpm libXext-1.0.3-alt1.i586.rpm libXext-1.0.3-alt1.src.rpm
xfce4-panel-4.4.1-alt2.src.rpm libfreetype-devel-2.3.5-alt2.i586.rpm libfreetype-2.3.5-alt2.src.rpm
mysql-gui-tools-5.0r12-alt1.src.rpm libXp-1.0.0-alt3.0.i586.rpm libXp-1.0.0-alt3.0.src.rpm
tracker-0.6.0-alt0.1.src.rpm libpoppler-glib-devel-0.5.4-alt6.i586.rpm poppler-0.5.4-alt6.src.rpm
showfont-1.0.1-alt1.src.rpm libFS-1.0.0-alt2.i586.rpm libFS-1.0.0-alt2.src.rpm
$
Замечу, что эту таблицу нужно читать в обратном порядке, справа налево:
"пришёл пакет libxkbfile-*.src.rpm, из него собрался пакет libxkbfile-devel-*.i586.rpm,
из-за чего придётся протестировать пересборкой qmmp-*.src.rpm" и т.д.
Среднее поле в таблице на самом деле оказывается не слишком нужным,
я его удалю:
$ cut -f1,3 rebuild-map |sort -u -k2,2 -k1,1 >.ss
$ perl -MList::Util=shuffle -e 'print +(shuffle<>)[1..10]' <.ss
lprof-1.11.4.1-alt1.src.rpm libxml2-2.6.29-alt2.src.rpm
$
"Пришел пакет libxml2-*.src.rpm, требуется протестировать пересборкой lprof-*.src.rpm".
Теперь несложно для каждого входящего пакета в incoming (справа)
вычислить число src.rpm пакетов (слева), подлежащих пересборке.
$ uniq -c -f1 .ss |head -1
144 alt-docs-main-0.4-alt7.src.rpm ALDConvert-0.05-alt8.src.rpm
$
Здесь alt-docs-main это просто первый пакет, который попался и поэтому
остался, суть в том, что пакет ALDConvert-*.src.rpm на входе, если он
конечно соберётся, потребует протестировать пересборкой 144 пакетов.
Я теперь сделаю совсем уж интуитивно понятную таблицу
<incoming-src-rpm-basename> <rebuild-number-src-rpm>
$ uniq -c -f1 .ss |awk '{print$3"\t"$1}' |sort -k2,2n >.sz
$ head -2 .sz
GraphicsMagick-1.1.8-alt1.src.rpm 1
MySQL41-4.1.21-alt5.1.src.rpm 1
$ tail .sz
libSM-1.0.3-alt1.src.rpm 1952
libICE-1.0.4-alt1.src.rpm 1962
fontconfig-2.4.2-alt3.src.rpm 2120
libXext-1.0.3-alt1.src.rpm 2196
libfreetype-2.3.5-alt2.src.rpm 2203
gcc4.1-4.1.1-alt11.src.rpm 2365
libXau-1.0.3-alt1.src.rpm 2388
libXdmcp-1.0.2-alt1.0.src.rpm 2389
libX11-1.1.3-alt3.src.rpm 2392
expat-2.0.1-alt0.1.src.rpm 2646
$
Видим, что GraphicsMagick на входе потребует пересборки всего одного
src.rpm пакета (кстати, это koffice), а expat на входе потребует
пересобрать уже 2646 src.rpm пакетов. Всего сейчас в репозитарии 6687
src.rpm пакетов (с точки зрения этой статистики).
ЗДЕСЬ НЕ УЧИТЫВАЮТСЯ ИЗМЕНЕНИЯ В basesystem + rpm-build.
Любой пакет, который попадает в basesystem + rpm-build, потребует,
по идее, полной пересборки сизифа, и этот случай я сейчас специально
отсёк. Никакой другой пакет, однако, не может зацепить для пересборки
даже и половину сизифа.
Я пока объявляю пакеты из basesystem + rpm-build частным случаем, который
в данной статистике не рассматривается.
Сколько же всего имеется "входных" src.rpm пакетов, которые могут
потребовать пересборку чего-либо?
$ wc -l <.sz
2261
$
Это означает, что ТОЛЬКО КАЖДЫЙ ТРЕТИЙ ПАКЕТ просит что-то пересобрать.
Большая половина пакетов являются "листьями" ("приложениями") и заведомо
не влияют на собираемость каких-либо других пакетов.
Значит, будем считать среднее количество пакетов на пересборку для
"каждого третьего" пакета, а на каком-то этапе результат просто поделим
результат на три. С точки зрения мат. статистики это, наверное, не
совсем правильно, то для грубой оценки сойдет.
Итак, распределение числа пакетов, подлежащих пересборке.
Среднее значение значение 78 пакетов, медиана распределения
5 пакетов, сигма 253 пакета. Как и со временем сборки пакетов,
получилось распределение с маленьким средним значением и большой
сигмой. Значит, говорить об "единичном случае" не серьезно,
нужно считать значения для серии пакетов.
Прежде всего однако прикинем порядок среднего значения.
78 пакетов * 74 секунды это порядка 100 минут.
Рационально считать время сборки для серии из 25 входящих src.rpm
пакетов. Это очень грубо означает, что мы закладываемся на "суточную
норму", и неудачные последовательности входящих пакетов с достаточно
высокой надежностью не должны выбрасывать нас за пределы суток.
Прежняя формула для "достаточно надёжного заклада" говорит:
P( xi(N) <= N*(mu+2*sigma/sqrt(N) ) >= 0.95
В данном случае xi(N) -- суммарное число src.rpm пакетов, подлежащих
пересборке на серии из N входящих пакетов, N=25; mu=78 пакетов,
sigma=253 пакета.
Вычислим член mu+2*sigma/sqrt(N), он даёт "среднее по выборке из 25"
с надёжностью 95% на превышение суммарного времени.
$ perl -le 'print 78+2*253/5'
179.2
$
Значит, чтобы нас не шатало "по суточной норме", вместо среднего
значения 78 пакетов нужно брать с запасом 179 пакетов.
Сколько времени будут собираться 179 пакетов? Из предыдущего письма
известно, что t(N) = N*(74+2*189/sqrt(N));
t(179) = 18303 секунды = 5 часов.
Итого, каждый третий входящий src.rpm пакет с вероятностью 95%
уложится на пересборочном тестировании в 5 часов; это усреднение
по 25 входящим пакетам. То есть на самом деле утверждение состоит
в том, что 25 входящих src.rpm с вероятностью около 95% уложатся
в 25*5=125 часов.
Среднее же время без "суточной надёжности" составляет, как уже
посчитано, 78 пакетов на пересборку * 74 секунды = 100 минут.
ЭТО ОЗНАЧАЕТ, ЧТО СРЕДНЯЯ ЗАГРУЗКА СЕРВЕРОВ на большом промежутке
времени (допустим, месяц) составит 100 минут/25 часов = 7%.
(Имеется в виду загрузка только на пересборочном тестировании.)
Запас серверной мощности, нужен, по сути, для того, чтобы "неудачная
последовательность входящих пакетов" не заставляла нас слишком долго
ждать.
Настало время поделить на 3. Подумаем, насколько это корректно.
Мы исходили из того, что все входящие пакеты подряд требуют что-то
пересобрать. Теперь они будут "перемешиваться" с пакетами, которые
пересобрать ничего не требуют. Значит, это не должно ухудшить
показателя за счёт каких-либо выбросов.
ИТОГО, 5 часов/3 = 100 минут.
ОТВЕТ: на серии из N пакетов, где N порядка 25, суммарное время
пересборочного тестирования с вероятностью 95% не превысит N*100 минут.
Это довольно грубый ответ, и реально он может отличаться раза в два,
но не на порядок. Завтра я попробую провести численный эксперимент,
который даст альтернативный и реально более правильный ответ.
Теперь настало время понять, чем статистика отличается от наглой лжи.
Ведь если пришёл пакет expat, то придётся ждать 54 часа, что на порядок
больше 5 часов и, похоже, выбрасывает нас за суточную норму. Просто
expat выбивается за пределы 95-процентной надёжности. Но в этом году
пакет expat был собран всего один раз. То есть при случайном
поступлении пакетов появление expat это очень редкое событие.
Придётся подождать.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20070825/4fa887d2/attachment-0001.bin>
Подробная информация о списке рассылки Devel