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-boun...@spectrumscale.org [mailto:gpfsug-discuss-boun...@spectrumscale.org] Namens Christof Schmitt Verzonden: maandag 2 oktober 2017 19:13 Aan: gpfsug-discuss@spectrumscale.org CC: gpfsug-discuss@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.schm...@us.ibm.com<mailto:christof.schm...@us.ibm.com> || +1-520-799-2469 (T/L: 321-2469) ----- Original message ----- From: "Ouwehand, JJ" <j.ouweh...@vumc.nl<mailto:j.ouweh...@vumc.nl>> Sent by: gpfsug-discuss-boun...@spectrumscale.org<mailto:gpfsug-discuss-boun...@spectrumscale.org> To: "gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>" <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@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=
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
