<div dir="ltr">Nothing from your config snippet jumps out at me.<div><br></div><div>Some more info about the environment would be useful:<div><br></div><div>- What version of Samba?</div><div>- What's the hardware like?</div>
<div>- Is it a local FS, or is it an NFS export or something like that?</div><div>- What is "slow"?</div><div>- Are only transfers slow, or is it directory browsing? Both?</div><div>- Is the network getting saturated?</div>
<div>- Is there anything else going on that might be competing for IO?</div><div><br></div><div><br></div><div>The few times I've had complaints about Samba performance, it's been either an IO problem (backup running while people were hitting the server), DNS problems (server trying to do lookups and waiting for timeouts), poorly configured NFS export from another machine (wsize, rsize anyone?), or the network has simply been saturated (adding a second bonded interface solved that one). You may be noticing a theme in that the "samba problems" I've faced haven't been samba problems at all....</div>
<div><br></div><div>Hope this helps.</div><div><br></div><div>QH</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 3:26 PM, Mike Bean <span dir="ltr"><<a href="mailto:beandaemon@gmail.com" target="_blank">beandaemon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>At the risk of being really blunt, CLUE has always given me good advice in the past, so I thought I'd ask for some pointers. We have a situation at work where some of our code monkeys are complaining about the performance on a samba share mounted on a RHEL6.1 server; I'm trying to get a path out of them (the monkeys) so I can reproduce the issue, but in the meantime we're not seeing an appreciable performance problem or evidence of any large errors. We're thinking it's going to come down to Samba performance tuning, and wouldn't you know, I know exactly spit and nothing about Samba performance tuning.<br>
<br>Prayed at the google altar, as usual, and unless my questing has served me poorly, the biggest gains are to be had in TCP_NODELAY, which was already in our conf.<br><br></div>Here's our smb.conf:<br><br># Global parameters<br>
[global]<br> socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65535<br> encrypt passwords = Yes<br> log level = 2<br> log file = /var/log/samba.log.%m<br> guest account = admin<br>
security = share<br> kernel oplocks = no<br> dead time = 15 # Default is 0<br> getwd cache = yes<br> lpq cache = 30<br><br>[dqm_share]<br> comment = Some Share<br>
path = /xxxx/yyyyyyyyyyyy<br> public = yes<br> writable = yes<br> printable = no<br> create mask = 0664<br> directory mask = 0775<br># strict locking = no #commented out to test its effects<br>
<br></div>As I see it, there's not much tuning I can do without benchmarking the share and that's a whole new can of worms; so I thought I'd solicit suggestions/advice from CLUE members willing to give it.<br>
<br></div>thanks,<br><br>Mike Bean<br><div><div><br></div></div></div>
<br>_______________________________________________<br>
clue mailing list: <a href="mailto:clue@cluedenver.org">clue@cluedenver.org</a><br>
For information, account preferences, or to unsubscribe see:<br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/listinfo/clue</a><br></blockquote></div><br></div>