nodejs / nodejs/node

Increased CPU utilization after upgrading from Node.js v20.20.0 to v22.x

Ouverte
#62,939 8 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

stale
Langage dominant
JavaScript
Étoiles
122k
Forks
37.3k
Merge moyen
4 j 2 h
PR mergées (30 j)
283

Description

Version

v22.22.0 / v22.22.2 / 24.15.0

Platform
Oracle Linux 8 latest
Subsystem

No response

What steps will reproduce the bug?
  1. Run workload on Node.js v20.20.0 → CPU ~68–70%
  2. Upgrade to Node.js v22.22.x or 24.15.0
  3. Run identical workload (same TPS, config)
  4. Observe CPU increase (~86–88%)
  5. Revert to v20 → CPU returns to baseline
How often does it reproduce? Is there a required condition?

consistently 100% reproducable

What is the expected behavior? Why is that the expected behavior?

no bigger than 5% CPU degradation

What do you see instead?

20% CPU degradation

Additional information

We are observing a significant increase in CPU utilization after upgrading our runtime from Node.js v20.20.0 → v22.x (22.22.x), with no application-level changes.

A/B testing strongly indicates the regression is tied to the Node.js runtime upgrade rather than application logic.

Impact

  • ~20% relative CPU increase observed
  • Consistent across multiple test runs
  • No functional regression, but clear performance degradation

Environment

  • Node.js versions:
    • v20.20.0 (baseline)
    • v22.22.0 / v22.22.2
  • Workload:
    • High-throughput service (~17–18K TPS)
    • Distributed/multi-node setup
  • Runtime flags:
    • --max-semi-space-size=256
    • --max-old-space-size=3072

Observed Behavior

Scenario Node Version CPU Utilization
Baseline v20.20.0 ~68–70%
Upgraded runtime v22.22.x ~86–88%
v22.x + --max-semi-space-size=16 v22.22.x ~88%
Reverted runtime v20.20.0 ~68%

Key Findings

  1. Strong correlation with Node.js version

    • Reverting v22 → v20 reduces CPU by ~12–20%
    • No application changes between runs
  2. Memory tuning did not help

    • Adjusting --max-semi-space-size showed no improvement
    • Lower values increased GC frequency without reducing CPU
  3. Latest v22 versions do not fix the issue

    • Testing with v22.22.2 shows same behavior
  4. Maglev likely not the cause

    • Disabled by default in Node ≥22.9.0
    • Issue persists on versions where Maglev is disabled

What Was Ruled Out

  • Application-level regression
  • Load/TPS variation
  • GC tuning via semi-space adjustments
  • Early v22-only issues

Suspected Cause

Likely related to runtime-level changes introduced in Node.js v22, such as:

  • V8 upgrade (v11.x → v12.x)
  • JIT execution changes
  • GC or memory management differences
  • libuv / stream internal changes

Reproduction Steps (High-level)

  1. Run workload on Node.js v20.20.0 → CPU ~68–70%
  2. Upgrade to Node.js v22.22.x
  3. Run identical workload (same TPS, config)
  4. Observe CPU increase (~86–88%)
  5. Revert to v20 → CPU returns to baseline

Additional Notes

  • No explicit Node.js release notes mention this regression
  • Issue is reproducible under high throughput
  • Not observed in lower TPS environments (≤5–7K TPS)

##Questions##

  • Are there known CPU regressions or behavior changes in Node.js v22 / V8 12.x?
  • Are there recommended runtime flags or GC tuning options for high-throughput workloads in v22?
  • Any guidance on mitigating CPU increase when upgrading from v20 → v22?
  • Will an upgrade to the latest available version of Node.js v26 fix this issue?

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par reproduire la charge de travail à haut débit signalée sur Node.js v20.20.0 et v22.22.x sous Oracle Linux 8 avec les flags de mémoire indiqués, en conservant des TPS et une configuration identiques. Comparez l’utilisation du CPU et documentez une charge de travail minimale et reproductible, ou isolez le changement du runtime responsable ; aucun fichier source ni test n’est nommé dans l’issue.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
javascript, linux, node.js
Domaine
backend, performance
Type d'issue
Bug
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
Active
Clarté
À clarifier
Accessibilité débutants
35/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.