You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OS API is missing available memory call in NodeJS #31243
The free commands says actually that I have 1832 MBs available, which is the free amount + some part of the buff/cache that can be cleared directly when needed.
The free column should be small, since this is memory which is not used is simply wasted. Available memory is the amount of memory which is available for allocation to a new process or to existing processes.
$ free -m
total used free shared buff/cache available
Mem: 7971 5907 149 135 1914 1832
Swap: 9541 2122 7419
Knowing all this, the NodeJs OS API (var os = require('os')) only provides os.freemem and os.totalmem. The free memory NodeJS API call indeed shows the same value as what the free command gives me. But the OS API does NOT have any call like: os.availablemem or something simular.
Bottom-line: I'm missing the available memory call in NodeJS. Which is often way more useful.
This is ultimately a libuv issue because node calls uv_get_free_memory() and that in turn either reads /proc/meminfo (parsing the MemFree: field) or makes a sysinfo(2) system call (reading the freeram field.)
/proc/meminfo has a MemAvailable: field and sysinfo(2) lets you approximate it via the bufferram field so you could start by opening a libuv pull request if you want to move forward with this. On other platforms, you could just do:
I'm missing the available memory call in NodeJS. Which is often way more useful.
...if you plan on using it as an input signal for e.g. "can I start this memory-consuming program?" then it's probably the wrong approach - it's a snapshot of a dynamic situation, one that may have changed dramatically in the time window between the call and the exec.
OK, Yea let's see what's the best solution for fetching this number.
It's not for determining for starting memory heavy apps. I actually noticed this usage of 'free memory' on the system information page of Wekan, admin panel.
Wekan is an open source to-do manager, using nodejs. I was in panic when application was saying I only had about 100mb free of memory. But actually I think the available memory should be reported in these kind of instances.
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
Activity
bnoordhuis commentedon Jan 7, 2020
This is ultimately a libuv issue because node calls
uv_get_free_memory()and that in turn either reads/proc/meminfo(parsing theMemFree:field) or makes asysinfo(2)system call (reading thefreeramfield.)/proc/meminfohas aMemAvailable:field andsysinfo(2)lets you approximate it via thebufferramfield so you could start by opening a libuv pull request if you want to move forward with this. On other platforms, you could just do:That said...
...if you plan on using it as an input signal for e.g. "can I start this memory-consuming program?" then it's probably the wrong approach - it's a snapshot of a dynamic situation, one that may have changed dramatically in the time window between the call and the exec.
melroy89 commentedon Jan 7, 2020
OK, Yea let's see what's the best solution for fetching this number.
It's not for determining for starting memory heavy apps. I actually noticed this usage of 'free memory' on the system information page of Wekan, admin panel.
Wekan is an open source to-do manager, using nodejs. I was in panic when application was saying I only had about 100mb free of memory. But actually I think the available memory should be reported in these kind of instances.
mhdawson commentedon Jan 7, 2020
+1 on discussing in a TSC meeting before landing.
github-actions commentedon Mar 4, 2022
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
bnoordhuis commentedon Mar 4, 2022
The MemFree -> MemAvailable change was made in libuv/libuv#3351 and is available in v16.x+ so I think this issue is good to close.