Skip to content

Perf issue: Increased footprint in benchmark on PPC64 on 6.8.0 #9764

Closed
Closed
Perf issue: Increased footprint in benchmark on PPC64 on 6.8.0#9764
Labels
memoryIssues and PRs related to Node.js memory management or memory footprint.performanceIssues and PRs related to the performance of Node.js.ppcIssues and PRs related to the Power architecture.

Description

@CurryKitten
CurryKitten
opened on Nov 23, 2016

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

Activity

  1. mscdex
    added
    ppcIssues and PRs related to the Power architecture.
    memoryIssues and PRs related to Node.js memory management or memory footprint.
    on Nov 23, 2016

  2. gibfahn commented on Nov 23, 2016

    @gibfahn
    gibfahn
    on Nov 23, 2016
    Member

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

  3. addaleax commented on Nov 23, 2016

    @addaleax
    addaleax
    on Nov 23, 2016
    Member

    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?

  4. gibfahn
    added
    performanceIssues and PRs related to the performance of Node.js.
    on Nov 23, 2016

  5. gibfahn commented on Nov 24, 2016

    @gibfahn
    gibfahn
    on Nov 24, 2016
    Member

    Also cc/ @gireeshpunathil

  6. gireeshpunathil commented on Dec 7, 2016

    @gireeshpunathil
    gireeshpunathil
    on Dec 7, 2016
    Member

    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.

  7. Trott commented on Jul 15, 2017

    @Trott
    Trott
    on Jul 15, 2017
    Member

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

  8. apapirovski commented on Apr 11, 2018

    @apapirovski
    apapirovski
    on Apr 11, 2018
    Contributor

    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.

  9. apapirovski
    closed this as completedon Apr 11, 2018

  10. gireeshpunathil commented on Apr 11, 2018

    @gireeshpunathil
    gireeshpunathil
    on Apr 11, 2018
    Member

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    memoryIssues and PRs related to Node.js memory management or memory footprint.performanceIssues and PRs related to the performance of Node.js.ppcIssues and PRs related to the Power architecture.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions