Re: PostgreSQL on VMWare vs Windows vs CoLinux

On Wed, 2004-06-02 at 17:39, Greg Stark wrote:
> "Matthew Nuzum" <matt(at)followers(dot)net> 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 <matt(at)followers(dot)net>
Followers.net, Inc.