Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR improves memory monitoring on Linux-based hosts.
Node's
os.freemem
doesn't represent how much ram is available for processes. It returns what is shown incat /proc/meminfo
MemFree
, which is calculated from memory used by different applications + buffers + Linux disk in-memory caching. This means that's it's ok to haveMemFree
close to 0 on Linux host, because Linux can always unload disk caches and buffers from memory without any harm to running processes. To clarify this, Linux developers added new field in/proc/meminfo
calledMemAvailable
. This filed represent real free memory capacity for applications on host, without including disk caching.So, if monitoring should answer the question
Is it enough free RAM on my host to run an application?
it should useMemAvailable
parameter. That's why I think it should be better to switch memory monitoring on this parameter, instead ofMemFree
.Unfortunately, there is no way to get
MemAvailable
fromnode.os
, but thankfullysysteminformation
is already in use, and you can getMemAvailable
there.Also here is a little bit more information about
free vs available
https://www.linuxatemyram.com/