I moved from my old build to my new build using the same disks and my transfer speeds have dropped from about 80-90MB/s to a max of 42MB/s when writing to the array.

 

 

Old Build:

 

-2.8GHz AMD Sempron (Single core)

-4GB Crucial RAM

 

New Build:

 

-3.6GHz Intel i3 Dual Core Haswell

-16GB G.Skill Ripjaw RAM

-Crucial 256GB SSD

-GIGABYTE GA-Z97X-UD5H

 

Also, the server doesn't seem to be using the cache drive.  When I copy files to the array and watch the GUI, the writes are showing up on the HDD as opposed to the SSD.  The SATA ports are set to ACHI in the BIOS.

syslog.txt

Have you checked the relevant share settings to make sure tHat they are set to use the cache?

You're actually getting excellent write speeds for a direct-to-the-array write with parity.

 

As for why the writes aren't being cached ... I suspect that, as itimpi noted, you simply don't have the shares set to use the cache.

 

You're actually getting excellent write speeds for a direct-to-the-array write with parity.

 

As for why the writes aren't being cached ... I suspect that, as itimpi noted, you simply don't have the shares set to use the cache.

 

itimpi was correct. Now that I set the shares to use the cache drive it is working correct.

 

Why would my transfer for a direct to the array copy speed drop so much?  It was almost double before.

Your direct-to-the array write speeds are EXCELLENT (42MB/s).

 

The higher speeds you were seeing (80-90MB/s) were clearly cached writes -- NOT direct to the array.

 

Your direct-to-the array write speeds are EXCELLENT (42MB/s).

 

The higher speeds you were seeing (80-90MB/s) were clearly cached writes -- NOT direct to the array.

 

Actually no.  This is the first time I've had a cache drive.  My last server didn't. 

You must not have had a parity drive assigned on your last server then => there's no way you can get 80-90MB/s writes to a fault tolerant array [unless your array drives are all SSDs  ].

 

As I noted, 42MB/s is an excellent speed for writes to the protected array.

 

 

Actually there was a parity drive installed.  Unless it wasn't being used for some reason?  It shows up in the GUI as a parity drive and I was able to rebuild a failed drive a few weeks ago, so I think it's working.

 

I almost want to put the old server back together just so I can get a screenshot.

Unless you were writing small files that were entirely cached in memory (which would "seem" to be very fast, since the PC writing them would see a high transfer rate), there's simply no way that you can write to the parity protected array at the speeds you indicated (80-90MB/s).

 

 

This setting in your go script could change things also.

 

sysctl vm.highmem_is_dirtyable=1

 

It allows more buffering in the buffer cache for some reason.

So you can do a burst write to the array for a short period of time before the cache starts flushing and slowing things down.

 

On my array there are times I burst at 90MB/s, but as more data gets copied it slows down to the 40-60MB/s range.

 

There are other design/architectural situations that come into play.

Such as,  how fast is the PCIe bus to the drive(s) in question?

If you happen to put the parity drive on a slower interface that would change burst-ability.

There is also write caching in the bios.

There is also path from CPU to Drive.

Are the drive(s) in question on the direct PCIe channel or does it go through another chipset that ultimately shares a channel with other devices?

 

80MB/s sustained write to array drives for large files (movies not mp3's) is unlikely without some kind of tuning in the buffer cache, empty filesystems or a small amount of data.

 

In my best settings with a number of machines I could not sustain 80MB/s past 500MB on a parity protected drive.

Usually around 60MB/s if the drive is empty.

By the time it hit 4GB-10GB it was the normal 35-50MB/s.