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