POOLMAX mit 5.1R5 bzw. 5.2
Author: matthiasforberg
Publication Date: 12/8/2015 9:43
Hallo,
bei einem Kunden bereiten wir gerade die Migration auf 5.2 vor. Dazu haben wir die etwas ältere 5.1 im ersten Schritt auf die letzte 5.1R5 gehoben. An sich kein Thema, aber jetzt ist es doch zu Fehlern gekommen, da offenbar das Verhalten der POOLMAX Einstellung in den JDBC-Konfigurationen geändert wurde. Das führt auch leider zu einem 5s Timeout bei jedem Verbindungsversuch mit der DB, so dass eine bislang zehnsekündige Vollgenerierung plötzlich 16h dauern soll...
Wir haben zunächst den empfohlenen Wert POOLMIN+4 eingestellt, also 1 und 5 für min und max. Das reichte aber nicht aus, dann wurden für min und max 5 und 10 probiert, inszwischen 10 und 20 - ein heiteres Einstellungsraten... :smileyangry:
Gibt es hier Richtlinien, welche Werte wann eingestellt werden sollen? Ist z.B. die Anzahl der Redakteure/Entwickler einzubeziehen oder die Anzahl der Aufträge etc. (Datenschema gibt es nur ein einziges je Projekt)?
Was sagt die Spanne zwischen min und max aus? Welche Auswirkungen (z.B. DB-Performance, Speicher) hat es, wenn wir die noch größer wählen?
Grüße
Matthias
Tags: database, datenbank, datenquelle, fs5.1, generation, generierung, jdbc
-
Author: m_haberkorn - 12/8/2015 14:44
Hallo,
eine Ergänzung zu den Problemen. Es geht hier um die Anbindung von Oracle 11g Datenbanken.
Viele Grüße
Markus
0 -
Author: kscheuing - 12/9/2015 18:48
Wie hatten ein ähnliches Verhalten mit 5.1R5 ...
Unser Poolmax steht inzwischen bei 20. Ich glaube wir haben das Datenbankseitig in den Griff bekommen, indem wir die anzahl der paralellen Processes abgestimmt hatten. Bin mir aber nich 100% sicher..
Ich werd morgen nochmal schauen. Vielleicht hilfts ja.
Gruß, Kai
0 -
Author: m_haberkorn - 12/10/2015 17:46
Hallo,
nach einigem Probieren haben wir herausgefunden, daß mit R5 die bestehenden DB-Verbindungen anscheinend nicht sauber wiederbenutzt werden. Stattdessen werden immer wieder neue DB-Verbindungen aufgemacht. Und das Verhalten durchbricht dann wohl den Wert von POOLMAX.
Wenn man die Timeouts aber reduziert, dann können bestehende, eigentlich noch gültige Verbindungen aber geschlossen werden. Und damit wird die Anzahl der maximalen DB-Verbindungen nicht zum Blocker.
Viele Grüße
Markus
0 -
Author: m_haberkorn - 1/20/2016 12:47
Hallo,
es gibt anscheinend einen Fehler in 5.1R5 mit den Datenbakverbindungen.
e-spirit hatte von uns aussagekräftige Logs bekommen....
Viele Grüße
Markus
0 -
Author: hjaeger - 6/23/2017 10:35
TLDR: Wer mit einem Update von <5.1R5 auf >5.1R5 im Redaktionsbetrieb DB-Layer-Probleme kriegt, muss den Connectionpool aggresiver timeouten und ggf. auf 5.2.905 updaten.
---------------------
Hallo zusammen.Wir sind bei einer 5.0 --> 5.2.R6 Umstellung in Kombination mit einer per JDBC angebundenen DB2 in exakt dieses Problem gelaufen.
Sollte es noch jemanden geben, der/die eine Migration mit Sprung über die 5.1R5 plant, dem sei gesagt, das das letzte Update für die 5.2R6 vom 31. Mai genau dieses connection pool reuse Problem "optimiert".
Ich würde mir bei solchen ja durchaus gut abgehangenen Problemen (Anfang 2016) eine proaktivere Kommunikation in Migrationsleitfäden/Blogposts/etc. seitens des Herstellers wünschen.
Sicherlich lässt sich die Symptomatik auch mit aggressiveren Timeouts und größeren Connectionpools kaschieren, aber auch diese Information findet sich nur über Umwege.
Der besagte Patch auf die 905 hat das Problem ohne Modifikation der JDBC-Konfiguration behoben.
0 -
Author: hjaeger - 6/23/2017 11:48
Und auch die Version 905 lindert das Problem nur begrenzt....
de.espirit.or.ORException: no free connection in pool (jdbc.POOLMAX=10)
Offensichtlich ist zusätzlich eine Anpassung der DB-Konfiguration notwendig
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
6 commentaires