Re:

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "E(dot)Rodichev" <er(at)sai(dot)msu(dot)su>
Cc: <pgsql-hackers(at)postgresql(dot)org>, <oleg(at)sai(dot)msu(dot)su>
Subject: Re:
Date: 2005-02-15 18:03:20
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE4768A5@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
* 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

Responses

  • Re: at 2005-02-16 00:28:18 from E.Rodichev
  • Re: at 2005-02-16 08:51:50 from Benjamin Arai

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Adler 2005-02-15 18:05:18 Re:
Previous Message E.Rodichev 2005-02-15 17:35:17 Re: