Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] 8.3beta1 testing on Solaris

From: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris
Date: 2007-10-26 13:36:53
Message-ID: 4721ED75.7090607@sun.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
I agree with Tom..  somehow I think  increasing NUM_CLOG_BUFFERS is just 
avoiding the symptom to a later value.. I promise to look more into it 
before making any recommendations to increase NUM_CLOG_BUFFERs.


Because though "iGen"  showed improvements in that area by increasing 
num_clog_buffers , EAStress had shown no improvements.. Plus the reason 
I think this is not the problem in 8.3beta1 since the Lock Output 
clearly does not show CLOGControlFile as to be the issue which I had 
seen in earlier case.  So I dont think that increasing NUM_CLOG_BUFFERS 
will change thing here.

Now I dont understand the code pretty well yet I see three hotspots and 
not sure if they are related to each other
* ProcArrayLock waits  - causing Waits          as reported by 
83_lockwait.d script
* SimpleLRUReadPage - causing read IOs             as reported by 
iostat/rsnoop.d
* GetSnapshotData - causing CPU utilization  as reported by hotuser

But I will shut up and do more testing.

Regards,
Jignesh



Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>   
>> Actually, 32 made a significant difference as I recall ... do you still have 
>> the figures for that, Jignesh?
>>     
>
> I'd want to see a new set of test runs backing up any call for a change
> in NUM_CLOG_BUFFERS --- we've changed enough stuff around this area that
> benchmarks using code from a few months back shouldn't carry a lot of
> weight.
>
> 			regards, tom lane
>   

In response to

Responses

pgsql-performance by date

Next:From: Jean-David BeyerDate: 2007-10-26 14:12:53
Subject: Re: Bunching "transactions"
Previous:From: Jignesh K. ShahDate: 2007-10-26 13:25:02
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris

pgsql-hackers by date

Next:From: Sebastien FLAESCHDate: 2007-10-26 13:58:33
Subject: Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF
Previous:From: Jignesh K. ShahDate: 2007-10-26 13:25:02
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group