Connection limit for SQLDB with small_plan (Bluemix) - ibm-cloud

What is the concurrent connection limit for SQLDB Small plan? We have a liberty application bounded to a SQLDB service with Small plan and got the following error. DB2 SQL Error: SQLCODE=-4712

The Free Beta plan features 100MB per instance and 10 concurrent connections.
The Small plan features 10GB max per instance and 20 concurrent connections.
The Premium plan features 500GB max storage per instance and 100 concurrent connections.
See the link below for more information:
https://console.ng.bluemix.net/?ace_base=true/#/store/cloudOEPaneId=store&serviceOfferingGuid=0d5a104d-d700-4315-9b7c-8f84a9c85ae3&fromCatalog=true
If you think you're close to exhausting your connections, you should use the Monitoring and Analytics Service to monitor connection pools:
https://www.ng.bluemix.net/docs/#services/monana/index.html#gettingstartedtemplate

Related

Mongodb connection pools with cross region replicas

We have a cluster hosted on Mongo Atlas (M50, AWS) with cross region replicas in 5 other regions. This allows my application servers in those regions to read from a local replica using readPreference=nearest which is much faster.
The M50 instance size has a maximum of 16000 connections.
The issue I face is that the connection pool creates a connection to each node in the cluster. With 5 other regions, each having 10 application servers and each server having an application pool of 100 (as is default), that's 5000 connections to every single node when they will only ever read from the replica in the local region. These connections take away from the connections available to application server in the the primary region which is doing all the writes (5000k writes per second). The primary region has 20 application servers. These serves are set to have a minimum of 500 connections each which creates a minimum of 10000 connections. That's a total of 15000 connections.
This creates a problem as we sometimes run out of connections when traffic spikes as those pools increase in size to cope with the additional load. The minimum pool size is required to ensure the application remains responsive when the traffic spikes (if we don't do this we see a lot of MongoWaitQueueFullExceptions and unacceptably high response times). We could set the maximum pool size but this limits throughput and we see timeouts.
Is there any way that the application pools in the replica regions can be prevented from creating connections to every single node in the cluster?
We don't want to increase the instance size as it doubles the cost of the cluster.
The application is written in .NET 6 (minimal API) with MongoDB driver version 2.16.

1 million concurrent database connections

In https://cloud.google.com/sql/docs/quotas, it mentioned that "Cloud Run services are limited to 100 connections to a Cloud SQL database.". Assume I deploy my service as Cloud Run, what's the right way to handle 1 million concurrent connections? Can cloud spanner enables this - I can't find documentation discussing maximum concurrent connections on cloud spanner maximum concurrent connection with Cloud Run.
Do you want Cloud Run to handle a million concurrent connections, or do you want Cloud SQL to handle a million concurrent connections?
If you want Cloud SQL to handle a million concurrent connections, you are probably wrong. Check out this article about Pool sizing (it's on a Java repo, but is general enough to apply to all connection pooling). If you are at the point where you need a million concurrent connections, you would need to invest in more advanced architectures (such as sharding).

create a connection pool for many DBs on the same DB server (Spring Boot)

I'm looking for a way to create a connection pool for many DBs on the same DB server (PostgreSQL Aurora).
This means that I need the ability of changing the target DB of a connection at run time.
Currently I'm using HikariCP for connection pooling, in a stack of Spring Boot and JHispter.
Background:
we need to deploy a multi-tenancy micro-service system with a single DB server (to be specific, a single AWS Aurora PostgreSQL instance)
our solution of multi-tenancy is that each tenant has a DB, in that DB we have many schema for each service. All the DBs are in the same AWS Aurora instance.
Our problem:
with this deployment, we have a connection pool for each (tenant x micro-service instance).
This leads to a huge number of connections.
Ie: with the pool size of 50 connections/pool. We need: 500 tenants x 20 micro-service instances x 50 connections/pool = 500000 connections.
The maximum connections allowed on any Aurora DB is 16000, and actually by default the "max_connections" parameter is typically set to something lower.
So now I'm looking for a way to make our pooling scope larger, so that many tenants can share the same pool. Since we use only 1 Aurora server instance, I think it's possible to create a connection pool that can be shared between many tenants.
Is there any way to have a connection pool that can switch the DB at run time?
Unless Aurora has done some customization on this, you cannot change the database of a connection once it is established in PostgreSQL. You can still use a pooler, but it will effectively be a separate pool for each database. This is pretty fundamental, there is nothing you can do about it.

Number of concurrent database connections

We are using amazon r3.8xlarge postgres RDS for our production server.I checked the max connections limit of the RDS, it happens to be 8192 max connections limit.
I have a service which is deployed in ECS and each ECS tasks can take one database connection.The tasks go up to 2000 during peak load.That means we will have 2000 concurrent connections to the database.
I want to check whether it is ok to have 2000 concurrent connections to database.secondly, Will it impact the performance of amazon postgres RDS.
Having 2000 connection at time should not cause any performance issue, since AWS manages the performance part. There are many DB load testing tools available, if you want to be at most sure about this.

Idle (not idle in transaction) connections are not released/closed in PostgreSQL AWS RDS

I'm using C3P0 connection pool and PostgreSQL(10.3) in AWS RDS.
I did a load test at low TPS (1 TPS) for 2 minutes, after load test finished, the number of connections were not dropped according to the monitoring board in AWS RDS. (See below). Neither did CPU utilization.
I'm still new to database, not sure if this is expected? This seems like it's reaching RDS instance's max_connection. I did a select from pg_stat_activity, 99% of connections are idle, and most of the queries are SHOW TRANSACTION ISOLATION LEVEL and SELECT 1.
Here's my C3P0 config:
maxConnection: 100
initialPoolSize: 1
minPoolSize: 1
acquireIncrement: 1
idleConnectionTestPeriod: 40
maxIdleTime: 20
maxConnectionAge: 30
maxStatements:0
numHelperThread:5
preferredTestQuery: SELECT 1
propertyCycle: 0
testConnectionOnCheckIn: false
testConnectionOnCheckOut: false
debugUnreturnedConnectionStacktraces: false
unreturnedConnectionTimeout: 60
acquireRetryAttempts: 10
acquireRetryDelay: 1000
checkoutTimeout: 10000
Any help will be appreciated! Thanks in advance!
Load test tool: It's a company internal load test tool. Generally speaking, it's creating loads to the service (5+ hosts) to hit my API, the API talks to connection pool to connectionPool.getDataSource().getConnection()(ComboPooledDataSource). The connection pool is a singleton instance among service, while each call to the API is in its own thread.