| From: | Ilya Kosmodemiansky <ilya(dot)kosmodemiansky(at)postgresql-consulting(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, 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:42:51 |
| Message-ID: | CAG95seXv4EKGhDV04rkk_ARgvz8OQUJy3Xbx5Rw16Wxm3+1j5Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, Mar 15, 2015 at 8:20 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2015-03-15 11:09:34 -0600, Scott Marlowe wrote:
>> shared_mem of 12G is almost always too large. I'd drop it down to ~1G or so.
>
> I think that's a outdated wisdom, i.e. not generally true.
Quite agreed. With note, that proper configured controller with BBU is needed.
> A new enough kernel, a sane filesystem
> (i.e. not ext3) and sane checkpoint configuration takes care of most of
> the other disadvantages.
Most likely. And better to be sure that filesystem mounted without barrier.
And I agree with Scott - 64MB work mem AND max_connections = 500 is a
recipe for disaster. The problem could be in session mode of
pgbouncer. If you can work with transaction mode - do it.
Best regards,
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
ik(at)postgresql-consulting(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-03-15 17:46:47 | Re: MusicBrainz postgres performance issues |
| Previous Message | Andres Freund | 2015-03-15 17:20:48 | Re: MusicBrainz postgres performance issues |