Jira verwendet Datenbankverbindungs-Pooling, um den Jira-Zugriff auf die darunterliegende Datenbank zu verwalten. In früheren Jira-Versionen wurde dieser Datenbankverbindungs-Pool ausschließlich mit Apache Tomcat verwaltet. Seit Jira 4.4 bietet Jiras dbconfig.xml-Datei jedoch eine Reihe von Datenbankverbindungs-Pool-Einstellungen zu Tomcat, durch die Tomcat wiederum Jiras Datenbankverbindungs-Pool handhabt.
Seit Jira 5.1 ist die Anzahl der Einstellungsmöglichkeiten für den Datenbankverbindungs-Pool deutlich gestiegen, die Jiras dbconfig.xml-Datei für Tomcat zur Verfügung stellt.
Der Reiter Advanced in der Jira-Konfiguration erleichtert sowohl die Konfiguration als auch die Verwaltung des Datenbankverbindungs-Pools. Die Seite Database Monitoring (die für Jira-Systemadministratoren zugänglich ist) bietet ein visuelles Werkzeug, um die Nutzung der Datenbankverbindungen zu überwachen. Die auf dieser Seite zusammengestellten Informationen können Ihnen dabei helfen, den Jira-Datenbankverbindungs-Pool über die Jira Konfigurationswerkzeuge zu optimieren.
Die Architektur des Datenbankverbindungs-Pools
Jedes Mal, wenn Jira auf eine Datenbank zugreift (in der Regel um zu lesen oder zu schreiben), wird eine Datenbankverbindung benötigt.
Eine Datenbankverbindung ist ein großes und komplexes Objekt, das sämtliche Kommunikationen zwischen Jira und seiner Datenbank bewältigt. Daher benötigt die Etablierung einer Datenbankverbindung viel Zeit und nimmt einen maßgeblichen Teil des Speichers des Clients (der Jira-Applikation) und des Datenbank-Servers in Anspruch.
Um zu vermeiden, dass jeder von Jira angefragte Datenbankzugriff eine neue Datenbankverbindung aufbaut, wird ein Pool an voreingestellten Datenbankverbindungen gepflegt. Sobald ein neuer Zugriff auf die Datenbank angefragt wird, nutzt Jira eine Verbindung aus diesem voreingestellten Verbindungs-Pool. Daher gilt:
Wenn Jira in Betrieb genommen wird, ist ein Minimum an Datenbankverbindungen zwischen Jira und den Datenbanken etabliert.
Dieses Set an Datenbankverbindungen stellt den Jira-Datenbankverbindungs-Pool dar.
- Sobald Jira einen Zugriff (beispielsweise zum Lesen oder Schreiben) auf die Datenbanken benötigt,
a. fragt Jira eine Datenbankverbindung aus dem Pool an
b. nutzt Jira die Datenbankverbindung, um aus den Datenbanken zu lesen und/oder zu schreiben
c. gibt Jira die Datenbankverbindung nach Beendigung des Zugriffs in den Pool zurück.
Falls die Zugriffsrate auf die Jira-Datenbanken die Anzahl an verfügbaren Datenbankverbindungen aus dem Pool übersteigt, kann Tomcat automatisch weitere Verbindungen generieren, um die Belastung zu bewältigen. Umgekehrt kann Tomcat Verbindungen schließen, um dem System Ressourcen zurückzugeben, die momentan nicht benötigt werden, wenn die Datenbankzugriffsrate unter die Anzahl der zur Verfügung stehenden Datenbankverbindungen sinkt.
Moderne Datenbanken können mit einer großen Anzahl an Verbindungen relativ leicht umgehen und mit ausreichend Speicherplatz mehrere Hundert Verbindungen bewältigen. Doch auf der Client-Seite verbrauchen diese Verbindungen viel Speicher. Generell ist es daher vorteilhaft, die Verbindungen auf eine kleinere Anzahl zu begrenzen. Dabei sollten jedoch genügend Verbindungen für die Applikation bereitstehen, sodass keine Wartezeit entsteht, wenn eine Verbindung benötigt wird.
Jiras Datenbankverbindungen tunen
- Fahren Sie die Jira-Instanz herunter.
- Führen Sie folgenden Schritte durch:
- Wenn Sie eine 'Recommended' Distribution von Jira nutzen, nutzen Sie das Konfigurations-Tool von Jira, um die Datenbankverbindungen zu tunen:
- Starten des Jira-Konfigurations-Tools:
- Windows:
Öffnen Sie eine Eingabeaufforderung und führen Sie config.bat im bin-Unterverzeichnis des Jira-Installationsverzeichnisses aus. - Linux/Unix
Öffnen Sie eine Konsole und führen Sie config.sh im bin-Untervrerzeichnis des Jira-Installationsverzeichnisses aus. - Hinweis: Es kann nötig sein, eine JAVA_HOME-Umgebungsvariable zu setzen, um das Jira-Konfigurations-Tool zu starten. Siehe hierzu: Installing Java.
- Windows:
- Wenn das Jira-Konfigurations-Tool läuft, klicken Sie auf das Advanced-Tab.
- Nutzen Sie die Informationen unten unter “Verbindungs-Pool-Einstellungen”, um Jiras Datenbankverbindung feinzutunen. Um einen Wert für eine dieser Optionen zu spezifizieren, stellen Sie sicher, dass Checkbox ganz links zuerst aktiviert wird.
- Klicken Sie auf Save, um die Änderungen in der Datei dbconfig.xml zu sichern.
- Alternative: Editieren Sie die Datei dbconfig.xml im Jira-Home-Verzeichnis.
- Nutzen Sie die Informationen unten unter “Verbindungs-Pool-Einstellungen”, um der Datei dbconfig.xml Elemente hinzuzufügen und die Datenbankverbindung feinzutunen.
- Speichern Sie die editierte Datei dbconfig.xml.
- Starten Sie Jira neu.
Verbindungs-Pool-Einstellungen
Option unter | Element in der | Beschreibung | Empfehlung | Von Jira voreingestellt* |
|---|---|---|---|---|
Maximum Size | pool-max-size | Die maximale Anzahl an Dankenbankverbindungen, die Tomcat gleichzeitig öffnen kann. | Die Anzahl sollte groß genug sein, dass die Applikation nicht auf eine frei werdende Verbindung warten muss, sobald sie benötigt wird. | 20 |
Maximum Idle | pool-max-idle | Die maximale Anzahl an Verbindungen, die sich ungenutzt im Pool befinden können. | Die Spezifizierung einer negativen Zahl setzt kein Limit für Datenbankverbindungen, die ungenutzt bleiben können. | Wert wie bei Maximum Size |
Minimum Idle/Size | pool-min-size | Die minimale Anzahl an ungenutzten Datenbankverbindungen, die Tomcat permanent geöffnet hält. | Entspricht der Wert dem unter Maximum Size (oben), was per Voreinstellung der Fall ist, hat der Pool eine feste Anzahl an Verbindungen und werden ungenutzte Verbindungen niemals geschlossen. | Wert wie bei Maximum Size |
Initial Size | pool-initial-size | Die initiale Anzahl an Datenbankverbindungen, die Tomcat im Pool öffnet | Diese Einstellung wird normalerweise nicht konfiguriert, da Tomcat schnell Datenbankverbindungen aufbaut, wenn Jira startet. | 0 |
Maximum Wait Time | pool-max-wait | Die Zeitspanne in Millisekunden, die der Pool der Applikation erlaubt auf eine Verbindung zu warten, wenn keine freien Verbindungen zu Verfügung stehen, bevor ein Fehler gemeldet wird. | Ein Wert von -1 bedeutet, dass Tomcat unbegrenzt wartet. | 30.000 |
Erweiterte Einstellungen (Generell ist es nicht erforderlich, die folgenden Einstellungen zu ändern. Ziehen Sie für weitere Informationen ggf. die Apache DBCP Dokumentation heran.)
Pool Statements | pool-prepared-statements | Aktivierung des Poolings für sog. Prepared Statements für den Datenbankverbindungs-Pool | Prepared Statements erlauben die Pre-Compilierung häufig genutzter SQL-Anweisungen. Das kann die Performance dramatisch verbessern. | false |
Maximum Open Statements | max-open-prepared-statements | Die maximale Anzahl offener Statements, die der Statement-Pool gleichzeitig zuweisen kann | Null für unlimitiert | unlimited |
Validation Query | validation-query | Die SQL-Anfrage, die zum Validieren von Verbindungen aus diesem Pool genutzt wird. Sofern spezifiziert, muss diese Anfrage ein SQL-SELECT-Statement sein, das zumindest eine Zeile returniert. | In der Regel wie folgt genutzt:
| SELECT 1 |
Validation Query Timeout | validation-query-timeout | Wie lange das System auf den Erfolg einer Validierungsanfrage warten sollte, ehe es die Verbindung als unterbrochen ausweist | Das sollte kurz sein, da die Validierungsanfrage so designt werden sollte, dass sie ein Minimum an Arbeitsaufwand durchführt. | 3 |
Test On Borrow | pool-test-on-borrow | Testet die Validität der Verbindung, wenn die Anwendung sie sich aus dem Pool leiht. Ist die Verbindung unterbrochen, wird sie aus dem Pool entfernt. | Sollte für Jira immer auf false eingestellt sein, da Jira sich für jede Datenbankoperation eine Verbindung borgt. | false |
Test On Return | pool-test-on-return | Testet die Validität der Verbindung, wenn die Anwendung sie zurück in den Pool gibt. Ist die Verbindung unterbrochen, wird sie aus dem Pool entfernt. | Sollte für Jira immer auf false eingestellt sein, da Jira sich für jede Datenbankoperation eine Verbindung borgt. | false |
Test While Idle | pool-test-while-idle | Testet die Validität der Verbindung periodisch, während sie ungenutzt ist. Ist die Verbindung unterbrochen, wird sie aus dem Pool entfernt. | Sollte MySQL auf true eingestellt sein. (MySQL schließt Verbindungen am Ende des Datenbank-Servers, wenn sie für längere Zeit nicht genutzt werden. Das kann ein Thema werden, wenn Jira-Instanzen über längere Zeiträume nicht genutzt werden, etwa über Nacht.) | false |
Time Between Eviction Runs | time-between-eviction-runs-millis | Die Anzahl der Millisekunden "in Schlaf" zwischen dem Ausführen des Eviction Threads des ungenutzten Objekts. Falls nicht positiv, wird kein Eviction Thread ausgeführt. Der Eviction Thread entfernt ungenutzte Verbindungen, wenn ihre Zahl pool-min-size übersteigt. | Hier sollte für MySQL ein positiver und etwas höherer Wert gesetzt werden. Sinnvoll ist 300.000 (fünf Minuten). | 300.000 für MySQL |
Minimum Evictable Idle Time | min-evictable-idle-time-millis | Der Minimalzeitraum, den ein Objekt ungenutzt im Pool sein kann, ehe es für die Eviction infrage kommt. |
| 60.000 für MySQL |
Remove Abandoned | pool-remove-abandoned | Entfernt sog. Abandoned Connections, wenn der removeAbandonedTimout überschritten wird. | Sollte auf true gestellt sein. Dies erlaubt dem Pool, Abandoned Connections zu identifizieren und Effekte auf die System-Performance zu vermeiden. | true |
Remove Abandoned Timeout | pool-remove-abandoned-timeout | Wie lange eine Verbindung ungenutzt sein kann, ehe sie als "abandoned" eingestuft wird (in Sekunden) |
| 300 |
Überwachung des Verbindungs-Pools
Jira bietet eine Ansicht, mit der System-Administratoren Statistiken zum Verbindungs-Pool einsehen können. Gehen Sie dazu in das Menü Administration/Plugins/Database Monitoring. Ihnen werden dann beispielsweise Grafiken wie die folgenden angezeigt:
Die obere Grafik verbildlicht die Aktivitäten des Verbindungs-Pools in den letzten sechs Stunden. Sie zeigt die Anzahl der aktiven und der ungenutzen Verbindungen ebenso an wie das Minimum und das Maximum innerhalb dieser Zeitspanne. Die Einheit der y-Achse entspricht der maximalen Anzahl an Verbindungen. Die Angaben sind gemittelte Durchschnittswerte über Zeitspannen von fünf Minuten.
Falls sich die Anzahl der aktiven Verbindungen konstant oder häufig am Maximum der verfügbaren Verbindungen befindet, ist es sinnvoll, die Anzahl der maximal verfügbaren Verbindungen im Pool zu erhöhen.
Wenn die Anzahl der aktiven Verbindungen hingegen deutlich niedriger ist als das Maximum an verfügbaren Verbindungen, ist es sinnvoll, die Anzahl der maximal verfügbaren Verbindungen im Pool zu verringern. Denken Sie aber daran, dass es besser ist, ein paar Verbindungen extra zu haben, die nicht genutzt werden, als wenn Sie zu wenige Verbindungen haben, wenn sie gebraucht werden.