WinRM/WinRS job memory limits.
My tangential testing that began with my problems with commands run via WinRs during some distributed load testing are slowly unravelling back to the start. I now have a better build and test system for the server examples that ship as part of The Server Framework. I have a test runner that runs the examples with memory limits to help spot memory leak bugs and a test runner that checks for lock inversions. My test scripts are also more flexible and I’ve found a couple of bugs.
Today I used a variation on my job object based memory limiting test runner to investigate the original problem with commands spawned remotely using WinRS. Given that I had a test runner that could spawn a process and place it into a job object it was simple to adjust this so that the target process was instead broken out of any job that the test runner might be in; just add CREATE_BREAKAWAY_FROM_JOB
to the process creation flags and hope… This seemed to work so I then looked into reporting on the job that the test runner found itself in… Some simple calls to IsProcessInJob()
and QueryInformationJobObject()
with null jobs showed that the WinRS processes were being run inside of a job and that the limits (on my particular box) were as follows:
Job report for process: 10676
Process IS in a job
Flags: 0x2b08 -
JOB_OBJECT_LIMIT_ACTIVE_PROCESS
JOB_OBJECT_LIMIT_PROCESS_MEMORY
JOB_OBJECT_LIMIT_JOB_MEMORY
JOB_OBJECT_LIMIT_BREAKAWAY_OK
JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE
ActiveProcessLimit: 15
Affinity: 0x0
MaximumWorkingSetSize: 0
MinimumWorkingSetSize: 0
PerJobUserTimeLimit: 0
PerProcessUserTimeLimit: 0
PriorityClass: 32
SchedulingClass: 5
JobMemoryLimit: 157286400
ProcessMemoryLimit: 157286400
The problem limits being the job and process memory limits. Luckily the WinRS job has JOB_OBJECT_LIMIT_BREAKAWAY_OK
set so my attempt to break the target process free of these limits works fine.
I still haven’t found where any of this is documented, but at least I now don’t have to write my own remote process spawning code.