On Sun, Feb 15, 2009 at 6:35 PM, Greg Smith wrote:
> http://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm goes over
> this topic, with "Appendix B: pg_stat_bgwriter sample analysis" covering a
> look at what to do based on a pg_stat_bgwriter snapshot.
Wonderful, thank you.
Alexander
On Sat, 14 Feb 2009, Alexander Staubo wrote:
Is there any statistic available that can tell me whether work_mem is
being exceeded?
As of 8.3, log_temp_files puts information about them into your logs; see
http://www.postgresql.org/docs/current/static/runtime-config-logging.html
--
* Greg Sm
On Sat, 14 Feb 2009, Alexander Staubo wrote:
Are there any statistics, either in PostgreSQL proper or in the OS, that
I can use as metrics to guide the tuning? For example, is there anything
in pg_stat_bgwriter that can help me tune the bgwriter_lru_* settings?
http://www.westnet.com/~gsmith/
On Sat, Feb 14, 2009 at 8:23 PM, Tom Lane wrote:
> Alexander Staubo writes:
>> Wow -- I set this to 10GB (5GB for shared buffers + another 5GB for
>> cache), and today's average write frequency went from 20MB/sec to just
>> 1MB/sec. The documentation suggests that effective_cache_size is only
>>
Alexander Staubo writes:
> wrote:
>> You should definitely set effective_cache_size.
> Wow -- I set this to 10GB (5GB for shared buffers + another 5GB for
> cache), and today's average write frequency went from 20MB/sec to just
> 1MB/sec. The documentation suggests that effective_cache_size is o
On Sat, Feb 14, 2009 at 9:49 AM, Craig Ringer
wrote:
> Is there any chance you had pg_xlog stored separately on your old database,
> and I/O for it wasn't being recorded?
No, the database files have always been on a single volume.
Alexander.
--
Sent via pgsql-performance mailing list (pgsql-pe
On Fri, Feb 13, 2009 at 6:35 PM, Kevin Grittner
wrote:
> You should definitely set effective_cache_size.
Wow -- I set this to 10GB (5GB for shared buffers + another 5GB for
cache), and today's average write frequency went from 20MB/sec to just
1MB/sec. The documentation suggests that effective_ca
Alexander Staubo wrote:
On Fri, Feb 13, 2009 at 12:53 PM, Alexander Staubo wrote:
The upgrade was done with dump/restore using "pg_dump -Fc". The old
database lived on a SAN volume, whereas the new database lives on a
local disk volume.
I need to correct myself: The Munin graphs were never se
>>> Alexander Staubo wrote:
> Kevin Grittner wrote:
>> Could you show the non-commented lines from old and new
>> postgresql.conf files, please?
>
> Attached. The differences are not performance-related, as far as I
> can see, aside from the additional of "synchronous_commit = off".
You shoul
On Fri, Feb 13, 2009 at 5:17 PM, Kevin Grittner
wrote:
> Could you show the non-commented lines from old and new
> postgresql.conf files, please?
Attached. The differences are not performance-related, as far as I can
see, aside from the additional of "synchronous_commit = off".
Alexander.
82.c
>>> Alexander Staubo wrote:
> When I compare the correct graph, however, it's apparently that I/O
> writes have, on average, doubled.
Could you show the non-commented lines from old and new
postgresql.conf files, please?
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@p
On Fri, Feb 13, 2009 at 12:53 PM, Alexander Staubo wrote:
> The upgrade was done with dump/restore using "pg_dump -Fc". The old
> database lived on a SAN volume, whereas the new database lives on a
> local disk volume.
I need to correct myself: The Munin graphs were never set to track the
SAN vol
On Fri, Feb 13, 2009 at 3:46 PM, Kevin Grittner
wrote:
Alexander Staubo wrote:
>> After upgrading from 8.2 to 8.3.5, the write load on our database
>> server has increased dramatically and inexplicably -- as has the CPU
>> usage.
>
> Did you do a VACUUM ANALYZE of the database after loading
>>> Alexander Staubo wrote:
> After upgrading from 8.2 to 8.3.5, the write load on our database
> server has increased dramatically and inexplicably -- as has the CPU
> usage.
Did you do a VACUUM ANALYZE of the database after loading it? Without
the database VACUUM, the first read of any page
14 matches
Mail list logo
