Vitaly Belman [EMAIL PROTECTED] writes:
With all that said, VMWare is badly suited for running a database,
while CoLinux can be run as a service (didn't try it yet though),
VMWare always sits there, it is slow to go up, slow to go down and
generally feels like a system hog.
Uhm, it
Using VMware myself quite extensively, I wonder what the disk
configuration was that you created for the VM. Where the disks
preallocated and did you make sure that they are contiguous on the NTFS
filesystem? Did you install the VMware tools in the guest operating system?
What did you use to
Greg Stark [EMAIL PROTECTED] writes:
That said, I'm curious why the emulated servers performed better than the
Native Windows port. My first thought is that they probably aren't syncing
every write to disk so effectively they're defeating the fsyncs, allowing the
host OS to buffer disk writes.
on VMWare vs Windows vs CoLinux
Greg Stark [EMAIL PROTECTED] writes:
That said, I'm curious why the emulated servers performed better than
the
Native Windows port. My first thought is that they probably aren't
syncing
every write to disk so effectively they're defeating the fsyncs,
allowing
Hi All,
I think it would actually be interesting to see the performance of the Cygwin version
for these same benchmarks, then we've covered all ways to run PostgreSQL on Windows
systems. (I expect though that performance of Cygwin-PostgreSQL will improve
considerably when an updated version is
Greg Stark wrote:
That said, I'm curious why the emulated servers performed better than the
Native Windows port. My first thought is that they probably aren't syncing
every write to disk so effectively they're defeating the fsyncs, allowing the
host OS to buffer disk writes.
I havn't tested it,
On 2 Jun 2004 at 16:45, Merlin Moncure wrote:
'better' does not mean 'faster'. Win32 has a pretty decent journaling
filesytem (ntfs) and a good I/O subsystem which includes IPC. Process
management is poor compared to newer linux kernels but this is
unimportant except in extreme cases.
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.5149.1 1
122.1 126.7
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
Matthew Nuzum [EMAIL PROTECTED] writes:
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.
So increase the number of transactions tested (-t switch to pgbench).
Be aware also that you really want -s
Merlin Moncure [EMAIL PROTECTED] writes:
... Right now the win32 native does
not sync() (but does fsync()). So, the performance is somewhere between
fsync = off and fsync = on (probably much closer to fsync = on). It is
reasonable to assume that the win32 port will outperform the unix
Hello pgsql-performance,
I was using the native windows PostgreSQL 7.5Dev and was adviced by
several people to use an emulated PostgreSQL instead, as it is just
a beta.
Well, I give it a whirl and tried both commercial VMWare and the
freeweare open-source CoLinux, both work under
12 matches
Mail list logo
