As a test I installed a 2016.3 agent on a VM server with 64 GB of RAM, using Automatically Manage for the page file. I did not encounter the same problem with 100 GB allocated to the hard drive. How much free space do the server's drives have? How many GB is the page file taking up?
It's really tricky to say what is happening here without more information.
1 of 1 people found this helpful
Bear in mind that the agent update may be the "trigger" rather than "the cause" here.
For instance, if your AV-program decides to do some in-depth check of every one of our binaries & touch every single files our binaries touch (often referred to as "process level scanning", but actual name differs by AV vendor), that can get pretty hefty ... and may not have triggered until now because of exclusions for the "old" files having had other hashes than the new ones (not sure if your exclusions are based on "filename" or "file + hash" for instance).
The page-file is purely managed by Windows - I'm just highlighting that there's potentially a variety of ways in which Windows ends up wanting "a lot" of space. Ultimately, I suspect you may need to chase down something from Microsoft that'll show / explain to you "what Windows is putting into the swap-file" (unfortunately, I'm not aware of such a tool - haven't had a need for one so far). I'm not sure how query-able (via tool or API) the swap-stuff is, but I'm assuming "someone" must've had something out there for it.
You can't be the first to run into "mysterious swap space" issues.
So - correlation != causation ... haven't heard of anything like this before, so my first instinct would be to try & figure out why Windows thinks it needs all this space (or at least - for what program) ... and that should be a key bread-crumb to then chase down hopefully (maybe the swap-file thing has some sort of debug-logging options... *fingers crossed*).
Thank you both for your responses.
What I have noticed on my tests is that the size of the pagefile depends on the size of RAM installed. Now, what happens is that the pagefile matches the size of the RAM, after LANDesk agent install and reboot.
If C: drive capacity - 100GB
RAM - 128GB
Pagefile - Windows managed
then the C: drive will run out of space, since it will try to create a 128GB pagefile on the disk.
One test that I've had happened on a newly installed machine with no patches yet, and it doesn't have a large pagefile. But when I installed LANDesk, pagefile grew to the size of RAM.
This issue isn't noticeable on machines that have little RAM.
OK - that's an interesting correlation.
Never heard or seen of anything like it in my 15+ years (which is why I think it's correlation - not causation).
Yeah - definitely need some sort of thing to figure out why Windows thinks it needs a page-file that big. We don't really control / make any kind of direct interaction with the page-file, so chances are this is a Windows-driven thing (why it believes it has to do this expansion is anyone's guess at this point). I'm still half suspecting something like AV or so to play a factor.
Curiouser and curiouser.
But yeah - first step is to research into what kind of logging / debugging opportunities exist (and I assume there are) around why Windows is doing this ridiuculous page-file expansion. That's really the key step from which to then trace/walk backwards.
Does the size of the pagefile reduce after time? It's not at all unusual for the pagefile to = the amount of installed RAM. For example if Windows thinks it may need to write a memory dump. But when it's windows managed the size should fluctuate as needed.
Do these servers have additional, larger drives for storage? You can set your OS pagefile to any drive you want. In my lab all of my core servers have magnetic drives for storage and SSD's for the OS drive, and I put the pagefile on the larger and cheaper HDD.