Re: PostgreSQL on VMWare vs Windows vs CoLinux

"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?

> 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.

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.

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.

--
greg