Warum sind Paketmanager so langsam?
Foto: by chuttersnap on Unsplash

Dieser Frage geht der bei Google tätige Entwickler Michael Stapelberg derzeit in seinem Blog und in einem Vortrag nach. Im März hatte Stapelberg seinen Rückzug aus Debian bekannt gegeben, wo er über zehn Jahre tätig war. Grund für seine Kritik an Debian waren dessen Strukturen, die ihm ein effizientes Arbeiten unmöglich machten.

Testobjekt Paketmanager

In der Zwischenzeit hat sich Stapelberg der Paketmanager angenommen und die bekanntesten Exemplare unter Linux systematisch untersucht. Im Grunde gibt es nur zwei Formate, von denen fast alle anderen mehr oder weniger abgeleitet sind. Dabei handelt es sich um das Debian-Paket deb und den Red Hat Package Manager rpm, die beide im Grunde Archivformate sind.

Sie machen zu viel

Was passiert nun, wenn wir eine Paketinstallation anstoßen? Traditionell werden zunächst die Paketlisten gelesen und die Abhängigkeiten überprüft. Darauf folgt der Download, das Entpacken der Archive und das Konfigurieren auf der Basis der im Paket hinterlegten Anweisungen. Schließlich wird das Paket in /usr/bin installiert.

Hoffen und Bangen

Der Moment der eigentlichen Installation nach dem Download der Pakete ist bei den hier betrachteten Paketmanagern heikel. Wenn währenddessen der Akku leer ist oder der Kernel aussteigt oder die Software fehlerhaft, haben wir meist ein Problem. Um das möglichst abzufedern, bedienen sich die Paketmanager des Linux-System-Calls fsync, um den gepufferten Dateiinhalt nicht nur im RAM zu haben, sondern auch auf den Datenträger zu schreiben. Das ist aber nur ein Grund warum eine Paketinstallation teilweise so lange dauert.

Stapelberg hat getestet, wie lange eine Auswahl von Paketmanagern braucht, um ein kleines und ein größeres Paket zu installieren:

Dabei hat das Paket ack eine Größe von 70 Kb, während qemu im Download 70 MB in die Waagschale wirft. Fedora macht bei beiden Paketen die schlechteste Figur. Die herunterzuladenden Metadaten stehen in keinem Verhältnis zur Größe des Pakets und das umso mehr, je kleiner das Paket ist.

Maintainer-Scripte

Ein weiterer Grund, warum Paketmanager lange für eine Paketinstallation brauchen sind die Maintainer-Scripte, die während der Installation über Hooks und Trigger abgearbeitet werden. Dabei werden Anweisungen aus den mit im Paket befindlichen Dateien preinst und postinst ausgeführt, die nach Stapelbergs Ansicht meist auch beim ersten Programmstart aufgerufen werden könnten. Zudem verhindert dieses Abarbeiten der Scripte, dass Pakete parallel installiert werden können.

Aus diesen Beobachtungen zog er den Schluss, dass entweder das Potenzial besteht, den Paketmanager selbst zu optimieren oder was das System macht, ist einfach zu komplex. Das veranlasste ihn dazu, eine experimentelle Distribution namens distri zu erstellen, die einige Dinge anders angeht und über einen wieselflinken Paketmanager verfügt.

Nicht ganz neu

Dabei hat Stapelberg das Rad nicht völlig neu erfunden, sondern verwendet Ideen aus der Distribution NixOS und deren Paketmanager Nix. Betrachtet man obige Grafik, so schafft es Nix einerseits, die benötigten Daten klein zu halten, erreicht aber andererseits nur lausige Übertragungsraten, sodass von der möglichen Geschwindigkeit nichts übrig bleibt. Stapelberg vermutet hier Implementationsfehler. Alpine und Arch Linux sind deutlich schneller als der Rest. Sie machen weniger als der Rest und das effizienter.

Images anstatt Archive

Stapelberg verwendet anstelle von Archiven, die entpackt werden müssen, Images, die schnell gemounted werden können, ähnlich wie bei AppImage oder Snap. Als Format kommen nur lesbare Squash-Images zum Zug, gemounted wird per FUSE. Ein weiterer Vorteil dieser Herangehensweise ist, dass die Pakete nicht verändert werden können. Ähnlich wie bei NixOS werden alle Bestandteile eines Pakets in ein einziges Verzeichnis installiert.

