Questions & Answers

matthiasforberg
Occasional Collector

POOLMAX mit 5.1R5 bzw. 5.2

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

6 Replies
m_haberkorn
I'm new here

Hallo,

eine Ergรคnzung zu den Problemen. Es geht hier um die Anbindung von Oracle 11g Datenbanken.

Viele GrรผรŸe

Markus

0 Kudos
kscheuing
I'm new here

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

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 Kudos

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

hjaeger
Elite Observer

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 Kudos

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 Kudos

Type a product name