Add direct access to rss without iterating pages #34291

Aschen · 2020-07-10T07:13:48Z

Accessing the rss value through process.memoryUsage().rss can be expensive because this method will also generate memory usage statistics by iterating on each page.

The overhead can be quite huge when a lot of memory has been allocated, consider this snippet:

rss-access.js

const ar = []

for (let i = parseInt(process.argv[2], 10); i--; ) {
  ar.push({
    very: 'This is a lot of datazzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz',
    big: {
      object: 'I m blue tadoudidadouda I m blue tadoudidadouda I m blue tadoudidadouda'
    }
  })
}

let start = process.hrtime();

process.memoryUsage().rss

let hrend = process.hrtime(start);

console.log(hrend[1] / 1000000, 'memoryUsage()');

start = process.hrtime();

process.rss()

hrend = process.hrtime(start);

console.log(hrend[1] / 1000000, 'rss()')

$ ./out/Release/node test.js 1000
0.361226 memoryUsage()
0.05305 rss()

$ ./out/Release/node test.js 10000000
1.208851 memoryUsage()
0.075418 rss()

This PR aim to offer an API to access directly the rss value in a (almost) constant time.

// Don't
process.memoryUsage().rss;

// Do
process.memoryUsage.rss();

EDIT: 2020-07-13

Following @bnoordhuis proposal I added a rssOnly option to process.memoryUsage instead of adding the new process.rss method:

process.memoryUsage({ rssOnly: true });
{
  rss: 36270080,
  heapTotal: 0,
  heapUsed: 0,
  external: 0,
  arrayBuffers: 0
}

EDIT: 2020-08-11

Following @jasnell and @bnoordhuis advices the rss value is now accessible through process.memoryUsage.rss

See #33384

Checklist

