How to tune the database pool in BitBucket Server

[Laurent Denanot]

Hi,

With reference to this question: https://answers.atlassian.com/questions/156264

As far as I can tell from the following page, the properties for setting up  the database pool have changed:

https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html#BitbucketServerconfigproperties-Databasepool

Can you confirm the former properties in Stash 2.x (db.pool.partition.*) no longer apply, and can you please tell me whether there are still 4 different pools ?

From the documentation it seems the pool implementation has changed (now using  HikariPool instead of BoneCP) and there is now a single pool.

However I still see a default pool size (db.pool.size.max) of 80, which seems rather large.

What would be a more reasonable setting for a user base of say, 30 users?

What is the absolute minimum number of connections Bitbucket needs for its own internal use?

Thanks in advance,

Regards,

Laurent

[Bryan Turner]

Laurent,

The old properties, like db.pool.partition.*, are for BoneCP, and will not work with HikariCP.

That said, with Bitbucket Server there should be no need to explicitly configure connections. Starting with 4.0, there is no longer a minimum number the server keeps open (the minimum was 16 under BoneCP). If your instance isn't doing much, idle connections are closed. If there's a load spike and several connections are needed, new connections are opened. The max is still 80, but it's unlikely you'll ever hit it.

On our primary production cluster, we rarely see either node opening more than 15 connections with the new HikariCP pool (where both nodes almost always had 80 connections under BoneCP).

Rather than trying to configure the pool size up or down, the best approach is to just let the pool manage itself. The defaults give your instance room to grow, but the only way you'll see your system use 80 connections is if you have a spike of sufficient concurrency to need 80. The rest of the time, it will probably use a dozen or less all by itself, without any need for manual configuration.

Best regards,
Bryan Turner
Atlassian Bitbucket

[Laurent Denanot]

Thanks Bryan for your answer though I still fail to see why a product like Bitbucket would use a default DB pool size of 80 connections, that is huge!! And I still fail to see why under light load (less than 10 users, NOT using it simultaneously) the active connection count would grow up to 20!

In any case, I was able to successfully configure the pool size by defining the "db.pool.size.max" property in the "bitbucket.properties" file.

For production, with an estimated user base of 30 users, I will probably use a pool size of 30 or 40, but not more.

Thanks for your help and best regards

Laurent

ps - sorry I meant to COMMENT instead of adding another answer but my current status restricts me from adding a comment to your post (I am told I must earn "points" prior to being able to perform further actions during a single day... I wish they would put this kind of policy in force at my workplace so that I could go home earlier...)

[Bryan Turner]

Laurent, If the connection count only grows to 20, I don't see why you'd bother configuring anything. The system is using fewer connections than your new arbitrary limit all on its own. I don't know your environment, so I'm not sure how much CI load (Bamboo, Jenkins, TeamCity) your instance might have. In environments with a lot of CI, even if no users are online and using the system the continuous polling from build servers can keep Bitbucket Server under load at all times. Plugins you install can also use database connections for their own background processing, in addition to housekeeping the server is doing in the background. I don't know what plugins you have installed, so I can't offer any perspective on what database operations they might be doing. The default is 80 for scalability. Most organizations are able to use Bitbucket Server in their environment without every needing to configure its database settings explicitly. It scales from 10 user starter licenses to thousand user enterprise licenses without adjustment. The only time opens all 80 connections at once is if it is under sufficient concurrent load that it needs them all. So, while 80 may be "too high" for your organization, that just means the server will never use 80; it'll use 20-30. There's no need to "help" the server not use 80 connections. And should a burst of concurrent requests come in the server will be able to scale to handle them all, rather than allowing requests to fail because it's not allowed to open more connections. Good luck! Bryan Turner Atlassian Bitbucket