Benjamin Krajmalnik wrote:
So, if I understand correctly, I should strive for a relative increase in
buffers_clean to buffers_backend
Right. Buffers written by a backend are the least efficient way to get
data out of the buffer cache, because the client running into that is
stuck waiting
>See how buffers_backend is much larger than buffers_clean, even though
>maxwritten_clean is low? That means the background writer isn't running often
>enough to keep up with cleaning things, even though >it does a lot of work
>when it does kick in. In your situation I'd normally do a first
Benjamin Krajmalnik wrote:
There are approximately 50 tables which get updated with almost 100%
records updated every 5 minutes -- what is a good number of autovacuum
processes to have on these? The current server I am replacing only
has 3 of them but I think I may gain a benefit from having
There are approximately 50 tables which get updated with almost 100%
records updated every 5 minutes - what is a good number of autovacuum
processes to have on these? The current server I am replacing only has
3 of them but I think I may gain a benefit from having more.
Watch pg_stat_user_tables
still gappy knowledge J
From: Greg Smith [mailto:g...@2ndquadrant.com]
Sent: Tuesday, February 01, 2011 4:54 AM
To: Benjamin Krajmalnik
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Configuration for a new server.
Benjamin Krajmalnik wrote:
have a new set of servers
Benjamin Krajmalnik wrote:
have a new set of servers coming in -- Dual Xeon E5620's, 96GB RAM,
18 spindles (1 RAID1 for OS -- SATA, 12 disk RAID10 for data -- SAS,
RAID-1 for logs -- SAS, 2 hot spares SAS).
You didn't mention the RAID controller and its cache setup. That's a
critical pi
Scott,
I don't know if you received my private email, but just in case you did not I
am posting the infomration here.
I have a new set of servers coming in - Dual Xeon E5620's, 96GB RAM, 18
spindles (1 RAID1 for OS - SATA, 12 disk RAID10 for data - SAS, RAID-1 for logs
- SAS, 2 hot spares S
