Date: Fri, 26 Oct 2007 09:36:53 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: [HACKERS] 8.3beta1 testing on Solaris
In-reply-to: <2139.1193369168@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org,
	Gregory Stark <stark@enterprisedb.com>, pgsql-hackers@postgresql.org
Message-id: <4721ED75.7090607@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <4720FB72.8060800@sun.com> <871wbi95nb.fsf@oxford.xeocode.com>
	<29721.1193359867@sss.pgh.pa.us> <200710251956.56744.josh@agliodbs.com>
	<2139.1193369168@sss.pgh.pa.us>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)

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@agliodbs.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
>