[gpfsug-discuss] number of SMBD processes

[Ouwehand, JJ]

Hello Christof,

Thank you very much for the explanation. You have point us in the right direction.


Vriendelijke groet,

Jaap Jan Ouwehand
ICT Specialist (Storage & Linux)
VUmc - ICT

[VUmc_logo_samen_kiezen_voor_beter]



Van: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] Namens Christof Schmitt
Verzonden: maandag 2 oktober 2017 19:13
Aan: gpfsug-discuss at spectrumscale.org
CC: gpfsug-discuss at spectrumscale.org
Onderwerp: Re: [gpfsug-discuss] number of SMBD processes

Hello,

the short answer is that the "deadtime" parameter is not a supported parameter in Spectrum Scale.

The longer answer is that setting "deadtime" likely does not solve any issue. "deadtime" was introduced in Samba mainly for older protocol versions. While it is implemented independent of protocol versions, not the statement about "no open files" for a connection to be closed. Spectrum Scale only supports SMB versions 2 and 3. Basically everything there is based on an open file handle. Most SMB 2/3 clients open at least the root directory of the export and register for change notifications there and the client then can wait for any time for changes. That is a valid case, and the open directory handle prevents the connection from being affected by any setting of the "deadtime" parameter.

Clients that are no longer active and have not properly closed the connection are detected on the TCP level:

# mmsmb config list | grep sock
socket options                    TCP_NODELAY SO_KEEPALIVE TCP_KEEPCNT=4 TCP_KEEPIDLE=240 TCP_KEEPINTVL=15

Every client that no longer responds for 5 minutes will have the connection dropped (240s + 4x15s).

On the other hand, if the SMB clients are still responding to TCP keep-alive packets, then the connection is considered valid. It might be interesting to look into the unwanted connections and possibly capture a network trace or look into the client systems to better understand the situation.

Regards,

Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com>  ||  +1-520-799-2469    (T/L: 321-2469)


----- Original message -----
From: "Ouwehand, JJ" <j.ouwehand at vumc.nl<mailto:j.ouwehand at vumc.nl>>
Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>
To: "gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>" <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Cc:
Subject: [gpfsug-discuss] number of SMBD processes
Date: Mon, Oct 2, 2017 6:35 AM


Hello,



Since we use new “IBM Spectrum Scale SMB CES” nodes, we see that that the number of SMBD processes has increased significantly from ~ 4,000 to ~ 7,500. We also see that the SMBD processes are not closed.



This is likely because the Samba global-parameter “deadtime” is missing.



------------

https://www.samba.org/samba/docs/using_samba/ch11.html

This global option sets the number of minutes that Samba will wait for an inactive client before closing its session with the Samba server. A client is considered inactive when it has no open files and no data is being sent from it. The default value for this option is 0, which means that Samba never closes any connection, regardless of how long they have been inactive. This can lead to unnecessary consumption of the server's resources by inactive clients. We recommend that you override the default as follows:



[global]

    deadtime = 10

------------



Is this Samba parameter “deadtime” supported by IBM?





Kindly regards,



Jaap Jan Ouwehand
ICT Specialist (Storage & Linux)

VUmc - ICT



[VUmc_logo_samen_kiezen_voor_beter]




_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI&m=LCAKWPxQj5PMUf5YKTH3Z0zW9cDW--1AO_mljWE3ni8&s=y0FjQ5P-9Q7YjxyvuNNa4kdzHZKfrsjW81pGDLMNuig&e=


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20171004/e8826c0f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 6431 bytes
Desc: image001.gif
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20171004/e8826c0f/attachment.gif>