Increased CPU utilization after upgrading from Node.js v20.20.0 to v22.x
Personne n'a encore pris cette issue.
- 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?
- Run workload on Node.js v20.20.0 → CPU ~68–70%
- Upgrade to Node.js v22.22.x or 24.15.0
- Run identical workload (same TPS, config)
- Observe CPU increase (~86–88%)
- 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
-
Strong correlation with Node.js version
- Reverting v22 → v20 reduces CPU by ~12–20%
- No application changes between runs
-
Memory tuning did not help
- Adjusting
--max-semi-space-sizeshowed no improvement - Lower values increased GC frequency without reducing CPU
- Adjusting
-
Latest v22 versions do not fix the issue
- Testing with v22.22.2 shows same behavior
-
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)
- Run workload on Node.js v20.20.0 → CPU ~68–70%
- Upgrade to Node.js v22.22.x
- Run identical workload (same TPS, config)
- Observe CPU increase (~86–88%)
- 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
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- 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