> 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.
800tps sounds unreasonably high on a notebook.

Question 2: Please try disabling the stats connector and see if that
helps. Merlin Moncure reported some scalability issues with the stats
collector previously.


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

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Tue, 15 Feb 2005, Magnus Hagander wrote:

>> 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

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

>
> 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"?

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

Regards,
E.R.
__________________________________________________ _______________________
Evgeny Rodichev Sternberg Astronomical Institute
email: er@sai.msu.su Moscow State University
Phone: 007 (095) 939 2383
Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly