From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Gregory Stark <stark@enterprisedb.com>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: 8.3beta1 testing on Solaris
Date: Fri, 26 Oct 2007 09:20:36 -0400
Message-ID: <4721E9A4.4040800@sun.com> (raw)
In-Reply-To: <87640u95xu.fsf@oxford.xeocode.com>
References: <4720FB72.8060800@sun.com>
<87640u95xu.fsf@oxford.xeocode.com>
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.
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, stark@enterprisedb.com, pgsql-hackers@postgresql.org
Subject: Re: 8.3beta1 testing on Solaris
In-Reply-To: <4721E9A4.4040800@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox