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:

  1. 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.

  2. 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.
    • 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
dem Advanced-Tab
im Konfigurations-Tool

Element in der
Datei dbconfig.xml

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.

Informieren Sie sich weiter unten über "Überwachungen", um zu erfahren, wie sie diesen Parameter am besten einstellen

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.
Wenn die Werte unter Minimum Idle/Size (unten) und Maximum Size (oben) übereinstimmen (Voreinstellung), hat diese Einstellung keinen Effekt.

Wert wie bei Maximum Size

Minimum Idle/Size

pool-min-size
(min-idle)

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.
In sehr großen Jira-Installationen kann es sinnvoll sein, einen niedrigeren Wert als bei Maximum Size zu wählen, um Ressourcen zu sparen.

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.
"-1" bedeutet, dass unendlich lange Wartezeiten genehmigt werden.

Ein Wert von -1 bedeutet, dass Tomcat unbegrenzt wartet.
Sie sollten eine Zeitspanne definieren, die auch im Falle von sog. Contention Spikes ausreicht. Sie sollte aber auch so kurz sein, dass User eine sinnvolle Fehlermeldung statt keiner Antwort oder eines Browser-Time-outs erhalten

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 FROM DUAL" (Oracle) oder
  • "SELECT 1" (MySQL)

SELECT 1
(für MySQL)

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
(für MySQL)

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
true für MySQL

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.
Wenn ein interner Fehler auftritt, ist es möglich, dass die Anwendung sich eine Verbindung leiht und sie nicht mehr zurückgibt. Wenn das zu oft geschieht, werden die Verbindungen im Pool knapp mit der Folge von Performance-Problemen oder Anwendungsausfällen.

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.

Dieser Inhalt wurde zuletzt am 14.09.2017 aktualisiert.

Der Inhalt auf dieser Seite ist schon seit einer Weile nicht mehr aktualisiert worden. Das muss kein Nachteil sein. Oft überdauern unsere Seiten Jahre, ohne wirklich unnütz zu werden.

Alte Inhalte können falsch, irreführend oder überholt sein. Bitte nutzen Sie das Formular oder den Live-Chat auf dieser Seite oder kontaktieren Sie uns via E-Mail unter content@seibert.group, wenn Sie Zweifel, Fragen, Anregungen oder Änderungswünsche haben.