Re: max_connections reached in postgres 9.3.3 - Mailing list pgsql-general

From Merlin Moncure
Subject Re: max_connections reached in postgres 9.3.3
Date
Msg-id CAHyXU0xy2LKfAjEMQJawDhgH_OL-_j4D3-srzJBQTddeUeWDkg@mail.gmail.com
Whole thread Raw
In response to max_connections reached in postgres 9.3.3  ("Vasudevan, Ramya" <ramya.vasudevan@classmates.com>)
Responses Re: max_connections reached in postgres 9.3.3
List pgsql-general
On Thu, Jun 12, 2014 at 1:23 PM, Vasudevan, Ramya
<ramya.vasudevan@classmates.com> wrote:
> Thank you for the response.
>
> On further investigation, we found out that select statements were happening normally. But DMLs (writes to the DB)
werehung for minutes at a time, and some of them went through. And we had 2 checkpoints during this period. Yesterday
whenwe had the issue, we had 759 connections  that were not idle (116 COMMIT, 238 INSERT, UPDATE 176, 57
AUTHENTICATION,133 BIND). So, it looked like writes (simple inserts and updates) were not happening as fast and caused
connectionsto back up in the DB. So, it didn’t look like any one bad query. 
> It almost seems like postgres could not write to the WAL logs.
>
> We normally have 600-700 connections in the database. Since we migrated lot more applications to this postgres
databasefrom oracle, we increased max_connections just as a test to see if we legitimately need to allow more
connectionsor if it is an issue. And quickly realized that we already had a high number (1500) 

Be sure to rule out locks -- some operation blocks queries until it
clears then everyone storms in.  It's good idea to count up blocked
queries (select count(*) from pg_locks where waiting) and raise alarms
when you see any accumulation there.

merlin


pgsql-general by date:

Previous
From: Keith Fiske
Date:
Subject: Re: [HACKERS] Question about partial functional indexes and the query planner
Next
From: Jeff Janes
Date:
Subject: Re: updates not causing changes