The old "low on memory" issue

Associate
Joined
19 Dec 2010
Posts
153
Location
Swansea, Wales
Hi Guys,

I am a fairly tech savvy person but I can't seem to sort this one out (tempted to format :( ).
I am getting the "Close programs to prevent information loss. Your computer is low on memory." error pop up when I am just doing my day to day work, I work from home, so generally I run several chrome tabs, Microsoft Outlook, and Skype for Business

I have done the usual, run CCleaner, uninstalled anything unnecessary, altered page file between off, and 4gb... no difference

I have 320gb used and 144gb free on my SSD.
If anyone can suggest common causes, or point me in the right direction i'd be much appreciated!

PC Specs:
Gigabyte Gaming 7 mobo
16gb 2600 corsair RAM
i7 6700k
512gb Samsung 850 evo SSD
GTX 1070 (Asus ROG)

Error_low_on_memory.jpg
 
What is your Page file set to? Ideally needs to be left on system managed, or at least to the same size as the amount of RAM you have installed.
 
Hi both,

It is fully up to date, i run regular windows update and driver update.
I will set pagefile to be managed by system, generally I have set it to equal my RAM.
See if that helps, thanks very much for your quick responses - I will let you know later/tomorrow if changing pagefile has helped :)
 
Last edited:
It's the driver/software for your Killer NIC device that's causing the memory leak. Update it.

Google 'killer nic memory leak" or ndu.sys memory leak if you want more info on it. You can also disable the ndu service which these crappy drivers have an issue with by creating a .reg file and adding it to your registry.

Open notepad and copy/paste the code below. Save the text file to your computer then right click on it and rename it with a .reg extension. Now when you double-click this file, it will make changes to the registry.

Content for this fix:
Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ndu]
"Start"=dword:00000004
 
Last edited:
I will set pagefile to be managed by system, generally I have set it to equal my RAM.

I know you've probably read the "set page file to equal your physical memory" from somewhere as it's widespread advice for some reason but it's honestly bad advice. Think about it for one moment, the less physical memory you have the bigger the page file you will need but setting your page file to equal your physical memory does the complete opposite.

It would be better advice to deduct your physical memory amount from say 64GB and set your page file that way (ie. 64GB-16GB physical memory=48GB page file, or 64GB-32GB physical memory=32GB page file), using that method whatever system you have you will have 64GB of combined physical and virtual memory.. but to be honest I would just leave the page file alone and let Windows manage it because it can't seem to cope very well without it.
 
Last edited:
Be aware that task manager only tells part of the story when it comes to ram use. There is a built in windows tool that allows you to get more info but I can't remember what it is called
 
I know you've probably read the "set page file to equal your physical memory" from somewhere as it's widespread advice for some reason but it's honestly bad advice. Think about it for one moment, the less physical memory you have the bigger the page file you will need but setting your page file to equal your physical memory does the complete opposite.

It would be better advice to deduct your physical memory amount from say 64GB and set your page file that way (ie. 64GB-16GB physical memory=48GB page file, or 64GB-32GB physical memory=32GB page file), using that method whatever system you have you will have 64GB of combined physical and virtual memory.. but to be honest I would just leave the page file alone and let Windows manage it because it can't seem to cope very well without it.

I set the page file to 512mb min max 8192 on several hundred machines, not 1 person has reported memory issues in 5 years...

if you have 16gb of ram and are not running cad / some other specialist software and run out of memory something is broken and needs fixing...
 
I set the page file to 512mb min max 8192 on several hundred machines, not 1 person has reported memory issues in 5 years...

if you have 16gb of ram and are not running cad / some other specialist software and run out of memory something is broken and needs fixing...


Disagree - most "not enough memory" issues can normally be resolved by switching back to System managed.

