I tried running the read and write tests on a SLES 11 SP1 x64 server running as a vSphere 4.0 VM connected to an EMC SAN and got pretty bad numbers. On average after 3 runs I was seeing 92.4 MB/s for writes and 71 MB/s for reads! Why would reads be slower than writes?

Also, do you know of an equivalent way to test a Windows GW server so I could compare performance of Windows to Linux?

Dan

Linux file systems (like many modern file systems) utilize the system memory to cache file writes, at least until it exhausts the memory that's available, then it needs to commit the writes to the disk IO subsystem. Since this test is reading a "0" from memory and writing it to a file many times, it's going to first go to cache until it exhausts available cache memory, then to disk with no read time delay. The "sync" command at the beginning of the command string will force the writing of any previously cached data to disk, leaving our "dd" command with a clean slate for our test. Although it is true that using the system cache will skew the test results; making a machine with oodles of memory appear to be much faster than one that is starved, adjusting the number of gigabytes of data written to disk to at least double the amount of memory available on the server will show a much more consistent and accurate number. This is because it's much much faster to write the "0" from memory to memory (cache) than it is to write it to disk across even the fastest SAN or disk system.

Read operations on the other hand rely almost entirely on the connection to disk and will only occur at the maximum sustainable speed from the IO subsystem (the slowest/weakest link in the chain). In our test we're reading it from disk and writing it to /dev/null (the bitbucket).

If you are writing to a SAN or cache enabled array controller, you can bias the read/write ratio to match your traffic. It's possible that your SAN administrator has biased the system one way or the other.

The answer to your question on Windows based tools is "it depends", many tools will emulate reads and writes but some will actually let you point to a directory structure and "exercise the hard drives" by copying these files to and from the server's disk. A simple way to do this is with a stopwatch and a few large files, it should give you a pretty decent idea of what your throughput on sustained reads are, what it won't do is show you what your sustained writes are as you'd be reading a file then writing at the same time.

I have always been hesitant to host a GroupWise system on Windows due to fragmentation issues exaggerated by how GroupWise reads and writes many many small transient files then deletes them. This will rapidly cause the performance to degrade on a file system ill-equipped to handle fragmentation. Again, these are my opinions and results from years of experience, your mileage will vary.

Linux file systems (like many modern file systems) utilize the system memory to cache file writes, at least until it exhausts the memory that's available, then it needs to commit the writes to the disk IO subsystem. Since this test is reading a "0" from memory and writing it to a file many times, it's going to first go to cache until it exhausts available cache memory, then to disk with no read time delay. The "sync" command at the beginning of the command string will force the writing of any previously cached data to disk, leaving our "dd" command with a clean slate for our test. Although it is true that using the system cache will skew the test results; making a machine with oodles of memory appear to be much faster than one that is starved, adjusting the number of gigabytes of data written to disk to at least double the amount of memory available on the server will show a much more consistent and accurate number. This is because it's much much faster to write the "0" from memory to memory (cache) than it is to write it to disk across even the fastest SAN or disk system.

Read operations on the other hand rely almost entirely on the connection to disk and will only occur at the maximum sustainable speed from the IO subsystem (the slowest/weakest link in the chain). In our test we're reading it from disk and writing it to /dev/null (the bitbucket).

If you are writing to a SAN or cache enabled array controller, you can bias the read/write ratio to match your traffic. It's possible that your SAN administrator has biased the system one way or the other.

The answer to your question on Windows based tools is "it depends", many tools will emulate reads and writes but some will actually let you point to a directory structure and "exercise the hard drives" by copying these files to and from the server's disk. A simple way to do this is with a stopwatch and a few large files, it should give you a pretty decent idea of what your throughput on sustained reads are, what it won't do is show you what your sustained writes are as you'd be reading a file then writing at the same time.

I have always been hesitant to host a GroupWise system on Windows due to fragmentation issues exaggerated by how GroupWise reads and writes many many small transient files then deletes them. This will rapidly cause the performance to degrade on a file system ill-equipped to handle fragmentation. Again, these are my opinions and results from years of experience, your mileage will vary.

Good point on disk frag under Windows. The installation I worked with started slowing down after 6-12 months after migrating to Windows (from NetWare). We moved from 7200 rpm disk (on SAN) to 15K and that helped a bit. However, the ultimate fis was to install a third party defrag tool that would use "free" cpu/disk cycles to keep the disk space unfragmented.

Note: we also found that too many hosts sharing the same physical SAN disk can hurt performance as well. We wound up putting POAs and MTAs on their own set of disk on the SAN to avoid disk contention.

I thought, defragmenting under w2008r2 is absolet?
Have anyone experience with GW and w2008r2?

thx@andreas