Skip to content

Conversation

gurneyalex
Copy link
Contributor

when running a very large number of instances, it is a good idea to limit the number of connections in the pool from 64 to a more reasonable value.

@odony
Copy link
Contributor

odony commented Jul 8, 2015

I don't see any problem with the patch, but out of curiosity, have you been able to measure any kind of difference with this patch? How many open connections did you have before/after?
Theoretically the system should not open more than 2 connections per request, and reuse them as necessary, so for a typical 8.0 build with 2 databases (-all and -base) you should see up to 4 connections per process (2 databases with 2 connections max each). We usually have 4 processes (2 HTTP workers, 1 longpolling and 1 cron worker), so that should be 16 connections max in total. The limit applies per process so passing --db_maxconn 8 won't reduce that number much...?
Thanks

@gurneyalex
Copy link
Contributor Author

Hmm actually no, I admit I did not monitor the number of connections before and after the patch. I was having max conn exceeded in postgresql and assumed the connection pool was filled on the first http request (because the errors were experienced during live usage of the runbot instances, and never during builds).

postgresql.conf tuning provided, with a massive increase of the number of connexions proved a better way in the end. I still have issues but these are related to the --log-db database which needs an increase in max connexions too.

I'll try and remove the patch on the OCA runbot see what happens and report back.

@rim-odoo rim-odoo added the RUNBOT label Aug 6, 2015
@odony odony force-pushed the master branch 7 times, most recently from ab648fe to 9bd4838 Compare January 18, 2016 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants