Re: MusicBrainz postgres performance issues

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "michael(at)sqlexec(dot)com" <michael(at)sqlexec(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: MusicBrainz postgres performance issues
Date: 2015-03-16 00:22:52
Message-ID: 5506225C.1070304@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 16/03/15 13:07, Tomas Vondra wrote:
> On 16.3.2015 00:55, michael(at)sqlexec(dot)com wrote:
>> Why is 500 connections "insane". We got 32 CPU with 96GB and 3000
>> max connections, and we are doing fine, even when hitting our max
>> concurrent connection peaks around 4500. At a previous site, we were
>> using 2000 max connections on 24 CPU and 64GB RAM, with about 1500
>> max concurrent connections. So I wouldn't be too hasty in saying more
>> than 500 is asking for trouble. Just as long as you got your kernel
>> resources set high enough to sustain it (SHMMAX, SHMALL, SEMMNI, and
>> ulimits), and RAM for work_mem.
[...]
> Also, if part of the query required a certain amount of memory for part
> of the plan, it now holds that memory for much longer too. That only
> increases the change of OOM issues.
>
[...]

Also you could get a situation where a small number of queries & their
data, relevant indexes, and working memory etc can all just fit into
RAM, but the extra queries suddenly reduce the RAM so that even these
queries spill to disk, plus the time required to process the extra
queries. So a nicely behaved system could suddenly get a lot worse.
Even before you consider additional lock contention and other nasty things!

It all depends...

Cheers,
Gavin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Roxanne Reid-Bennett 2015-03-16 02:23:56 Re: MusicBrainz postgres performance issues
Previous Message michael@sqlexec.com 2015-03-16 00:17:44 Re: MusicBrainz postgres performance issues