Wer näheres dazu lesen möchte, findet Details im Blog. Die Distribution soll ihren experimentellen Charakter behalten, kann aber von GitHub in verschiedenen Formaten heruntergeladen und getestet werden.

Warum sind Paketmanager so langsam?

Verwandte Themen

Debian diskutiert wieder über Init-Systeme
views 903
Das Thema Init-Systeme hat Debian schon mehrfach erschüttert. Zuletzt 2014, als sich Debian nach zähem Ringen durch eine Entscheidung des Technis...
GNU/Linux Debian 9.10 und 10.1 veröffentlicht
views 800
Debian 10 WallpaperWie bereits seit Längerem angekündigt, hat das Debian-Projekt am Wochenende die derzeit stabile Veröffentlichung Debian 10 »Bu...
DebConf19 hat begonnen
views 274
DebConf19 Logo by Ramon MulinAm 21. Juli beginnt in Curitiba im Südwesten Brasilien die 20. Ausgabe der alljährlichen Debian-Entwicklerkonferenz ...
Hinter den Kulissen eines Debian-Release
views 907
Vorschlag für Buster-ArtworkGerade erst wurde Debian 10 »Buster« veröffentlicht. Die Fertigstellung eines Debian-Release dauert in der Regel um d...
GNU/Linux Debian 10 »Buster« veröffentlicht
views 1.3k
Debian Buster HintergrundRund zwei Jahre sind vergangen, seit Debian 9 »Stretch« herausgegeben wurde. Jetzt erscheint, wie vor einigen Woche...

Beitrag kommentieren

