Re: [PERFORM] SSD + RAID

2010-02-20 Thread Bruce Momjian
Matthew Wakeling wrote: On Fri, 13 Nov 2009, Greg Smith wrote: In order for a drive to work reliably for database use such as for PostgreSQL, it cannot have a volatile write cache. You either need a write cache with a battery backup (and a UPS doesn't count), or to turn the cache off.

Re: [PERFORM] SSD + RAID

2010-02-20 Thread Dan Langille
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Momjian wrote: Matthew Wakeling wrote: On Fri, 13 Nov 2009, Greg Smith wrote: In order for a drive to work reliably for database use such as for PostgreSQL, it cannot have a volatile write cache. You either need a write cache with a

Re: [PERFORM] SSD + RAID

2010-02-20 Thread Bruce Momjian
Dan Langille wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruce Momjian wrote: Matthew Wakeling wrote: On Fri, 13 Nov 2009, Greg Smith wrote: In order for a drive to work reliably for database use such as for PostgreSQL, it cannot have a volatile write cache. You either need

[PERFORM] AutoVacuum_NapTime

2010-02-20 Thread George Sexton
I have a system with around 330 databases running PostgreSQL 8.4.2 What would the expected behavior be with AutoVacuum_NapTime set to the default of 1m and autovacuum_workers set to 3? What I'm observing is that the system is continuously vacuuming databases. Would these settings mean the

Re: [PERFORM] AutoVacuum_NapTime

2010-02-20 Thread Tom Lane
George Sexton geor...@mhsoftware.com writes: I have a system with around 330 databases running PostgreSQL 8.4.2 What would the expected behavior be with AutoVacuum_NapTime set to the default of 1m and autovacuum_workers set to 3? autovacuum_naptime is the cycle time for any one database, so

Re: [PERFORM] AutoVacuum_NapTime

2010-02-20 Thread George Sexton
-Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Saturday, February 20, 2010 6:15 PM To: George Sexton Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] AutoVacuum_NapTime George Sexton geor...@mhsoftware.com writes: I have a system with around 330

[PERFORM] can we optimize STACK_DEPTH_SLOP

2010-02-20 Thread terry
hi, STACK_DEPTH_SLOP stands for Required daylight between max_stack_depth and the kernel limit, in bytes. Why we need so much memory? MySql need only no more than 100K. Where these memory allocated for? Can we do something to decrease this variable? Thanks.

[PERFORM] can we optimize STACK_DEPTH_SLOP

2010-02-20 Thread terry
hi, STACK_DEPTH_SLOP stands for Required daylight between max_stack_depth and the kernel limit, in bytes. Why we need so much memory? MySql need only no more than 100K. Where these memory allocated for? Can we do something to decrease this variable? Thanks.

Re: [PERFORM] can we optimize STACK_DEPTH_SLOP

2010-02-20 Thread terry
Thanks for your help! But why we set STACK_DEPTH_SLOP to 512K, not 128K? What it according to?