Die Symptome

Kürzlich trat in einem TYPO3-Kundenprojekt das Verhalten auf, dass mit jedem Aufruf der Webseite die Prozessotlast auf dem Server ständig anwuchs und so den Server lahm legt. Dies führte dazu, dass weder das TYPO3-Backend noch die Webseite in kürzester Zeit erreichbar waren.

Apache und MySQL – Einstellungen beheben nicht das Problem

Versuche Einstellungen und Limits im Apache-Webserver und der MySQL-Datenbank vorzunehmen, um so den Server zu reglementieren schlugen fehl.
Schaut man in die Log-Files, so war folgendes zu erkennen:

Weitere Varianten an Fehlermeldungen waren:

• mod_fcgid: process XXX graceful kill fail, sending sigkill
• mod_fcgid: read data timeout in 120 seconds
• mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
• mod_fcgid: ap_pass_brigade failed in handle_request_ipc function

Dies ließ darauf schließen, dass es Problem mit dem Webserver oder im Speziellen mit dem mod_fcgi Modul gibt.
Dem widerspricht aber, dass sämtliche Optimierungen des Webserver zu keinen Ergebnissen führt.

Schaut man sich dann die Datenbankprozesse /-zugriffe an, so war zu erkennen, dass TYPO3-SQL-Abfragen auf die RealUrl-Tabellen ewig lange dauern.
Dies hat zur Folge, dass der Webserver mit jedem Zugriff auf der Webseite die SQL-Abfragen ausführt, aber nicht beendet und somit die Prozessorlast bis zum Ausfall des Servers steigt.
Bei uns lagen die Tasks schnell bei über 500.

Zugriffe auf TYPO3 Datenbank Tabelle „tx_realurl_urlcache“ dauern ewig

Konkret war diese eine Tabelle das Problem: „tx_realurl_urlcache“

Diese Tabelle stammt von dem in der TYPO3-Welt sehr weit verbreiteten Plug-In RealUrl, welches dafür sorgt, dass TYPO3 mit die einzelnen Seiten mit suchmaschinenfreundlichen Adressen ausliefert. Ein kurzes Abstellen dieses Plug-In im Backend zeigte dann die Wirkung. Zwar wurden die Seiten mit den üblichen /index.php?id=xxx im Browser ausgeliefert, die Serverlast konnte abrupt auf ein Minimum wieder herunter gefahren werden (natürlich mussten die evtl. noch vorhanden SQl Abfragen im Hintergrund noch gekillt werden)

Die Wartung von Datenbank Tabellen im TYPO3

Mit OPTIMIZE TABLE wurden sämtliche Tabellen der TYPO3-Datenbank repariert, da in unserem Fall von einer beschädigten Datenbank auszugehen war, die durch einen Stromausfall beim Kunden (Standort des Servers) entstanden sein könnte.
Weiter wurde im speziellen ein Augenmerk auf die RealUrl Tabellen

• tx_realurl_pathcache
• tx_realurl_uniqalias
• tx_realurl_uniqalias_cache_map
• tx_realurl_urlcache

gelegt.

Gerade die letztere ist im Laufe der Lifetime der Webseite gigantisch angewachsen:

Abschließend wurden diese Tabellen geleert und das Plug-In wieder im TYPO3 Backend aktiviert.

Die Kombination aus Optimierung der Datenbank und möglicherweise Bereinigung von extrem vielen Daten in der „tx_realurl_urlcache“ – Tabelle führen dazu, dass der Server wieder im Normalbetrieb läuft.

Im konkreten Fall waren diese Versionen im Einsatz

• TYPO3 6.2.27
• realurl 2.0.15
• MySQL 5.5.57
• Apache 2.4.7
• Ubuntu 14

Die Internetagentur VCAT Consulting aus Potsdam entwickelt Webportale auf Basis von TYPO3, WordPress, Drupal und bietet darüber Individualprogrammierung unter zur Hilfenahme von Symfony an. In diesem konkreten Beispiel profitierte der Potsdamer Kunde von unseren speziellen TYPO3-Wartungspaketen.