Open DB connection buildup

[FrankPerryCarbonite]

In testing our deployment of the omaha server to Elastic Beanstalk, one thing that we've observed is that some DB connections seem to remain open and build up over time, never closing and eventually causing the DB to become unresponsive. Looking at the code, it appears that these should close automatically after 60 seconds. Are there any known issues around this?

[yurtaev]

Do you use root database user?

You can try to change parameter max_connections for postgresql https://wiki.postgresql.org/wiki/Number_Of_Database_Connections & http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html

[FrankPerryCarbonite]

I'm not using the standard postgres root user (as described in https://wiki.postgresql.org/wiki/First_steps), but have used the username that I set as the master user when setting up the RDS instance and observe the behavior. Do I need to use the postgres root? In either case, this seems insecure...

When does the omaha server decide to open a new DB connection? Because opening and closing DB connections is expensive, I would expect it to only open a few connections. When I apply load (250 users/second hitting service/update2) to the public server via Tsung (http://tsung.erlang-projects.org/), I'm seeing >100 connections. This seems excessive. A couple of the connections look like they are from the private admin omaha server, but the majority are from the client-facing public server. Is this expected?

BTW, I should have plenty of connections available:

omahadb=> show max_connections;
 max_connections
-----------------
 259
(1 row)

[yurtaev]

It's a good question. I've tested this use case and I saw 50 connections which were not closed. Currently, I have no idea why it happens.

I've added the issue into our task list, I'll check it a little bit later.

[aduewel]

Hi there, we do experience the same issue. Did you had some findings in the past?

• We actually run into the max connection limit on postgres which results in http 500 for requests to /service/update2
• We do not use pg_bounce to kill idle connections, but I think we need to implement it now.