[clue] samba performance tuning?
Quentin Hartman
qhartman at gmail.com
Wed Sep 18 09:48:49 MDT 2013
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20130918/f86f5b6d/attachment-0001.html
More information about the clue
mailing list