I am trying to use Hikari for Postgres connection. Here is the setting:
config.setMinimumIdle(20);
config.setMaximumPoolSize(100);
However, it only seems to have 2 connections. I got this after ran netstat -ant | grep 5432
tcp4 0 0 127.0.0.1.5432 127.0.0.1.53183 ESTABLISHED
tcp4 0 0 127.0.0.1.53183 127.0.0.1.5432 ESTABLISHED
and also in Postgres console SELECT sum(numbackends) FROM pg_stat_database;
sum
-----
2
(1 row)
I am not sure what's going on and I appreciate your help!
Recommended setup is to not set minimumIdle
This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently. However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize.
Seems HikariCP does not care much about it
If the idle connections dip below this value ... HikariCP will make a best effort to add additional connections
A good test for your value could be to open more than 20 connections and verify they are maintained in the pool during idleTimeout (10 minutes by default). Then the value should be kept at the setting value (20 in this case).
That minimum will be maintained once the number of connections reaches that value
Idle connections will not be retired once the pool reaches minimumIdle connections.
Related
I run a JEE application on Payara 4.1 which uses PostgreSQL 9.5.8. The connection pool is configured in following way.
<jdbc-resource poolName="<poolName>" jndiName="<jndiName>" isConnectionValidationRequired="true"
connectionValidationMethod="table" validationTableName="version()" maxPoolSize="30"
validateAtmostOncePeriodInSeconds="30" statementTimeoutInSeconds="30" isTimerPool="true" steadyPoolSize="5"
idleTimeoutInSeconds="0" connectionCreationRetryAttempts="100000" connectionCreationRetryIntervalInSeconds="30"
maxWaitTimeInMillis="2000">
From what monitors say, the applications needs 1-3 DB connections to postgres when running. Steady pool size is set to 5, max pool size is 30.
I see, that about 4 times a day the application opens all connections to the database hitting the max pool size limit. Some requests to the server fail at this point with exception: java.sql.SQLException: Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.
After some seconds all issues are gone, and the server runs fine till the next hiccup.
I have requested some TCP dumps to be performed to look closely into what happens exactly. I see that:
After 30 connections (sockets) have been opened, most of the connections are rarely used.
After some time (1h or so) the server tries to access some of such pooled connections to realize, that the socket is closed (DB responds immediately with a TCP RST).
As the pooled connections count decreases hitting steady pool size, the connection pool opens 25 connections (sockets) which takes some time (about 0,5 up to 1 second per connection – don’t know why this long, as the TCP handshakes are immediate). At this point some server transactions are failing.
The loop repeats.
This issue is driving me mad. I was wondering, whether I am missing some crucial pool configuration to revalidate the connections more often but could not find anything that would help.
EDIT:
What does not help, as we have tested it already:
Making the pool size bigger (same issues)
Removing idleTimeoutInSeconds="0". We had issues with the connection pool every 10 minutes we did that.
Context
I am running a SpringBoot application on Cloud Run which connects to a postgres11 CloudSQL database using a Hikari connection pool. I am using the smallest PSQL instance (1vcpu/614mb/25connection limit). For the setup, I have followed these resources:
Connecting to Cloud SQL from Cloud Run
Managing database connections
Problem
After deploying the third revision, I get the following error:
FATAL: remaining connection slots are reserved for non-replication superuser connections
What I found out
Default connection pool size is 10, hence why it fails on the third deployment (30 > 25).
When deleting an old revision, active connections shown in the Cloud SQL admin panel drop by 10, and the next deployment succeeds.
Question
It seems, that old Cloud Run revisions are being kept in a "cold" state, maintaining their connection pools. Is there a way to close these connections without deleting the revisions?
In the best practices section it says:
...we recommend that you use a client library that supports connection pools that automatically reconnect broken client connections."
What is the recommended way of managing connection pools in Cloud Run, given that it seems old revisions somehow manage to maintain their connections?
Thanks!
Currently, Cloud Run doesn't provide any guarantees on how long it will remain warm after it's started up. When not in use, the instance is severely throttled by not necessarily shutdown. Thus, you have some revisions that are holding up connections even when not being directed traffic.
Even in this situation, I disagree that with the idea that you should avoid using connection pooling. Connection pooling can lower latency, improve stability, and help put an upper limit on the number of open connections. Alternatively, you can use some of the following configuration options to help keep your pool in check:
minimumIdle - This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently.
maximumPoolSize - This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections.
idleTimeout - This property controls the maximum amount of time that a connection is allowed to sit idle in the pool. This setting only applies when minimumIdle is defined to be less than maximumPoolSize. Idle connections will not be retired once the pool reaches minimumIdle connections.
If you set minimumIdle to 0, your application will still be able to use up to maximumPoolSize connections at once. However, once a connection is idle in the pool for idleTimeout seconds, it will be closed. If you set idleTimeout to something small like 1 minute, it will allow the number of connections your pool is using to scale down to 0 when not in use.
Hope this helps!
The issue here is that the connections don't get closed by HikariCP when they are opened. I don't know much about Hikari but I found this which explains how connections should be handled through Hikari. I hope that helps!
I am using SpringBoot(2.0.4),Hibernate,Postgres and HikariCP(2.7.9)
I want a configuration in which the pooled connections by HikariCP should be released back to DB after certain amount of being Idle.
For example considering the default configuration of HikariCP in SpringBoot, the pool is initialized with 10 DB Connections.
I want that if there is inactivity for suppose 2 hours all the connections should be return back to DB.
If after 2 hours any request for connections comes, the HikariCP should reinitialize the whole pool of 10 connections and serve it.
Is this possible ? Is there any configuration setting for such requirement ?
I would like to know how maxLifetime and idleTimeout settings behave in a fixed-size Hikari pool.
Under which circumstances are connections being retired from a fixed-size pool? And since the pool is fixed-size, is a new connection immediately created after a retirement?
Furthermore, what happens if the database itself (MySQL in my case) closes a connection after the database wait timeout is reached (in case the maxLifetime is not less than the DB timeout)?
Will the connection be retired from the fixed-size pool and another one will be immediately created?
Thanks!
HikariCP is retiring connections when connection reaches its maxLifetime or connection remains idle in pool for idleTimeout.
HikariCP housekeeper runs every 30s by default. to maintain 'minimumIdle' connections, it may add new connections or retire idle connections (not borrowed by client for idleTimeout millis).
you must set maxLifetime few mins less than (mysql)wait_timeout to avoid broken connection / exceptions.
HikariCP may add new connections in housekeeper or when client attempts to borrow connection. so it may not add connections immediately after retiring them.
we are in the process of porting our configuration from Tomcat to WildFly. Within our Tomcat connection pool configuration we are using maxIdle and minIdle properties, which as the doc say:
maxIdle (int) The maximum number of connections that should be kept
in the pool at all times. Default value is maxActive:100 Idle
connections are checked periodically (if enabled) and connections that
been idle for longer than minEvictableIdleTimeMillis will be released.
(also see testWhileIdle)
minIdle (int) The minimum number of established connections that
should be kept in the pool at all times.
Looking at JBoss/WildFly docs, the only available parameter is idle-timeout-minutes, which refers anyway to a single connection idle time:
The maximum time, in minutes, before an idle
connection is closed. A value of 0 disables timeout. Defaults to 15
minutes.
Is there a workaround to mimic the same configuration also on JBoss/WildFly ?
Thanks!
Tomcat uses both a minIdle and maxIdle parameter to determine respectively the minimum and maximum of idle connections that should be kept in the pool. While the minIdle parameter, can be turned to be WildFly min-pool-size, on the other hand, the maxIdle parameter has not corresponding match on WildFly. The closest match is the idle-timeout-minutes, which is the number of minutes after which unused connections are closed (default 15 minutes). You can actually vary this parameter let’s say to 10 minutes as follows:
/subsystem=datasources/data-source=ExampleDS/:write-attribute(name=idle-timeout-minutes,value=10)
Source: From Tomcat to WildFly in one day