While setting the min to 512Mb max to 8Gb may work - not sure what it really achieves. Either set it System managed and forget about it, or set it to the same Min and Max values (e.g. so it never allocates any more, and in theory doesn't spend time allocating), that are more than the RAM you have.


The key generally is that pagefile should be large enough to contain all of the system RAM - it isn't just about how much RAM you have, but for some tasks the system needs to back some of the allocated ram with page file regardless - e.g. memory mapped files)
 
You are all wrong :p

If you are going to set it manually then for an SSD it doesn't make much odds in terms of dynamic allocation, while for a HDD you'd want a static size.

You want to set atleast 1024MB as the Initial size as sometimes Windows for some reason just assumes (or has to do operations before it can adjust the pagefile) it can write out 600-700MB worth i.e. dealing with minidumps or some application tails and if it can't odd things can happen* or it will spit out an error. Much larger than 1024MB potentially can be doing needless additional writes and using up space on an SSD where it can be limited (though these days its probably less of an issue) but if you have a larger SSD then no harm setting it higher.

Max size mostly will depend on your usage and there is no real penalty to setting it very large - I generally set 8192MB and it doesn't cause any problems but ostensibly you want enough space for most of your RAM and a bit of overhead for "proper" operation.

Setting a large static size on an SSD usually just uses up a ton of disc space, doesn't provide any realworld performance benefits and potentially adds more wear to the SSD - which isn't a big deal with a good modern SSD but still no point using up writes needlessly (one reason for this is that pagfile writes when they do happen are often quite large - for some reason it works a lot with blocks and will write out entire blocks even when only using a small amount of that block - not sure if its due to a performance optimisation when working in that way with mechanical HDDs).

Disagree - most "not enough memory" issues can normally be resolved by switching back to System managed.

Mostly because people don't understand how to set the pagefile manually and do it wrong or just follow the windows recommendations which are also usually dead wrong.




* This can also be an issue if you just disable it entirely.
 
Last edited:
I know you've probably read the "set page file to equal your physical memory" from somewhere as it's widespread advice for some reason but it's honestly bad advice. Think about it for one moment, the less physical memory you have the bigger the page file you will need but setting your page file to equal your physical memory does the complete opposite.

It would be better advice to deduct your physical memory amount from say 64GB and set your page file that way (ie. 64GB-16GB physical memory=48GB page file, or 64GB-32GB physical memory=32GB page file), using that method whatever system you have you will have 64GB of combined physical and virtual memory.. but to be honest I would just leave the page file alone and let Windows manage it because it can't seem to cope very well without it.

This sounds utterly bizarre to me. I can't fathom a time you would ever need a 32GB page file let alone 48!?
 
can you explain

Much larger than 1024MB potentially can be doing needless additional writes

why are there needless writes ?

If min, is right-sized, to what you typically need, should be optimal ? avoiding re-sizing.
to-wit - as disco_p alludes first thing (engineering principles :rolleyes:) is to find out why you have the low memory warning
process explorer or rammap utilities can help, and will show
- virtual size of each processes (working set, as per screen capture is not adequate to analyse)
- size of non-pooled memory being used by drivers eg. Killer NIC hypothesis.
check on web for more info eg

specifically the 11% shown in capture is misleading, the first chrome process may have a working set of 30.7MB, but the process virtual size maybe 100MB and that is what can contribute to low memory warnings.
 
Last edited:
can you explain



why are there needless writes ?

Mostly due to the archaic nature of the implementation (I assume using certain layout and blocks, etc. to try to get optimal performance on mechanical HDDs where otherwise the data could end up fragmented - random writes causing a significant performance drop over sequential), sometimes due to end user configuration i.e. if they have the pagefile setup to flush on shutdown, etc. or other processes that use security methods to ensure sensitive data doesn't end up stored in the pagefile indefinitely.
 
Even if the system has an SSD will the OS know ? and avoid clearing a contiguous space on the SSD for paging file (which may then, ironically, itself, be moved by the ssd wear-levelling algorithm).
However if the paging files remains allocated between boots (unless you have a flush), the writes overhead of specifying a too large paging file may not be problematic, and specifying a right sized min paging file up front, may avoid IO intensive task of allocating it dynamically later.

I have wondered about creating a (right sized) partition explicitly for the paging file, that way you also avoid a scenario where the disk has filled up, not leaving space for paging file growth.
 
I'm also including storage space considerations in there - though these days less and less people have <250GB SSDs. For most people they won't see the pagefile grow above 1024MB in normal use - if your normal usage has a higher peak commit then it would be worth setting it larger. I definitely don't recommend going lower due to some things like crash dumps and the odd weird Windows behaviour when it can't allocate virtual memory.
 
This sounds utterly bizarre to me. I can't fathom a time you would ever need a 32GB page file let alone 48!?

I have had a 90GB page file in use once. I was studying data from a Neural Network and the dataset generated a page file this size, this was with 32GB ram also. To get the performance I spanned the page file over 3 SSD's then one of the SSD's was killed off due to writes!
 
Ok that motivated me to create a performance monitor tracking the following


<Counter>\Memory\Pool Nonpaged Bytes</Counter>
<Counter>\Memory\System Driver Resident Bytes</Counter>
<Counter>\Memory\Pool Paged Bytes</Counter>
<Counter>\Memory\Commit Limit</Counter>
<Counter>\Paging File(_Total)\% Usage</Counter>
<Counter>\Memory\Committed Bytes</Counter>
<Counter>\Process(avguard)\Virtual Bytes</Counter>
hopefully will show : if the nvidia or other drivers are making big memory demands, track Avira/antivirus, and follow gradual commit increase ...
I typically re-boot every ~7 days due to low memory myself
 
Back
Top Bottom