On Tue, 11 Mar 2014 18:42:28 +0100
Rolf Anderegg <rolf.anderegg@xxxxxxxx> wrote:
> Am 10.03.2014 20:52, schrieb Steve French:
> > There are some quick obvious things to check:
> > 1) since server is Samba - check if unix extensions negotiated and
> > check default rsize
> > (you can simply do cat /proc/mounts to see what was negotiated)
> >
> > 2) with unix extensions enabled, the maximum read size (and write
> > size) is much larger (which usually should help) so check if
> > differences in rsize or wsize can explain performance differences.
> >
> > 3) Similarly, increasing the maximum number of simultaneous requests
> > that the server can support for each client can have an impact on
> > performance ("max mux = 50" is the default in the server's smb.conf
> > but it can be increased if your workload has many requests from one
> > client at the same time).
>
> Thanks Steve for your helpful pointers.
> The first three points had no effect in my particular case.
>
> > 4) caching behavior changes - we moved to a much stricter caching
> > policy ("cache=strict") on later kernels so mounting with
> > "cache=loose," and allowing more efficient client side write caching
> > which is usually sufficient for most workloads, may also help.
>
> The cache mode was the nail that hit it. The cache modes had a dramatic impact
> on the CIFS mount read speed:
>
> ~29 MB/s with "cache=loose"
> <800 kB/s with "cache=strict"
>
> Having read the discussion that lead to this change in 3.7
> (https://lists.samba.org/archive/samba-technical/2012-April/083228.html), I now
> understand the reason for the default cache coherency strictness; albeit "a
> little slower" is quite an understatement in my case.
>
If cache=loose helps, then that suggests that you aren't getting
oplocks when you open files. That may or may not be expected depending
on the usage pattern, but that's probably where you should focus your
efforts. Do you have multiple machines or processes opening these files
at the same time?
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
