Обсуждение:
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. 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. Looks like this is the same for 8.0.1. Did somebody resolved this issue successfully? _________________________________________________________________________ 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. 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
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 * 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
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 * 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.orgso 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