Alle Kommentare
  • martin

    26.08.2019, 09:56 Uhr

    Komisch,
    ich habe mich immer gefragt, warum die Paketmanager im Vergleich mit Windows bei grösseren Updates immer um soviel schneller sind.

    Aber,…., vom reinen Gefühl her, kann ich nur sagen, das mir bisher kein Paketmanager wirklich langsam erscheint. Sowohl opensuse, welches ich seit Jahren auf einem Desktop PC verwende, als auch Fedora (neueres Notebook) und Debian (altes Netbook) liefern hier eine ordentliche Performance.

  • Rainer

    26.08.2019, 10:28 Uhr

    Hallo,
    finde auch das die Installationen und updates mit den Paketmanager schnell gehen.
    Früher bei openSuse, dann bei Linux-Mint und jetzt bei KDE-Neon.
    Läuft eigentlich immer zuckzuck durch.
    Rainer

    • Ferdinand Thommes

      26.08.2019, 10:38 Uhr

      Vergleichsweise sind die halt langsam. Schau dir mal den Paketmanager von Void an, da kann man von schnell sprechen.

  • fossonly

    26.08.2019, 15:10 Uhr

    Ich kann nicht wirklich nachvollziehen, was hier allen Ernstes langsam sein soll? Denn ausgehend von einer SSD und einer moderaten CPU, samt ordentlicher Internetverbindung, zieht apt unter Debian bei mir extrem durch. Prinzipiell ist der einzig problematische Faktor die Internetverbindung, die gewissermaßen unter fremder Kontrolle steht, und daher potenziell je nachdem blockieren kann. Aber sonst rattert apt zumindest bei mir, bei selbst großen Updates ausserordentlich schnell durch, und das nebenher ohne negativ zu beeinträchtigen.

    • Ferdinand Thommes

      26.08.2019, 16:02 Uhr

      Ich weiß, es ist Meckern auf hohem Niveau. Aber wenn das niemand macht, dann bleibt alles wie es ist. Und das ist nicht zukunftsträchtig. Ich verfolge gerne spannende Ideen und Experimente, von daher berichte ich über sowas. Schaut mal auf die Kommentare bei Pro Linux zur gleichen News von heute, da geht es auch recht kontrovers zu.

  • Fryboyter

    26.08.2019, 16:11 Uhr

    @martin
    >Aber,…., vom reinen Gefühl her, kann ich nur sagen, das mir bisher kein Paketmanager wirklich langsam erscheint

    Im Vergleich zu pacman ist apt relativ langsam. Nehmen wir zwei Raspberri Pi gleicher Bauart. Auf einem läuft Raspian und auf dem anderen Arch. Während apt noch dabei ist herauszufinden ob Updates vorhanden sind läd pacman die Updates meist schon herunter. An sich keine große Sache. Aber mich hat es genug genervt, dass ich die automatischen Updates für Raspbian aktiviert habe.

    An der Bandbreite der verwendeten Mirrors liegt es meiner Meinung aber nicht, da beide Geräte die Updates an sich mit voller Bandbreite herunterladen. Womöglich macht apt einfach mehr im Hintergrund.

  • martin

    26.08.2019, 19:08 Uhr

    ich kann nur eines sagen. Vor etwa 2 Monaten habe ich einen Windows 10 PC von Version 1809 auf 1903 aktualisiert. Angefangen wurde um 18 Uhr, Ende war um 2 Uhr Nachts (ungefähr 2/3 der Zeit für Downloads). Kurz zuvor hatte ich Fedora von 29 auf 30 aktualisiert. Mit der Downloadzeit dauerte das ganze 90 Minuten, davon 1h für den Download. Ein Netbook habe ich vor wenigen Wochen von Debian 9 auf 10 aktualisiert. Das dauerte etwas über 2h (mit Download) und ist auch der alten Hardware zu schulden. Trotzdem bin ich der Ansicht, das die Paketmanager schnell sind. Muss aber auch zugeben, das Pacman echt schnell ist.
    Zu Void Linux kann ich nur eines sagen, der bisher einzige Versuch dieses Systems ist ca. 2 Jahre her und war extrem erfolglos. Deshalb habe ich Void erst einmal ad acta gelegt, werde mir das System aber irgendwann nochmal ansehen.

  • tuxnix

    27.08.2019, 13:09 Uhr

    Wenn man Images verwendet spart man das Komprimieren und Dekomprimieren ein. Allerdings geht das zu Lasten der übertragenen Datenmenge. Wenn man Hooks und Trigger erst mit dem Programmstart abarbeitet, muss ein admin nach einem update auch jedes aktualisierte Programm aufrufen um die Installation abzuschließen. Das was als Vorteil erscheint geht hier sehr zu Lasten anderer Teilbereiche.
    Alte Strukturen zu hinterfragen ist immer mal gut. Aber weshalb hat Stapelberg die Werte von “distri” nicht in die Tabelle geschrieben? Für einen Vergleich wäre das sinnvoll gewesen.
    Den Vorschlag alle Bestandteile eines Pakets in ein einziges Verzeichnis zu installieren sollte man einzeln diskutieren. Die Veränderungen sind zu umfangreich für den direkten Vergleich.
    Was ich mich öfters man gefragt habe ist, ob mit dem Entpacken von Paketen nicht im Hintergrund schon begonnen werden könnte während das Download weiterer Pakete noch läuft. M.m. nach wäre hier viel Zeit einzusparen.

  • Ferdinand Thommes

    27.08.2019, 18:42 Uhr

    Auch Hacker News (HN) haben das Thema aufgegriffen. Einer der Kommentare verdeutlicht, wie groß die Unterschiede sein können.: »It’s odd that Alpine lets you install e.g. “emacs-nox” on an IoT device connected via crappy LTE, on the other side of the world, faster than you can install it on your local Ubuntu dev machine, with like 100-1000x more network bandwidth, 10-100x more CPU and 100-1000x faster local storage«.

  • Thomas S.

    29.08.2019, 09:14 Uhr

    Also ich kann das ebenfalls überhaupt nicht nachvollziehen. Selbst größere Updates unter Arch mit zig Programmen laufen in wenigen Minuten durch. Bei Ubuntu dauert es im Vergleich damit tatsächlich etwas länger.

    Ich habe mal getestest. Die qemu-Installation mit pacman ist bei mir in unter 3s fertig und braucht ganz bestimmt nicht über 1 Minute, wie im Test.

    • Ferdinand Thommes

      29.08.2019, 11:10 Uhr

      Das lag vermutlich daran, dass du die meisten Abhängigkeiten bereits im System hattest.