Slow write speed on fast hardware. SMB/CIFS bottleneck?

Status
Not open for further replies.

Mlovelace

Guru
Joined
Aug 19, 2014
Messages
1,111
It didn't make any difference. (I added them as loader tunables, yes?)
Those should have been added as sysctl tunables (it's a drop-down selection in the tunables dialog) not loader.

Edit: Forgot to mention you can just edit the values you added as loader to sysctl, then reboot. You don't have to delete and re-add them.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Those should have been added as sysctl tunables (it's a drop-down selection in the tunables dialog) not loader.

Edit: Forgot to mention you can just edit the values you added as loader to sysctl, then reboot. You don't have to delete and re-add them.

So the big thing here that strikes me is that this is a situation where @Mlovelace has a Chelsio but you have an X540, which is known to be a bit twitchy. That should be getting serviced by ixgbe (ix0/ix1), so maybe try (one at a time)

hw.ix.max_interrupt_rate=65536
hw.ix.enable_aim=0
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
Getting about 850MB/s write 215 MB/s read with 5 x SATA HDDs stripe
About 700MB/s write 210MB/S read with single SSD as stripe
About 800 MB/s write 215MB/s read with 8 SAS as raidz2

Thats with a synthetic test that emulates large single file video (blackmagic design disc speed test).
Real file transfers are capped at 450 write 210 read as limit of the local workstations SSD - I can't get on the workstations with the NVMe M.2 drives at the moment.
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
So the big thing here that strikes me is that this is a situation where @Mlovelace has a Chelsio but you have an X540, which is known to be a bit twitchy. That should be getting serviced by ixgbe (ix0/ix1), so maybe try (one at a time)

hw.ix.max_interrupt_rate=65536
hw.ix.enable_aim=0
OK, I've not got the two ports bonded yet so just on ix0
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
So the big thing here that strikes me is that this is a situation where @Mlovelace has a Chelsio but you have an X540, which is known to be a bit twitchy. That should be getting serviced by ixgbe (ix0/ix1), so maybe try (one at a time)

hw.ix.max_interrupt_rate=65536
hw.ix.enable_aim=0
Neither had any perceivable effect.
Read speed seems to be limited now on all drives (synthetic test or real file transfer).
 

Mlovelace

Guru
Joined
Aug 19, 2014
Messages
1,111
Neither had any perceivable effect.
Read speed seems to be limited now on all drives (synthetic test or real file transfer).
My guess would be that your read speeds are bottle-necked by the filer's limited about of memory. With only 16GB of RAM you will have a relatively small amount of ARC to work with. You can run some iperf tests to make sure the 10Gbe network is symmetric; if the network is symmetric with iperf then I'd look at the RAM as the culprit.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Also, reads are going to tend to be slower because they're the thing you have to actually go out and read from disk on demand. Writes can be faster because you don't need to actually retrieve something from the disk, you just need to know where the free blocks are, and then queue up a whole bunch of writes.
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
iperf say 9.3 Gb/s each way.
Ordering another 16GB memory today.

How do Qnap+synology boxes get away with so little memory on their 10GbE products. Can they actually reach particularly high throughputs?
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
I tried the tunables on my Mk1 server (desktop components - an i5/12GB ram + intel x540 nic but has the 3 x SSD stripe in at the moment )
Read speed was unchanged (800 GB/s), but write speed jumped up from 160GB/s to 700GB/s

BestRead.PNG BestWrite.PNG
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
iperf say 9.3 Gb/s each way.
Ordering another 16GB memory today.

How do Qnap+synology boxes get away with so little memory on their 10GbE products. Can they actually reach particularly high throughputs?

It's a matter of design. FreeNAS uses ZFS, which was built from the ground up to assume memory is cheap, because it was intended to be run on a big Sun Solaris server. This allows ZFS to do some interesting and amazing things, including going MUCH faster than the underlying hardware might otherwise allow, because of things like the ARC. However, in order to get that, you have to toss lots of resources at it. If you under-resource it, it goes rather more poorly.

