LINUX.ORG.RU
Форум — Talks  

Самый быстрый пакетный менеджер станет ещё быстрее

 , ,


0

1

В pacman 5.2 планируют использовать zstd вместо(?) xz. Ломать ничего не будут, т.к. у пакетов будет другой формат (.pkg.tar.zst). Держу в курсе.

Новость на опеннете

На всякий случай призываю alexferman

Deleted

Последнее исправление: cetjs2 (всего исправлений: 2)

Самый быстрый пакетный менеджер

apk из alpine быстрее. xbps на глаз тоже шустрее будет, но утверждать не буду.

Singularity ★★★★★
()

Первоисточник

https://www.archlinux.org/news/required-update-to-recent-libarchive/

Кстати, основное преимущество в том, что zstd многопоточный, а xz по-умолчанию нет. Для многопоточного xz не получается воспроизводимое сжатие, а сейчас стремятся к полной воспроизводимости.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от Deleted

Да, я вчера уже писал

Чукча не читатель, чукча писатель.

greenman ★★★★★
()
Ответ на: комментарий от Deleted

06.10.2019

Вот примерно поэтому я не видел

Deleted
()
Ответ на: комментарий от Singularity

Ну, gzip самый реактивный вроде, ценой эффективности сжатия.

Deleted
()

Самый быстрый пакетный менеджер

Ни слова не вижу про xbps.

Thetan ★★★
()

И тут Леня добрался своими шаловливыми ручонками. Зачем ломать то что столько лет работало безотказно?

Пора валить с этого школодистра, ломающего каждую неделю совместимость!

Behem0th ★★★★★
()

Самый быстрый пакетный менеджер

aleksej@lenovo:~/Загрузки$ grep -rw --include=*.c 'fsync\|fflush' pacman/
pacman/lib/libalpm/log.c:		fflush(handle->logstream);
pacman/lib/libalpm/util.c:	fflush(NULL);
pacman/src/pacman/callback.c:	fflush(stdout);
pacman/src/pacman/callback.c:	fflush(stdout);
pacman/src/pacman/callback.c:		fflush(stdout);
pacman/src/pacman/callback.c:		fflush(stderr);
pacman/src/pacman/callback.c:			fflush(stdout);
pacman/src/pacman/files.c:	fflush(stdout);
pacman/src/pacman/package.c:	fflush(stdout);
pacman/src/pacman/util.c:		fflush(stream);
pacman/src/pacman/util.c:		fflush(stream);
pacman/src/pacman/util.c:	fflush(stdout);
pacman/src/pacman/util.c:	fflush(stderr);
pacman/src/pacman/util.c:	fflush(stream);
pacman/src/pacman/util.c:	fflush(stdout);

Ну ещё бы.

Для сравнения: 