[/] make -j4 test (UNIX), or vcbuild test (Windows) passes (Unix is ok but unfortunately I don't have a windows computer)
tests and/or benchmarks are included
documentation is changed or added (I will add the documentation once we agree on the API)
commit message follows commit guidelines

bnoordhuis

For your (and everyone else's) consideration, perhaps:

the os module is a more appropriate place for a new method?
instead of a new method, make process.memoryUsage() take an optional { rssOnly: true } options object?

bnoordhuis · 2020-07-10T08:57:45Z

test/parallel/test-memory-usage.js

@@ -43,4 +43,5 @@ if (r.arrayBuffers > 0) {
         `${after.external} - ${r.external} >= ${size}`);
  assert.strictEqual(after.arrayBuffers - r.arrayBuffers, size,
                     `${after.arrayBuffers} - ${r.arrayBuffers} === ${size}`);
+  assert.strictEqual(process.memoryUsage().rss, process.rss());


This is not reliable because the RSS can change between the two calls.

bnoordhuis · 2020-07-10T09:01:13Z

src/node_process_methods.cc

+  // Get the double array pointer from the Float64Array argument.
+  CHECK(args[0]->IsFloat64Array());
+  Local<Float64Array> array = args[0].As<Float64Array>();
+  CHECK_EQ(array->Length(), 1);
+  Local<ArrayBuffer> ab = array->Buffer();
+  double* fields = static_cast<double*>(ab->GetBackingStore()->Data());
+
+  fields[0] = rss;


Suggested change

// Get the double array pointer from the Float64Array argument.

CHECK(args[0]->IsFloat64Array());

Local<Float64Array> array = args[0].As<Float64Array>();

CHECK_EQ(array->Length(), 1);

Local<ArrayBuffer> ab = array->Buffer();

double* fields = static_cast<double*>(ab->GetBackingStore()->Data());

fields[0] = rss;

args.GetReturnValue().Set(static_cast<double>(rss));

Float64Array is overkill if you're returning a single floating-point value. You can expose the method directly, without going through a JS method first.

Aschen · 2020-07-10T12:01:34Z

@bnoordhuis

IMHO the os module is not the right place for that because as far as I understand it's information about the whole OS and not the currently running process.

But I like your idea of a { rssOnly: true } option object 👍

BridgeAR · 2020-07-10T12:31:03Z

Note: I'm not happy with the process.rss API, if someone have a better suggestion I'm in 👍

It would be possible to use process.memoryUsage.rss();. I am not certain if this might be confusing for some people though.

Aschen · 2020-07-10T12:47:13Z

It would be possible to use process.memoryUsage.rss();. I am not certain if this might be confusing for some people though.

I thought about this one but I couldn't figure an easy way to document it since it will involve a property on a function which is a function

Aschen · 2020-07-13T09:43:40Z

@bnoordhuis I updated the PR with the rssOnly option so you may want to review the code again

lib/internal/process/per_thread.js

src/node_process_methods.cc

bnoordhuis · 2020-07-13T15:24:22Z

test/parallel/test-memory-usage.js

@@ -24,6 +24,15 @@
 const common = require('../common');
 const assert = require('assert');

+const result = process.memoryUsage({ rssOnly: true });


Suggested change

const result = process.memoryUsage({ rssOnly: true });

process.memoryUsage();

const result = process.memoryUsage({ rssOnly: true });

Then re-run the test. :-)

(You need to clear the other fields when rssOnly=true or they'll contain stale values.)

bnoordhuis · 2020-07-13T15:24:39Z

test/parallel/test-worker-memory.js

@@ -47,5 +47,7 @@ for (let i = 0; i < numWorkers; ++i) {
                'Unexpected memory overhead: ' +
                util.inspect([startStats, finishStats]));
    }
+
+    assert.strictEqual(process.memoryUsage().rss, process.rss());


Leftover from the previous iteration of the PR? There's no process.rss() anymore.

jasnell · 2020-07-14T14:21:46Z

@Aschen :

It would be possible to use process.memoryUsage.rss();. I am not certain if this might be confusing for some people though.

I thought about this one but I couldn't figure an easy way to document it since it will involve a property on a function which is a function

Take a look at the documentation for process.hrtime.bigint() for an example of this pattern. I think I'd prefer the process.memoryUsage.rss() approach also.

Aschen · 2020-07-21T04:45:13Z

@bnoordhuis Are you also ok with the process.memoryUsage.rss() approach?

bnoordhuis · 2020-07-21T08:51:57Z

@Aschen Sure, there's precedent, e.g., fs.realpath.native().

doc/api/process.md

Aschen · 2020-11-09T08:11:11Z

I got a strange error on the file node_snapshop.cc in the compilation even if I didn't modify this file 🤔

https://github.com/nodejs/node/pull/34291/checks?check_run_id=1371318709

LD_LIBRARY_PATH=/home/runner/work/node/node/out/Release/lib.host:/home/runner/work/node/node/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /home/runner/work/node/node/out/Release/obj/gen; "/home/runner/work/node/node/out/Release/node_mksnapshot" "/home/runner/work/node/node/out/Release/obj/gen/node_snapshot.cc"
Unknown external reference 0x55a462331140.
<unresolved>
Illegal instruction (core dumped)
node.target.mk:26: recipe for target '/home/runner/work/node/node/out/Release/obj/gen/node_snapshot.cc' failed
rm 2ad06b2c9baade6b27c5c82cdcc7af11c369378d.intermediate 9ac559b3661ef3e3ae7143f36ccc6691e578b31c.intermediate 02a486ff0aa87df511c38b125409357fdc559df2.intermediate 5e4cf980d3dc346b9b9ba01305d21285c5aecbf4.intermediate
make[2]: *** [/home/runner/work/node/node/out/Release/obj/gen/node_snapshot.cc] Error 132
Makefile:104: recipe for target 'node' failed
make[1]: *** [node] Error 2
Makefile:530: recipe for target 'build-ci' failed
make: *** [build-ci] Error 2
Error: Process completed with exit code 2.

doc/api/process.md

Flarna · 2020-11-09T16:58:32Z

doc/api/process.md

@@ -1593,6 +1593,26 @@ Will generate:
 When using [`Worker`][] threads, `rss` will be a value that is valid for the
 entire process, while the other fields will only refer to the current thread.

+The `process.memoryUsage()` method iterate over each page to gather
+informations about memory usage which can be slow depending on the


I find can be slow quite vague - in special as a caller can't do anything to avoid this to test if it will be slow.
Are we talking about µs, ms, or seconds here?

It depends on the program size in memory. Access the RSS take a fixed time but compute heap statistics is quite costly since you have to iterate over every memory page.
The difference can be in seconds. (see the benchmark in the PR description)

The sample in PR description prints milli seconds not seconds so not that bad.
I tried it local on my machine and even for 4GB heaps it was below 0.2ms. But for sure the rss only API is much faster.

At the beginning I have done this PR because I found very strange results while benchmarking promises (#33384).
So even if the difference is not that huge it can be misleading in some cases

src/node_process_methods.cc

Flarna · 2020-11-10T10:23:03Z

I got a strange error on the file node_snapshop.cc in the compilation even if I didn't modify this file

I think you have to add registry->Register(Rss) in RegisterProcessMethodsExternalReferences (node_process_methods.cc).

Flarna · 2020-11-17T19:43:09Z

@nodejs/process

src/node_process_methods.cc

Accessing the rss value through memoryUsage() can be expensive because this method will also generate memory usage statistics by iterating on each page. This commit intend to offer a more direct access to rss value. Refs: #33384 PR-URL: #34291 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: James M Snell <jasnell@gmail.com>

Refs: #34291 PR-URL: #36781 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

PR-URL: #36768 Refs: #34291 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com>

PR-URL: #36769 Refs: #34291 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: #36766 Refs: #34291 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

PR-URL: #36839 Refs: #34291 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: James M Snell <jasnell@gmail.com>