Those smaller NAS boxes, they don't have the complexity of ZFS. A typical hard drive might be able to read files at 200MBytes/sec, and two mirrored might go at 400MBytes/sec, so with a simple filesystem like EXT3, there's an easy, low-resource way for a SoC based NAS to be able to perform ~400MBytes/sec reads and ~200MBytes/sec writes for sequential access, but the trick is, you will *never* go faster than what the underlying hard drives support. Things like disk seeks bring that down; it is possible to bring a SoC NAS to its knees on some platter based HDD's with just a few hundred IOPS worth of traffic.

With ZFS, the system might be sustaining a hell of a lot more traffic than that, and it doesn't necessarily need to be sequential traffic. If it can be held in ARC/L2ARC, it requires no seeks to fetch. Writing to the pool, even "random" updates tend to be aggregated and written to contiguous space, so you can see a ZFS filer pulling off some amazing stunts with traffic that'd melt even a high end traditional array like an EqualLogic or something like that.

ZFS isn't magic. It just trades off one thing for another.
 

Miles Tudor

Dabbler
Joined
Apr 10, 2016
Messages
13
ZFS isn't magic. It just trades off one thing for another.
Gotcha.

I've got another 16GB of memory arriving tomorrow. Lets see if that improves it any further.
I'm pretty happy with 700MB/s ish each way so I'll put this into production soon.
Is there anything else you want to try?
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Yeah, once you have the extra memory, try doubling the 16777216 values (33554432) and see if that makes any improvement. You're getting close to a point, though, where you may also be needing to make client side tweaks, and I'm not really the right person to advise on that.
 

depasseg

FreeNAS Replicant
Joined
Sep 16, 2014
Messages
2,874
What sort of tuning has been done to it on the 10G side?

The X540 isn't thrilling but can probably be made to work fine.

Can I inflict either pain or pleasure? Try adding the following for tunables.

kern.ipc.soacceptqueue=256
kern.ipc.maxsockbuf=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.recvspace=4194304
net.inet.tcp.recvbuf_inc=4194304
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.sendspace=4194304
net.inet.tcp.sendbuf_inc=4194304

Bet it flies. Or crashes. Maybe both. Might also need to stab CIFS with some adrenaline, I don't recall if CIFS tries to manipulate the socket settings itself or not. More memory will help. Shoot for 64GB, 128GB is pricey (~$800) but a nice performance booster.

[Side note: Are these (or similar) tunables needed for 10G? Should they go into your 10G Primer?]
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
[Side note: Are these (or similar) tunables needed for 10G? Should they go into your 10G Primer?]

I'm actually trying to investigate what actually makes sense here. Raising these numbers stupid-big is counterproductive, but obviously there's some set that will make sense. The problem is that I don't use 10G in the same way that many others do, the network here isn't built for raw throughput. I don't have an easy way to lab up a high performance 10G testing environment without buying new hardware or downing some production gear.

What I'd really kinda like to do is to have some guidance in the 10G primer, but also to rewrite autotune and offer it as a patch.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
As someone who works on TrueNAS systems regularly, I've found that virtually no tuning needs to happen on the 10Gb side*.

The asterisk is because TrueNAS systems use specific Chelsio cards, and those tunables etc specific to Chelsio cards won't translate if you use another brand (Intel, for example). In my own testing, copying files over CIFS, NFS as well as doing iSCSI 10Gb really hasn't needed much tuning to be fast. CIFS has some limitations in terms of saturating 10Gb with a single user on a single machine, but those issues currently appear to be more due to CPU bottlenecks than anything else.

All of this considered, I really don't think much tuning is "necessary" to get good speeds. Of course, there's always ways to optimize for cases that go outside of what your typical home/small business use (high latency, relatively low bandwidth VPN connections, etc.) and other end-case scenarios.
 

Rand

Guru
Joined
Dec 30, 2013
Messages
906
While I have no scientific proof I always had to tune 10GBe to go beyond 200MB/s on FreeNas (9.1+) with Intel Cards. For me tuning was required as well at the client (windows) side (but thats fairly simple as its part of the windows/intel driver)

I totally agree that having one set of values for everybody without regard to specific hardware layout will not be the best approach - therefore I am looking forward to the improved Autotune very much - or in the meantime if CJ will be able to apply his thorough investigation skills on the various settings then an updated set of useful values and potential implications:)
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Status
Not open for further replies.
Top