PGO-Tests für Datenbankserver zeigen, warum Optimierung die Geschwindigkeit verringern kann
Von Percona veröffentlichte PGO-Tests einer relationalen Open-Source-Datenbank, die von vielen Webanwendungen genutzt wird, zeigen: Eine Optimierung, die Datenbanksoftware schneller machen soll, kann auch eine langsamere ausführbare Datei hervorbringen. In einem Vergleich brachte eine mit profilgesteuerter Optimierung (PGO) erstellte Release-Version eine Verbesserung von weniger als 5 %. PGO nutzt aufgezeichnetes Programmverhalten, um die Kompilierung zu steuern. Individuell erstellte Builds, die anhand eines bestimmten Datenbanktests trainiert wurden, liefen dagegen langsamer als Builds ohne PGO. Das sind voneinander getrennte Beobachtungen und kein Beleg dafür, dass die Technik grundsätzlich hilft oder schadet.
In einem Artikel vom 9. Oktober 2026 beschreibt Percona seine Untersuchung der Frage, ob es sinnvoll ist, PGO für seinen Datenbankserver standardmäßig zu aktivieren. Der Bericht ist der Auftakt einer dreiteiligen Erläuterung dazu, was PGO ist, wie es funktioniert, warum ein mit dem Leistungstestwerkzeug sysbench trainierter Build an Leistung verliert und wie man das Training richtig angeht. Dieser erste Teil berichtet über das unerwartete Ergebnis, weist aber dessen Ursache nicht nach.
PGO verändert, wie Software erstellt wird. Bei der Kompilierung wird Quellcode in ein ausführbares Programm übersetzt. In dem von Percona beschriebenen zweistufigen Verfahren enthält der erste Build eine Instrumentierung: zusätzliche Zähler, die Aktivitäten an Verzweigungen aufzeichnen, an denen die Ausführung einen Pfad wählt, an Schleifen, in denen Arbeitsschritte wiederholt werden, und an Aufrufstellen, an denen eine Funktion eine andere aufruft. Anschließend wird dieser instrumentierte Build mit einer repräsentativen Trainingslast ausgeführt, also mit Aufgaben, die das Programm beanspruchen sollen. Die Zähler identifizieren häufig ausgeführten Code, sogenannten Hot Code, und selten ausgeführten Code, sogenannten Cold Code. Eine zweite Kompilierung nutzt diese Beobachtungen, um die entstehende ausführbare Datei zu gestalten.
Der Compiler kann diese Informationen auf verschiedene Weise nutzen. Er kann häufige Funktionsaufrufe verstärkt inline einbinden, also die Anweisungen einer Funktion direkt dort einsetzen, wo sie benötigt werden, statt einen separaten Aufruf auszuführen. Er kann häufig durchlaufene Pfade so anordnen, dass die Ausführung über benachbarte Anweisungen fortgesetzt wird, und selten genutzte Pfade aus diesem Ablauf heraus verlagern. Außerdem kann er Funktionen innerhalb der Binärdatei, also der kompilierten ausführbaren Datei, neu anordnen, sodass Codeabschnitte, die häufig zusammenarbeiten, nahe beieinanderliegen. Das verbessert die Lokalität im Instruktionscache: Der Prozessor kann seinen kleinen, schnellen Speicher für Programmanweisungen besser nutzen. Häufig aufgelöste indirekte Aufrufe, deren Ziel erst während der Ausführung ausgewählt wird, können zudem in direkte Aufrufe eines bekannten Ziels umgewandelt werden.
Diese Mechanismen erklären, warum die Qualität des Trainings wichtig ist. PGO beschleunigt nicht einfach den Trainingslauf. Es verändert die Struktur der ausführbaren Datei entsprechend den Aktivitäten, die während dieses Laufs beobachtet wurden. Entscheidend ist deshalb, ob das Training die Aufgaben widerspiegelt, die die Datenbank bewältigen muss, und nicht nur, ob ein Trainingslauf erfolgreich abgeschlossen wurde. Ein Profil liefert Erkenntnisse über ein bestimmtes Ausführungsmuster, aber kein Versprechen höherer Leistung bei jedem möglichen Muster.
Percona berichtet von zwei unterschiedlichen Ergebnissen. Der Vergleich eines Builds ohne PGO mit einer PGO-Release-Version zeigte einen kleinen Vorteil von weniger als 5 %. Unabhängig davon wurde die Open-Source-Datenbank mit PGO anhand einer Aufzeichnung von sysbench-tpcc kompiliert, einem Test für Datenbanktransaktionen. Der daraus entstandene Build war in den beschriebenen Tests durchweg langsamer als der Build ohne PGO. Auch eine Änderung der Parallelität beim Training, also der Anzahl gleichzeitig arbeitender Threads, kehrte dieses Ergebnis nicht um: Percona gibt an, Thread-Zahlen von 128 bis 1024 ausprobiert zu haben. Im Fließtext des Berichts wird die Verlangsamung nicht beziffert. Daher lässt sich dieser Leistungseinbuße kein belegter Prozentwert zuordnen.
Eine wichtige Einschränkung ergibt sich aus der Leserdiskussion. Ein Kommentator fragt, ob beim Abschalten von PGO alle anderen Compiler-Einstellungen unverändert geblieben seien. Außerdem schlägt er vor, die Linkzeitoptimierung (LTO) zu aktivieren. Sie ermöglicht es den Build-Werkzeugen, über separat kompilierte Programmteile hinweg zu optimieren, und könne seiner Ansicht nach die Leistungsgewinne durch PGO verstärken. Das sind von einem Leser vorgeschlagene Prüfungen, keine bestätigten Erklärungen oder zusätzlichen Versuchsergebnisse. Aus dem vorliegenden Bericht geht nicht hervor, ob andere Einstellungen geändert wurden oder ob LTO aktiviert war.
Für Datenbankbetreiber und Unternehmen, die auf die Open-Source-Datenbank angewiesen sind, lautet die übertragbare Erkenntnis: Eine Änderung am Build sollte überprüft werden, statt die Bezeichnung „Optimierung“ als Beleg für eine Verbesserung zu betrachten. Ein aussagekräftiger Vergleich sollte die übrigen Build-Einstellungen unverändert lassen und Aufgaben verwenden, die den vorgesehenen Einsatz widerspiegeln. Die genannten Thread-Zahlen zeigen außerdem, warum man nicht davon ausgehen kann, dass allein eine höhere Parallelität beim Training eine Leistungseinbuße behebt. Hier geht es um eine Leistungsuntersuchung, nicht um einen Bericht über eine Sicherheitslücke.
Für Organisationen, die auf externe Unterstützung beim Betrieb angewiesen sind, sind die verwalteten Datenbanken, das Monitoring und die automatisierten Backups von AEU Data relevant, um Datenbankänderungen zu überwachen und gespeicherte Daten zu schützen. Diese Dienste belegen jedoch nicht, ob ein bestimmter PGO-Build schneller ist. Die offene Frage in Perconas erstem Bericht bleibt konkret: Warum verlor dieser mit sysbench trainierte Build an Leistung, obwohl ein separater Vergleich von Release-Versionen einen moderaten Gewinn zeigte?