On Wed, 2004-06-02 at 17:39, Greg Stark wrote: > "Matthew Nuzum" <[EMAIL PROTECTED]> writes: > > > I have colinux running on a Fedora Core 1 image. I have the rhdb 3 (or > > PostgreSQL RedHat Edition 3) on it running. Here are tests with fsync on > > and off: > > FSYNC OFF FSYNC ON RUN > > 136.9 142.0 124.5 149.1 1 > > 122.1 126.7 140.1 169.7 2 > > 125.7 148.7 147.4 180.4 3 > > 103.3 136.7 136.8 166.3 4 > > 126.5 146.1 152.3 187.9 5 > > 114.4 133.3 144.8 176.7 6 > > 124.0 146.5 143.3 175.0 7 > > 121.7 166.8 147.8 180.5 8 > > 127.3 151.8 146.7 180.0 9 > > 124.6 143.0 137.2 167.5 10 > > -------------------------------------- > > 122.7 144.2 142.1 173.3 AVG > > > > I hope those numbers' formatting come through all right. > > No, they didn't. You used tabs? Are they four space tabs or 8 space tabs? > I assume 4 space tabs, but then what is the meaning of the four columns? > You have two columns for each fsync setting? One's under Windows and one's > under Vmware? Which is which? > Sorry that wasn't clear. The pgbench program puts out two numbers, can't remember what they are, I think one number included the time to make the connection. Therefore, the first two columns represent the two values presented from pgbench with FSYNC off. The second two columns are those same to figures but with FSYNC ON. The 5th column is the run. I did 10 runs and included the output of all runs so that incase anything significant could be gleaned from the details, the data would be there.
The executive summary is this: Tom was curious if colinux might be deceiving the applications that expect the fsync to occur. He suspected that pgbench run with and without fsync enabled might reveal something. Therefore: FSYNC ON: 142.1 FSYNC OFF: 122.7 Having FSYNC off seems to yield faster results. I'd like some input on a more demanding test though, because these tests run so quickly I can't help but be suspicious of their accuracy. When there are two OSs involved, it seems like the momentary activity of a background process could skew these results. > > It occurs to me that the fsync may be performed to the linux filesystem, but > > this filesystem is merely a file on the windows drive. Would Windows cache > > this file? It's 2GB in size, so if it did, it would only be able to cache > > part of it. > > Well VMWare certainly doesn't know that the linux process called fsync. For > all it knows the Linux kernel just schedule the i/o because it felt it was > time. > > So the question is how does VMWare alway handle i/o normally. Does it always > handle i/o from the Guest OS synchronously or does it buffer it via the > Host OS's i/o system. We probably will never know what the internal workings of VMWare are like because it is a closed source program. I'm not slighting them, I have purchased a license of VMWare and use it for my software testing. However, colinux is an open source project and we can easily find out how they handle this. I have little interest in this as I use this merely as a tool to speed up my application development and do not run any critical services what-so-ever. > > I'm actually not sure which it does, it could be doing something strange. But > does seem most likely that it lets Windows buffer the writes, or does so > itself. It might also depend on whether you're using raw disks or a virtual > disk file. Undoable disks would throw another wrench in the works entirely. In these tests I'm using a virtual disk file. This is a 2GB file on the hard drive that linux sees as a disk partition. Colinux does not support undoable disks in the way that vmware does. Their wiky site does not mention anything tricky being done to force disk writes to actually be written; the implication therefore is that it leaves the i/o completely at the discretion of XP. Also note that XP Pro and 2000 Pro both offer different caching options for the user to choose so unless it does something to actually force a write the answer is probably "who knows." > > Note that "caching" isn't really the question. It doesn't have to cache the > entire 2GB file or even very much of it. It just has to store the block that > linux wants to write and report success to linux without waiting for the disk > to report success. Linux will then think the file is sync'd to disk and allow > postgres to continue with the next transaction without actually waiting for > the physical disk to spin around to the right place and the head to seek and > perform the write. That's interesting to know. I wondered about that. So, my summary is this: If you develop applications in windows that run in linux and you need a testing platform you may like colinux a lot because of the following: * It's purchase price is 0 * It's seems to be capable of running any (or at least many) distribution based on 2.4 kernel * It appears to run much faster than VMWare (maybe because it has far fewer features, including the ability to run X apps unless you use VNC or a separate X server) * When idle it causes no apparent load on the CPU. This is the best part in my opinion. VMWare causes a drag on the system even when idle and especially when active. With colinux you can simply minimize the console or run it as a service and forget about it until you need it. You may prefer VMWare if you need: * GUI setup tools * Full PC hardware support (sound, fb, etc) * Undoable disk support * Painless install (colinux isn't hard but it's not "shrink wrap" quality yet) * Need special kernel features. Colinux uses its own kernel which has been ported to windows. OK, this horse is dead... anyone else want to kick it? Just kidding... If you want me to test something for you, I'd be happy to. Be specific and give me the details and I'll run it through the wringer on Friday. Oh, and don't ask me to download anything big please. 25 of us share a 56k modem there so bandwidth is limited. Hope this is helpful to someone, have a nice day. -- Matthew Nuzum <[EMAIL PROTECTED]> Followers.net, Inc. ---------------------------(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