Re: - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re:
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE4768A5@algol.sollentuna.se
Whole thread Raw
In response to  ("E.Rodichev" <er@sai.msu.su>)
Responses Re:  ("E.Rodichev" <er@sai.msu.su>)
Re:  ("Benjamin Arai" <barai@cs.ucr.edu>)
List pgsql-hackers
>>> I've tested the performance of 8.0.1 at my dual-boot notebook
>>> (Linux and Windows XP).
>>>
>>> I installed 8.0.1 for Linux and Windows XP, and run pgbench
>>> -c 1 -t 1000 Under Linux (kernel 2.6.10) I got about 800 tps,
>>> and under Windows XP - about 20-24 tps.
>>>
>>> Next I switched off virtual memory under Windows (as it was
>>> recommended in posting
>>> http://www.pgsql.ru/db/mw/msg.html?mid=2026070). It does not
>>> help. Without virtual memory I got 15-17 tps.
>>
>>
>> Question 1: Is your writeback cache really disabled in Linux, on the
>> harddrive? Windows fsync will *write through the disk write cache* if
>> the driver is properly implemented. AFAIK, on Linux if write cache is
>> enabled on the drive, fsync will only get into the cache.
>
>Difficult to say concerning writeback cache... I have 2.6.10
>without any
>additional tuning, file system is ext2. From dmesg:
>
>hda: TOSHIBA MK8026GAX, ATA DISK drive
>hda: max request size: 128KiB
>hda: 156301488 sectors (80026 MB), CHS=65535/16/63, UDMA(100)
>hda: cache flushes supported

Run:
hdparm -I /dev/hda

If you get a line like:
Commands/features:       Enabled Supported:          *    READ BUFFER cmd          *    WRITE BUFFER cmd          *
HostProtected Area feature set          *    Look-ahead          *    Write cache 
...
(last line is what matters here)
you have write cacheing enabled.

To turn it of, run
hdparm -W0 /dev/hda

Not sure if you need to reboot, I don'tt hink so. Then re-run the
benchmark on linux.


>> 800tps sounds unreasonably high on a notebook.
>
>Yes, I also was surprized. The same test at Xeon 2.4GHz server
>indicates
>about 700 tps. But it is another issue.

The CPU probably has nothing to do with this, it's probably all I/O.


>> Question 2: Please try disabling the stats connector and see if that
>> helps. Merlin Moncure reported some scalability issues with the stats
>> collector previously.
>
>Sorry, what is "stats connector"?

That's supposed to be stats collector, as you realised in your other
mail. Sorry.

>>> Several yeas ago (about 1997-1998) Oleg Bartunov and me had
>>> the same performance results (Linux vs Windows NT + cygwin).
>>> It was the discussion at this list with resume that the
>>> reason is the implementation of shared memory under Windows.
>>> Every IPC operation results the HDD access.
>>
>> It shouldn't in 8.0 - at least not on the native win32.
>Don't know about
>> cygwin.
>
>Yes, I also expected that the performance for native
>implementation will be
>more reasonable. In fact, during pgbench test under Windows
>and under Linux
>HDD LED lights continiously, so looks like under Windows there
>are much more
>disk operations compared with Linux.

That would be consistent with the theory that write-back caching is
enabled on linux and not on windows.

//Magnus


pgsql-hackers by date:

Previous
From: "E.Rodichev"
Date:
Subject: Re:
Next
From: Michael Adler
Date:
Subject: Re: