From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Krzysztof Kardas <krzychk2(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL with Zabbix - problem of newbe |
Date: | 2010-04-09 16:44:59 |
Message-ID: | r2ydcc563d11004090944vdee233a7w4dbf3ea99217005c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Apr 9, 2010 at 10:30 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> The main problem with this configuration is that work_mem is set to an
>> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
>> free after starting the server, work_mem='4MB' is as large as you can safely
>> set this.
>
> if you need more work_mem for this or that and also need to serve a
> lot of connections, you can always set it locally (1.6GB is still too
> high though -- maybe 64mb if you need to do a big sort or something
> like that).
>
> Another path to take is to install pgbouncer, which at 400 connections
> is worth considering -- but only if your client stack doesn't use
> certain features that require a private database session. zabbix will
> _probably_ work because it is db portable software (still should check
> however).
Also remember you can set it by user or by db, depending on your
needs. I had a server that had a reporting db and an app db. The app
db was set to 1 or 2 Meg work_mem, and the reporting db that had only
one or two threads ever run at once was set to 128Meg. Worked
perfectly for what we needed.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-04-09 18:22:20 | Re: 3ware vs. MegaRAID |
Previous Message | Merlin Moncure | 2010-04-09 16:30:26 | Re: PostgreSQL with Zabbix - problem of newbe |