| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Robert Kaye <rob(at)musicbrainz(dot)org>, Josh Krupka <jkrupka(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: MusicBrainz postgres performance issues |
| Date: | 2015-03-15 17:11:55 |
| Message-ID: | CAOR=d=3k9DYpxj6d2qSdtpvdieAfNrnNXHE_jR-ELR2X=mGLqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, Mar 15, 2015 at 11:09 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-03-15 17:20:48 | Re: MusicBrainz postgres performance issues |
| Previous Message | Scott Marlowe | 2015-03-15 17:09:34 | Re: MusicBrainz postgres performance issues |