[clue] samba performance tuning?

Mike Bean beandaemon at gmail.com
Wed Sep 18 09:56:27 MDT 2013


Think Quentin might've been right when he suggested DNS.  Started talking
to the codemonkeys, turned up the logging.   They told me, it's happening
right now!   Lots of "authentication for user failed" no such user.

A while back we melted down our old NIS server by accident, Had problems
with authentication ever since.   yp.conf was pointing to an alias - which,
when doing nslookup, DID have the right IP address for the new nis
server.   Commented out the line and just put the IP address of the new NIS
server in there anyway.  service ypbind restart.

tail -f started moving again.   Users checking their access.
samba CPU use went way down,

checked nswitch.conf.  Tweaked a couple entries that were out of whack,
codemonkeys are going to let me reboot it in a couple minutes.


On Wed, Sep 18, 2013 at 9:48 AM, Quentin Hartman <qhartman at gmail.com> wrote:

> Graphite++. I use it for a number of application-level metrics at work and
> it's suuuuuuper nice.
>
>
> On Wed, Sep 18, 2013 at 9:41 AM, Chris Fedde <chris at fedde.us> wrote:
>
>> Add interface bytes in/out and error counts to your monitoring so you can
>> look back and see if there are any interesting issues there. Also if you
>> have smart switches add monitoring there too.  It's hard to know what
>> changed when you don't have some kind of baseline.
>>
>> I use nagios and nagios graph for monitoring right now but I'm starting
>> to get more interested in using Graphite for the time series data.
>>
>>
>> On Tue, Sep 17, 2013 at 8:57 PM, Mike Bean <beandaemon at gmail.com> wrote:
>>
>>> Don't believe it,  I've been messing with it for a while, but I don't
>>> understand the appeal. GPFS just feels like another open source project IBM
>>> bought up so they could take credit for the work.  (Used to be mmfs).
>>>
>>>
>>> On Tue, Sep 17, 2013 at 4:51 PM, Quentin Hartman <qhartman at gmail.com>wrote:
>>>
>>>> I'd throw some instrumentation on the server hosting the samba share
>>>> and see if you're simply saturating the links (users <-> samba <-> gpfs )
>>>> if nothing else has changed and the storage performance is generally within
>>>> "ok" tolerances. I've not worked with gpfs before, sounds like a cool tech.
>>>>
>>>> I like Ganglia for general system instrumentation like this. It can
>>>> take some voodoo to make it work, but the graphs and trends it creates are
>>>> usually worth it. If you need something quicker / lighter, collectd works
>>>> well, but I haven't used it in a long time. As i recall it needs a plugin
>>>> to do net stats.
>>>>
>>>> QH
>>>>
>>>>
>>>> On Tue, Sep 17, 2013 at 4:26 PM, Mike Bean <beandaemon at gmail.com>wrote:
>>>>
>>>>> Samba version 3.6.5
>>>>>
>>>>> "What is slow?"
>>>>> A good, worthy question to ask.  I don't have an answer yet because
>>>>> I'm still trying to get in touch with the users.   When I pull up that
>>>>> share, it's not appreciably degraded to me.  I consider it fine for use.
>>>>>
>>>>> Others
>>>>>
>>>>> That's the part that gets a little complicated.  The host system
>>>>> itself is running on a gpfs cluster, but there's been exactly zero
>>>>> complaints about gpfs access.  The cluster, for all intents and purposes,
>>>>> seems fine, the only issue they're having is the rate of access on this one
>>>>> share for the last few weeks or so, and there's not been any appreciable
>>>>> change that we were aware of that took place approximately two weeks ago.
>>>>>
>>>>> (I did notice smbstatus didn't work until I softlinked our .conf file
>>>>> to user/local/samba/lib...  flimsy, I admit it,.... a coincidence?)
>>>>>
>>>>>
>>>>> On Tue, Sep 17, 2013 at 3:52 PM, Quentin Hartman <qhartman at gmail.com>wrote:
>>>>>
>>>>>> Nothing from your config snippet jumps out at me.
>>>>>>
>>>>>> Some more info about the environment would be useful:
>>>>>>
>>>>>> - What version of Samba?
>>>>>> - What's the hardware like?
>>>>>> - Is it a local FS, or is it an NFS export or something like that?
>>>>>> - What is "slow"?
>>>>>> - Are only transfers slow, or is it directory browsing? Both?
>>>>>> - Is the network getting saturated?
>>>>>> - Is there anything else going on that might be competing for IO?
>>>>>>
>>>>>>
>>>>>> 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....
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>> QH
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 17, 2013 at 3:26 PM, Mike Bean <beandaemon at gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Here's our smb.conf:
>>>>>>>
>>>>>>> # Global parameters
>>>>>>> [global]
>>>>>>>         socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=65536
>>>>>>> SO_SNDBUF=65535
>>>>>>>         encrypt passwords = Yes
>>>>>>>         log level = 2
>>>>>>>         log file = /var/log/samba.log.%m
>>>>>>>         guest account = admin
>>>>>>>         security = share
>>>>>>>         kernel oplocks = no
>>>>>>>         dead time = 15                     # Default is 0
>>>>>>>         getwd cache = yes
>>>>>>>         lpq cache = 30
>>>>>>>
>>>>>>> [dqm_share]
>>>>>>>    comment = Some Share
>>>>>>>    path = /xxxx/yyyyyyyyyyyy
>>>>>>>    public = yes
>>>>>>>    writable = yes
>>>>>>>    printable = no
>>>>>>>    create mask = 0664
>>>>>>>    directory mask = 0775
>>>>>>> #  strict locking = no                  #commented out to test its
>>>>>>> effects
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Mike Bean
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> clue mailing list: clue at cluedenver.org
>>>>>>> For information, account preferences, or to unsubscribe see:
>>>>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> clue mailing list: clue at cluedenver.org
>>>>>> For information, account preferences, or to unsubscribe see:
>>>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list: clue at cluedenver.org
>>>>> For information, account preferences, or to unsubscribe see:
>>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list: clue at cluedenver.org
>>>> For information, account preferences, or to unsubscribe see:
>>>> http://cluedenver.org/mailman/listinfo/clue
>>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list: clue at cluedenver.org
>>> For information, account preferences, or to unsubscribe see:
>>> http://cluedenver.org/mailman/listinfo/clue
>>>
>>
>>
>> _______________________________________________
>> clue mailing list: clue at cluedenver.org
>> For information, account preferences, or to unsubscribe see:
>> http://cluedenver.org/mailman/listinfo/clue
>>
>
>
> _______________________________________________
> clue mailing list: clue at cluedenver.org
> For information, account preferences, or to unsubscribe see:
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20130918/84bbbfcc/attachment.html 


More information about the clue mailing list