Re: pg_test_fsync performance

On Wed, Feb 15, 2012 at 02:23, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
>> On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
>> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > > On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
>> > >> +1, I was about to suggest the same thing.  Running any of these tests
>> > >> for a fixed number of iterations will result in drastic degradation of
>> > >> accuracy as soon as the machine's behavior changes noticeably from what
>> > >> you were expecting.  Run them for a fixed time period instead.  Or maybe
>> > >> do a few, then check elapsed time and estimate a number of iterations to
>> > >> use, if you're worried about the cost of doing gettimeofday after each
>> > >> write.
>> >
>> > > Good idea, and it worked out very well.  I changed the -o loops
>> > > parameter to -s seconds which calls alarm() after (default) 2 seconds,
>> > > and then once the operation completes, computes a duration per
>> > > operation.
>> >
>> > I was kind of wondering how portable alarm() is, and the answer
>> > according to the buildfarm is that it isn't.
>>
>> I'm using following simplistic alarm() implementation for win32:
>>
>>   https://github.com/markokr/libusual/blob/master/usual/signal.c#L21
>>
>> this works with fake sigaction()/SIGALARM hack below - to remember
>> function to call.
>>
>> Good enough for simple stats printing, and avoids win32-specific
>> code spreading around.
>
> Wow, I wasn't even aware this compiled in Win32;  I thought it was
> ifdef'ed out.  Anyway, I am looking at SetTimer as a way of making this
> work.  (Me wonders if the GoGrid Windows images have compilers.)

They don't, since most of the compilers people would ask for don't
allow that kind of redistribution.

Ping me on im if you need one preconfigured, though...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/