Re:

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

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

Also, didn't someone recently report some very significant performance
differences Windows networking QoS (Quality of Service) installed? You
might try that.

On Tue, 15 Feb 2005, Matthew T. O'Connor wrote:

Magnus Hagander wrote:

Also, didn't someone recently report some very significant performance
differences Windows networking QoS (Quality of Service) installed? You
might try that.

It's unlikely. Postmaster listens loopback, AFAIK loopback does not
affected by any networking tuning and parameters. Additionally, during
pgbench test I have not any other network activity, hence QoS flag
looks unrelated for this problem.

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

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

On Tue, Feb 15, 2005 at 08:03:39PM +0300, E.Rodichev wrote:

On Tue, 15 Feb 2005, Magnus Hagander wrote:

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

Write caching is generally on by default with IDE drives. Disable it
like so:
hdparm -W 0 /dev/hda

-Mike Adler

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

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
[mailto:pgsql-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

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

Not really known, as the native win version is a bit too new for that.

Expect linux performance to be better, though, that much is sure.

//Magnus

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.

The price on win32 for row level stats collector is fairly high. Also
the stats collector resets randomly under very high loads. However I
don't think this is what's going on here.

Also, IPC is out. The win32 IPC implementation is fine, if somewhat
slower than linux implementation. It's all about syncing, IMO.

Merlin