Network Open File Handle Limit

Question

I hope I'm posting this under the right category.

While centralizing our storage for our DevOps pipeline, I've come across the issue that Windows has a limit on Maximum open files per session (found on powershell by the net config server command). Our network storage is mounted on each of our Windows Build Farm machines, but due to this open file handle restriction, all of our builds are failing. Is there a way to increase this limit, since local handles can reach up to several million? Or is there a way around this, perhaps by tricking windows into percieving the mounted drive as local? I do know it is possible on *nix OS to change this type of value, but I have found no documentation on Microsoft's side. I would hope that Microsoft might perhaps have a solution to this as well, since rebasing our build farm to Linux would be an inconvienence.

I do find it strange that the Maximum open files per session is affecting the build farm agents as clients/workstation, since this value is only being displayed for net config server and is not given on net config workstation. But I assume this value is used for each network connection sessions. The centralized storage is running on a new Synology NAS, if that information might be helpful. Let me know if any further information is needed to better assist.

Thanks for any assistance.

Answer 1

Hello Bo,

The specification "[MS-SRVS]: Server Service Remote Protocol" says:

sv599_sessopens: Specifies the number of files that can be open in one session. The range of values MUST be from 1 to 16384, inclusive.<20>

<20> Section 2.2.4.46: The allowed range of values on Windows NT 4.0 is 1 to 2,048, inclusive.

There are various hints that this is an SMB server parameter.

What makes you think that your build failures are related to this setting?

Gary

Answer 2

Hello Bo,

Have you used ETW (Event Tracing for Windows) to investigate the problem? It should be possible to definitely show whether the problem is caused by server or client limitations and perhaps even identify the routine that detects and reports the problem. Analysing the trace data can be tricky, but I am happy to help.

Here is an example of the types of trace data that can be obtained:

Gary

Answer 3

Hello Bo,

I wrote a short test program to open 20,000 files on an SMB share and it ran without error. To be sure that 20,000 plus handles were concurrently open (i.e. no major bugs in the test program), I monitored the open handles count with perfmon:

I think that there is some doubt about the real cause of your problem.

Gary