Date: Fri, 26 Oct 2007 09:20:36 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: 8.3beta1 testing on Solaris
In-reply-to: <87640u95xu.fsf@oxford.xeocode.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Message-id: <4721E9A4.4040800@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> <87640u95xu.fsf@oxford.xeocode.com>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)


Hi George,

I have seen the 4M/sec problem first actually during an EAStress type 
run with only 150 connections.

I will try to do more testing today that Tom has requested.

Regards,
Jignesh


Gregory Stark wrote:
> "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
>
>   
>> CLOG data is not cached in any PostgreSQL shared memory segments and hence
>> becomes the bottleneck as it has to constantly go to the filesystem to get
>> the read data.
>>     
>
> This is the same bottleneck you discussed earlier. CLOG reads are cached in
> the Postgres shared memory segment but only NUM_CLOG_BUFFERS are which
> defaults to 8 buffers of 8kb each. With 1,000 clients and the transaction rate
> you're running you needed a larger number of buffers.
>
> Using the filesystem buffer cache is also an entirely reasonable solution
> though. That's surely part of the logic behind not trying to keep more of the
> clog in shared memory. Do you have any measurements of how much time is being
> spent just doing the logical I/O to the buffer cache for the clog pages? 4MB/s
> seems like it's not insignificant but your machine is big enough that perhaps
> I'm thinking at the wrong scale.
>
> I'm really curious whether you see any benefit from the vxid read-only
> transactions. I'm not sure how to get an apples to apples comparison though.
> Ideally just comparing it to CVS HEAD from immediately prior to the vxid patch
> going in. Perhaps calling some function which forces an xid to be allocated
> and seeing how much it slows down the benchmark would be a good substitute.
>
>