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?

Re: [PERFORM] can we optimize STACK_DEPTH_SLOP

2010-02-20 Thread Tom Lane
"=?ISO-8859-1?B?dGVycnk=?=" <94487...@qq.com> writes: > 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? That's not memory, that's just ad

[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] 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" writes: > > I have a system with around 330 databases ru

Re: [PERFORM] AutoVacuum_NapTime

2010-02-20 Thread Tom Lane
"George Sexton" 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 you'd get an autovac

[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 autovac

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.

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

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