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

[Alexey Tourbin]

Уважаемые мужчины!

Вследствие перехода на rpm-4.13 в вашем национальном дистрибутиве
наблюдается многократное замедление работы.

Вот как сканировал пакеты старый rpm:

$ killall -STOP ktorrent chromium
$ rpmpeek /var/cache/apt/archives/rpm_4.0.4-alt101.M80P.1_x86%5f64_1484665077.rpm \
	cp -pv ./usr/lib/rpm/rpmq /tmp
'./usr/lib/rpm/rpmq' -> '/tmp/rpmq'
$ cd /klad/Sisyphus/files/x86_64/RPMS
$      /tmp/rpmq -p *.rpm >/dev/null
$ time /tmp/rpmq -p *.rpm >/dev/null
0.85s user 0.31s system 99% cpu 1.166 total

Вот как сканирует пакеты новый rpm:

$      rpmquery -p *.rpm >/dev/null
$ time rpmquery -p *.rpm >/dev/null
3.51s user 0.25s system 99% cpu 3.757 total

Сканирует в четыре раза дольше - вместо '0.85 user' стало '3.51 user'.
Предварительный осмотр показывает, что rpm теперь вычисляет какие-то
хитрые SHA1-суммы.

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

Старый rpm сканировал пакеты так:

$ sudo sysctl vm.drop_caches=3
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       4582       3283          0          1       1601
-/+ buffers/cache:       2979       4886
Swap:        32763       3176      29586
$ time /tmp/rpmq -p *.rpm >/dev/null
2.06s user 1.85s system 2% cpu 3:04.51 total
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       5247       2619          0         25       2199
-/+ buffers/cache:       3021       4844
Swap:        32763       3176      29586

То есть при сканировании x86_64 пакетов отъедалось примерно 600 Мб
буферного кеша.

Новый rpm сканирует пакеты так:

$ sudo sysctl vm.drop_caches=3
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       4580       3286          0          1       1602
-/+ buffers/cache:       2976       4889
Swap:        32763       3176      29586
$ cd /klad/Sisyphus/files/x86_64/RPMS
$ time rpmquery -p *.rpm >/dev/null
4.66s user 1.89s system 3% cpu 3:13.99 total
$ free -m
             total       used       free     shared    buffers     cached
Mem:          7866       6534       1331          0         28       3482
-/+ buffers/cache:       3023       4843
Swap:        32763       3176      29586

Новый rpm при сканировании x86_64 пакетов отъел 1880 Мб, более чем
в 3 раза больше старого.  Мужчины, прогресс пришел в ваш дом!

Рассмотрим пример прогресса на конкретном пакете.  Я вот для себя
собираю пакет ffmpeg, потому что в вашем национальном дистрибутиве его
немає.

$ linux-fadvise ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm POSIX_FADV_DONTNEED
...
$ /tmp/rpmq -p ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm
ffmpeg-3.1.6-alt0
$ linux-fincore ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm |tail -1
total cached size: 8,192

С новым rpm:

$ linux-fadvise ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm POSIX_FADV_DONTNEED
...
$ rpmquery -p ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm
ffmpeg-3.1.6-alt0.x86_64
$ linux-fincore ~/RPM/RPMS/x86_64/ffmpeg-3.1.6-alt0.x86_64.rpm |tail -1
total cached size: 49,152

У пакета ffmpeg маленький заголовок, потому что в нем находится только
программа ffmpeg (плюс еще ffplay и ffprobe) и несколько man-страниц.
Старому rpm нужно было 2 страницы виртуальной памяти, новому - 12.

Всё это конечно же происходит из-за readahead.  Я когда-то делал патч
для отключения readahead во время загрузки заголовка:
http://git.altlinux.org/people/at/packages/rpm.git?a=commitdiff;h=66b17f5f
На новый rpm его не портировали.

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

* * *

В связи со всем этим безобразием более актуально встает вопрос о
кешировании заголовков.  Пожалуй, напишу об этом отдельным письмом.