Re: [devel] печальные последствия перехода на rpm-4.13

[Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

Hi,

On Wed, Jan 25, 2017 at 07:48:12AM +0300, Alexey Tourbin wrote:
> Уважаемые мужчины!
> 
> Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
> наблюдается многократное замедление работы.
> 
> Вот как сканировал пакеты старый rpm:
[...]
> Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
> хитрые SHA1-суммы.

Никакой хитрости, оно сравнивает SHA1HEADER с реальностью.  Мне не кажется
это совсем плохой идеей, а для чтения тысяч файлов всегда можно сделать
%__vsflags = %__vsflags|_RPMVSF_NODIGESTS, например 0xf0f00.

> Но это полбеды, а настоящий масштаб бедствия становится понятен, если
> посмотреть, что происходит с виртуальной памятью.
[...]

Спасибо за исследование!

> У пакета ffmpeg маленький заголовок, потому что в нем находится только
> программа ffmpeg (плюс еще ffplay и ffprobe) и несколько man-страниц.
> Старому rpm нужно было 2 страницы виртуальной памяти, новому - 12.
> 
> Всё это конечно же происходит из-за readahead.  Я когда-то делал патч
> для отключения readahead во время загрузки заголовка:
> http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=66b17f5f
> На новый rpm его не портировали.

Да, портировалось необходимое, а такие вещи к сожалению остались
до появления необходимости. :)

Со спортированным патчем (см task #177147) на rpmquery
-p ~/chromium-55.0.2883.75-alt1.x86_64.rpm получается:

-total cached size: 245,760
+total cached size: 77,824

Раньше были те же 77,824.

> Правда, этот патч мне не очень нравится, потому на время загрузки
> заголовка readahead отключается полностью.

В контексте сборочницы этот патч очень важен когда кэша нет.  Мы даже с
ним теряем минут, кажется, 40 на создание кэша.

> Теоретически этом может
> привести к тому, что для загрузки заголовка может потребоваться
> несколько physical reads.  Но на практике их не требуется (ср. total
> time у /tmp/rpmq и rpmquery) - вероятно, выручает встроенный кеш
> внутри самого жесткого диска.
>
> * * *
> 
> В связи со всем этим безобразием более актуально встает вопрос о
> кешировании заголовков.  Пожалуй, напишу об этом отдельным письмом.

Если речь в первую очередь о сборочнице, то, возможно, стоит задуматься о
патчинге apt-овых индексов (вместо генерации их с нуля).  Остальные
клиенты gb-sh-rpmhdrcache вполне могли бы патчить то, что у них есть -- и
генератор useful-files и генератор contents_index.
Понятно, что единственной загвоздкой в патчинге индексов являются именно
useful-files.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]