aleksej@lenovo:~/Загрузки$ grep -rw --include=*.c 'fsync\|fflush' dpkg/
dpkg/utils/update-alternatives.c:	if (fflush(ctx.fh))
dpkg/utils/update-alternatives.c:	if (fsync(fileno(ctx.fh)))
dpkg/dpkg-deb/build.c:  if (fsync(ar->fd))
dpkg/lib/dpkg/mlib.c:  fflush(f);
dpkg/lib/dpkg/dbmodify.c:  if (fflush(importanttmp))
dpkg/lib/dpkg/dbmodify.c:  if (fflush(importanttmp))
dpkg/lib/dpkg/dbmodify.c:  if (fsync(fileno(importanttmp)))
dpkg/lib/dpkg/dbmodify.c:    ohshite(_("unable to fsync updated status of '%.250s'"),
dpkg/lib/dpkg/atomic-file.c:	if (fflush(file->fp))
dpkg/lib/dpkg/atomic-file.c:	if (fsync(fileno(file->fp)))
dpkg/lib/dpkg/dir.c:	if (fsync(fd))
dpkg/lib/dpkg/dir.c:	if (fsync(fd))
dpkg/lib/dpkg/compress.c:	/* Because BZ2_bzWriteClose has done a fflush on the file handle,
dpkg/lib/compat/vsnprintf.c:	if (fflush(file))
dpkg/src/archives.c:   * asynchronous hint for the kernel, we are doing an fsync() later on
dpkg/src/archives.c:    /* Postpone the fsync, to try to avoid massive I/O degradation. */
dpkg/src/archives.c:     * asynchronous hint for the kernel, we are doing an fsync() later on
dpkg/src/archives.c:      debug(dbg_eachfiledetail, "deferred extract needs fsync");
dpkg/src/archives.c:      if (fsync(fd))
dpkg/src/unpack.c:  fflush(stdout);
dpkg/src/unpack.c:   * explicit fsync()s, we have to do them here.
dpkg/src/divertcmd.c:	if (fsync(dstfd))
dpkg/dpkg-split/queue.c:    if (fsync(fd_dst))
dpkg/dpkg-split/join.c:  if (fsync(fd_out))

dpkg --force-unsafe-io тоже очень быстрый, ага.

Rootlexx ★★★★★
()
Ответ на: комментарий от commagray

понятно... я с беты сижу (фактически на релизе уже) на zstd, хорошо все.

cetjs2 ★★★★★
()
Ответ на: комментарий от Behem0th

Пора валить с этого школодистра, ломающего каждую неделю совместимость!

Как говорится, в добрый путь!

m0rph ★★★★★
()
Ответ на: комментарий от Polugnom

Да ты просто мастер чтения, я смотрю.

See Appendix B for details on the measurement method and command outputs.

Deleted
()
Ответ на: комментарий от Singularity

xbps метеорит по сравнению с рачевским пакманом

One ★★★★★
()
Ответ на: комментарий от Deleted

замеры, включающие скачку пакетов

apk просто в принципе не умеет локально кэшировать пакеты, лол. Приходится подстраиваться.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Polugnom

http://ix.io/1Z2q:

$ podman run -it --rm archlinux
[root@163756f4cb76 /]# echo 'Server = http://mirror.yandex.ru/archlinux/$repo/os/$arch' > /etc/pacman.d/mirrorlist
[root@163756f4cb76 /]# time pacman -Sy linux-firmware --noconfirm
:: Synchronizing package databases...
 core                                                                  133.5 KiB  3.26M/s 00:00 [########################################################] 100%
 extra                                                                1645.5 KiB  17.1M/s 00:00 [########################################################] 100%
 community                                                               4.9 MiB  21.2M/s 00:00 [########################################################] 100%
resolving dependencies...
looking for conflicting packages...

Packages (1) linux-firmware-20190923.417a9c6-1

Total Download Size:    82.02 MiB
Total Installed Size:  470.66 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages...
 linux-firmware-20190923.417a9c6-1-any                                  82.0 MiB  8.46M/s 00:10 [########################################################] 100%
(1/1) checking keys in keyring                                                                  [########################################################] 100%
(1/1) checking package integrity                                                                [########################################################] 100%
(1/1) loading package files                                                                     [########################################################] 100%
(1/1) checking for file conflicts                                                               [########################################################] 100%
(1/1) checking available disk space                                                             [########################################################] 100%
:: Processing package changes...
(1/1) installing linux-firmware                                                                 [########################################################] 100%
:: Running post-transaction hooks...
(1/2) Creating temporary files...
<...>
(2/2) Arming ConditionNeedsUpdate...

real    0m15.573s
user    0m5.095s
sys     0m0.581s

http://ix.io/1Z2t:

$ podman run -it --rm alpine
/ # echo 'http://mirror.yandex.ru/mirrors/alpine/v3.10/main' > /etc/apk/repositories
/ # echo 'http://mirror.yandex.ru/mirrors/alpine/v3.10/community' >> /etc/apk/repositories
/ # time apk add linux-firmware
fetch http://mirror.yandex.ru/mirrors/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://mirror.yandex.ru/mirrors/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/84) Installing linux-firmware-yamaha (20190322-r1)
<...>
(84/84) Installing linux-firmware (20190322-r1)
OK: 442 MiB in 98 packages
real    0m 23.03s
user    0m 2.45s
sys     0m 0.62s

23s vs 15s, шах и мат.

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от Polugnom

Fedora

Давайте всё перепишем на Python и на каждый чих будем грузить 100МБ какого-то дерьма:

Fedora’s dnf takes almost 30 seconds to fetch and unpack 107 MB.
Fedora’s dnf takes over a minute to fetch and unpack 266 MB.

Вот серьёзно, медленнее dnf придумать пакетный менеджер можно?

EXL ★★★★★
()
Ответ на: комментарий от intelfx

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

Почему бы тогда просто не скачать пакет curl’ом или wget’ом и локально сделать:

pacman -U packagename.tar.gz
apk add --allow-untrusted packagename.apk

На одной версии (у тебя в твоём примере 20190322-r1 vs 20190923) какого-нибудь пакета, вроде того же qemu или git?

Хотя и тут могут быть side-эффекты, например, различные зависимости.

EXL ★★★★★
()
Ответ на: комментарий от ZERG

Это довольно сложная проблема. Всякие автокады тоже однопоточные. Для случая с PM пакеты можно просто распаковывать одновременно.

boowai ★★★★
()
Ответ на: комментарий от EXL

Почему бы тогда просто не скачать пакет curl’ом или wget’ом и локально сделать:

Правильнее будет отзеркалировать репозиторий (или его часть) локально и работать с ним. Потому что разбор индексов — это тоже часть бенчмарка. Но мне влом.

Хотя и тут могут быть side-эффекты, например, различные зависимости.

Да, в этом и есть основная проблема. Тот же qemu в арче имеет в несколько раз больше зависимостей, чем в alpine.

Тесты конкретно Stapelberg’а вообще непонятно как были проведены — из них следует, что pacman едва ли не медленнее dnf (что заведомо неправда).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

Ну это замеры погоды на Марсе. Тогда уж поднял бы репозиторий локально и соединялся с ним из виртуалки или контейнера.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

а вы знаете почему неуловимый джо, неуловимый?

chenbr0 ☆
()
Ответ на: комментарий от EXL

Давайте всё перепишем на Python

ЕМНИП, на Python там осталась лишь морда, а остальное - в библиотеке на C.

и на каждый чих будем грузить 100МБ какого-то дерьма

Всё же это не просто так: поскольку в rpm зависимости могут быть не только от имени пакета, но и от его содержимого, размер метаданных тупо больше. Но да, dnf тормоз. И имеет ещё странности вроде своего кеша у каждого пользователя, в результате чего одни и те же данные могут перекачиваться по несколько раз.

Rootlexx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks