Re: MusicBrainz postgres performance issues - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: MusicBrainz postgres performance issues
Date
Msg-id CAOR=d=3k9DYpxj6d2qSdtpvdieAfNrnNXHE_jR-ELR2X=mGLqA@mail.gmail.com
Whole thread Raw
In response to Re: MusicBrainz postgres performance issues  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-performance
On Sun, Mar 15, 2015 at 11:09 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

Clarification:

> 64MB work mem AND max_connections = 500 is a recipe for disaster. No
> db can actively process 500 queries at once without going kaboom, ad
> having 64MB work_mem means it will go kaboom long before it reaches
> 500 active connections. Lower that and let pgbouncer handle the extra
> connections for you.

Lower max_connections. work_mem 64MB is fine as long as
max_connections is something reasonable (reasonable is generally #CPU
cores * 2 or so).

work_mem is per sort. A single query could easily use 2 or 4x work_mem
all by itself. You can see how having hundreds of active connections
each using 64MB or more at the same time can kill your server.


pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: MusicBrainz postgres performance issues
Next
From: Andres Freund
Date:
Subject: Re: MusicBrainz postgres performance issues