Hikari Pool Connection Validation

Diskutiere Hikari Pool Connection Validation im Datenbankprogrammierung Bereich.
NicoDeluxe

NicoDeluxe

Hallo zusammen,

ich habe einen Connection Pool wie unten, allerdings bekomme ich ständig folgende Fehlermeldungen und die Verbindungen sind geschlossen. Hat jemand ne Idee?

No operations allowed after statement closed.
Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@20221c8d (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.

Code:
HikariConfig config = new HikariConfig();
                    config.setJdbcUrl(tenantProperties.getProperty("datasource.url") + "&serverTimezone=" + TimeZone.getDefault().getID());
                    config.setUsername(tenantProperties.getProperty("datasource.username"));
                    config.setPassword(tenantProperties.getProperty("datasource.password"));
                    config.setPoolName(tenantId);
                    config.setMaximumPoolSize(5);
                    HikariDataSource ds = new HikariDataSource(config);
                    ds.setIdleTimeout(600000);
Hab schon maxLifeTime gesetzt auf verschiedene Werte, aber bringt nix. Meine DB hat standard 28800s wait_timeout hat das damit irgendwas zu tun?

Hier in der Methode kommt der Fehler (Hibernate kümmert sich ums das Schließen der Verbidnungen bzs zurückgeben in den Pool mit Spring boot)

Code:
private void doWork(){}
Session hibernateSession = em.unwrap(Session.class);
            hibernateSession.doWork(new org.hibernate.jdbc.Work() {
                @Override
                public void execute(Connection connection) {
                //do da work Prepeared Statement
                }
}
 
NicoDeluxe

NicoDeluxe

Danke, aber was ist der HA Proxy Timeout? In Mysql sehe ich massig logs "is marked as crashed and should be repaired" aber die sind ok, Tabellen kann ich aufrufen
 
mihe7

mihe7

Wenn ich es richtig verstehe, dann muss der Werte von wait_timeout (SHOW VARIABLES like '%timeout%') gleich oder sogar etwas größer sein als maxLifeTime. Oder irgendwas anderes schließt die Connection, z. B. im Code.
 
NicoDeluxe

NicoDeluxe

Der RAM ist scheinbar nicht ausreichend :( Zu viele Connections im Pool. MaxLifetime setz ich mal auf 10% unter wait_timeout
 
L

LimDul

Ich bin gerade verwirrt - ist der Sinn eines Pools, dass ich nicht eben für jeden User X-Connections vorhalte sondern einen globalen Pool?
 
NicoDeluxe

NicoDeluxe

Es gibt mehrere Pools, pro Tenant 1 pool. Man könnte vielleicht auch einen Pool mit allen Verbindungen machen
Hab jetzt auf 2 Verbindungen reduziert, hoffe dass es reicht. Keine Möglichkeit RAM zu erhöhen die Tage :/
 
NicoDeluxe

NicoDeluxe

Die Tenants in der gleichen DB wie meinst du das? Jeder Tenant hat eine eigene DB auf einem großen Server, vielleicht 100 tenants derzeit

Jetzt viel mir auf, dass der RAM wächst, unser Programm macht stündlich was auf die Datenbanken und jedesmal wächst der RAM des DB Servers um 200BM anstatt nach dem Abarbeiten der Queries wieder weniger zu werden.
 
mihe7

mihe7

Jeder Tenant hat eine eigene DB auf einem großen Server, vielleicht 100 tenants derzeit
Das wären also etwa 200 Connections. Die sollten IMO nicht das Problem darstellen.

Jetzt viel mir auf, dass der RAM wächst, unser Programm macht stündlich was auf die Datenbanken und jedesmal wächst der RAM des DB Servers um 200BM anstatt nach dem Abarbeiten der Queries wieder weniger zu werden.
https://blog.pythian.com/mysql-memory-consumption/ enthält interessante Infos zum Speicherverbrauch.
 
NicoDeluxe

NicoDeluxe

Die Mysql Variablen sind alle default :/ Das ist echt merkürdig, nicht mal der neustart des angebundenen Service macht den RAM auf dem DB Server frei. Also muss mysql da iwas speicehrn. Das geht so lange gut bis er voll ist und die Connections schließt.

Muss ich vielleicht in meiner og Methode irgendwas schließen? Laut einiger Beiträge darf die connection nicht geschlossen werden. Wenn ich das Prepeared Stement schließe kommt auch wieder irgendeine Fehlermeldung.
 
mihe7

mihe7

Laut einiger Beiträge darf die connection nicht geschlossen werden.
Die Connection muss vom Connection Pool geschlossen werden - dafür ist er ja da. Es ist auch normal, dass die DB Speicher frisst - das soll so sein, denn alles, was im Speicher liegt, kann ohne I/O in die Peripherie beantwortet werden. Nur sollte es natürlich nicht zu viel werden. Was allerdings interessant ist: dass das Speicher beim Schließen der Connection freigegeben wird. Das hört sich nach verbindungsbezogenen Daten an. Gem. der Formel aus dem Blog würde ich mir read_buffer_size, join_buffer_size, read_rnd_buffer_size, thread_stack und max_packet_size ansehen.
 
NicoDeluxe

NicoDeluxe

Danke, ich kann damit leider nicht so viel anfangen. Meiner Meinigung nach sind das alles Standardwerte (die vielleicht nicht immer gut sind)

Folgende Werte sind gemäß Konsole gesetzt:
read_buffer_size=131072
join_buffer_size =262144
read_rnd_buffer_size = 262144
thread_stack = 299008
max_packet_size EMTPY SET
 
NicoDeluxe

NicoDeluxe

Also es scheint so, dass ein bestimmter Service Schuld ist. Der ballert einfach verdammt viel Daten an die DB. Was aber komisch ist, dass die DB den RAM nicht freigibt sondern einfach iwann die Connections killed.
 
L

LimDul

Mal ganz doof gefragt - diese verdammt viele Daten, ist das eine Transaktion oder mehrere? Weil wenn das eine Transaktion ist, kann ich mir vorstellen, dass die eher im RAM gehalten wird, als wenn es mehrere sind.
 
Thema: 

Hikari Pool Connection Validation

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben