>>> 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
* Host Protected 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

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

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

Thanks. Ok, really I have it enabled (fortunately

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

Done. Now it is disabled.

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

No, under Linux reboot makes nothing (it is completely dynamical system).

Now I have

/usr/local/pgsql/bin:14>pgbench -c 1 -t 500
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 500
number of transactions actually processed: 500/500
tps = 89.528064 (including connections establishing)
tps = 89.560730 (excluding connections establishing)


It is about 9 times slower. But again 4 times faster then under Windows.

After

root@390x:/e# hdparm -W1 /dev/hda

/dev/hda:
setting drive write-caching to 1 (on)


/usr/local/pgsql/bin:24>pgbench -c 1 -t 500
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 500
number of transactions actually processed: 500/500
tps = 846.189777 (including connections establishing)
tps = 849.481986 (excluding connections establishing)


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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

What kind of performance difference can be expected between Linux and
Windows?

Benjamin Arai
barai@cs.ucr.edu
benjamin@cs.ucr.edu
http://www.benjaminarai.com


-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailtogsql-hackers-owner@postgresql.org] On Behalf Of Magnus Hagander
Sent: Tuesday, February 15, 2005 10:03 AM
To: E.Rodichev
Cc: pgsql-hackers@postgresql.org; oleg@sai.msu.su
Subject: Re: [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
* Host Protected 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

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



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org