erratic read speeds openindiana

Jon S - If you re-read the thread you'll see that i have tried 151a4 (was actually using it all the time but didn't mention till later), You'll also see that this affects ALL protocols, Samba, NFS, iSCSI and so on. I have also tried Solaris 11 and so on.

So, point a & b that you mention above are out of the window and as for c...

c) you have three drives in a RAIDZ2 that seems so wrong you have one data disk and two parity disks. Do your self a favor and just mirror and keep one spare drive for repairs if a failure occurs. Now redo your initial tests on a mirrored pair and let me know the results.
Click to expand...

What? I have 8 disks in a RAIDZ2 as well as various iterations of SSD pools and so on. C is out the window also.

Finally 80MB/sec is a little over half of the capacity of the theoretical max of 125MB/sec that can be achieved with a single GigE NIC.
 
Finally 80MB/sec is a little over half of the capacity of the theoretical max of 125MB/sec that can be achieved with a single GigE NIC.


Do bear in mind though that there is no way to realise that theoretical max in practice!
 
Billy_nnn said:
Finally 80MB/sec is a little over half of the capacity of the theoretical max of 125MB/sec that can be achieved with a single GigE NIC.


Do bear in mind though that there is no way to realise that theoretical max in practice!
Click to expand...

That is why you buy Ethernet jacks and cables that support RFC99xx (EtherNet 802.3 high-pressure mode), so you can pump the data down the pike even faster under high pressure leading to faster speeds! :D
 
No - but the consistent 118MBs that CentOS and/or OF delivers aint far off. Certainly closer than 80... ;)
 
Oh and I looked in to the 'EtherNet 802.3 high-pressure mode' but unfortunately the flux capacitor is incompatible with my mobo.
 
I heard one guy that WinXP and Linux clients got slower speed, like 80MB/sec. When he tried a Win7 client, he got over 100MB/sec.
 
Nutnut said:
Something else i have just discovered - when it's bouncing all over the place, if i kick off a second file copy from the same pool it reaches max speed.

I've also done a complete clean install and taken the opportunity to reconfigure the 2x Intel ssd's as a mirror. Works like a charm. Seems to be stutter on the spinners?
Click to expand...

Went back through the thread and saw this - my experiences match yours perfectly (though I don't seem to have the stock of SSDs that you have to play with). I particularly paid attention to that last part. Were you able to indeed get full gigabit bandwidth out of that 2x SSD mirror?

This is reinforcing my suspicions quite a bit - single thread performance (CIFS) is being held up in the I/O pipeline (Constantin was discussing this with me a few weeks ago). I would surmise that ZFS needs a big pool of devices to keep IO latency down, otherwise single-thread performance suffers. That would explain not only why I gained a good deal of performance with zfs_vdev_max_pending=1 on my drives at home, but why your two SSDs manage to flood the wire with a single thread (latency per IO is much lower with an SSD, and even if ZFS stuffs their queues 10 deep, with two of them they can clear them out in time for any additional IO that may have been held up). End result - your single thread performance is better. Same thing happens when you give ZFS a huge number of disks - you have so many available devices to spread IOs across, your average latency stays low.

If you really want to swing for the fences to test this - put all 8 disks in 2-disk mirror. Yeah, you don't get as much storage. But I have a sneaking suspicion that what you gain in I/Os will more than make up for it, and solve your throughput dilemma all in one go, without having to touch any tuning variables.
 
You must log in or register to reply here.
Back
Top