Perf issue: Increased footprint in benchmark on PPC64 on 6.8.0

[CurryKitten]

We run a series of benchmarks on node across multiple platforms - one of which is to run AcmeAir and have some throughput over a given time.

We found that that when going from 6.7.0 to 6.8.0 there was a quite significant increase in memory footprint (typically an increase of approx 40%), but this only affected Linux PPC64 & PPC64LE

We pinned the cause of the change down to PR #8100, and it can be replicated/solved by swapping out the fs.js and module.js file between the releases before building. This issue obviously continues in to 6.9.0/6.9.1.

What we haven't been able to do is pin down exactly what is in the additional footprint. We've taken heap dumps of both 6.7.0/6.9.1 runs, and they look very close in terms of object allocation and memory usage. Looking at /proc//maps of the runs just seems to show there is more native memory in use. I've been unable to determine why this change is only affecting PPC64/PPC64LE

[gibfahn]

I guess cc/ @addaleax in case there's any obvious reason.

[addaleax]

So, what is added in #8100 is a new cache, and it’s understandable that that increases the footprint slightly, but it shouldn’t make huge differences. I would be curious if using a WeakMap would make a difference here.

I've been unable to determine why this change is only affecting PPC64/PPC64LE

Yeah, that seems weird… maybe it’s a V8 thing?

[gibfahn]

Also cc/ @gireeshpunathil

[gireeshpunathil]

OK, recreated the issue with simplified steps, and compared the memory footprint at different stages of the run: (first row for good node, and second for bad)

start-up

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
23910 gireesh     20   0 1192832  59456  23104 S   0.0  1.6   0:00.60 node 
24091 gireesh     20   0 1193024  57088  24320 S   0.0  1.6   0:00.57 node

after issuing loaddb.sh

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                  
24226 gireesh     20   0 1228672  96000  23168 S   0.0  2.6   0:04.13 node
24091 gireesh     20   0 1234048  77760  24320 S   0.0  2.1   0:04.07 node

After one full iteration of jmeter:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                  
23746 gireesh     20   0 1224704  96000  23168 S   0.0  2.6   0:04.19 node 
23629 gireesh     20   0 1234240 107456  24320 S   0.0  3.0   0:04.13 node   

As can be seen, there is no change in the bootup, but the footprint increases when transactions are carried out. Investigating further.

[Trott]

@gireeshpunathil Any additional information to report? (Should this remain open? Does it still affect current Node.js?)

[apapirovski]

This hasn't had an update in nearly 1.5 years. I'm going to close out but feel free to reopen if you have any new updates.

[gireeshpunathil]

I haven't looked at this issue since my last update, so out of the context. @CurryKitten - do you have the environment / tools / steps that is necessary to test this if need be?