Increased CPU utilization after upgrading from Node.js v20.20.0 to v22.x
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- JavaScript
- Star
- 122k
- Fork
- 37.4k
- Merge trung bình
- 4 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 272
Mô tả
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?
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện workload thông lượng cao đã được báo cáo trên Node.js v20.20.0 và v22.22.x dưới Oracle Linux 8 với các memory flag được liệt kê, giữ TPS và cấu hình giống hệt nhau. So sánh mức sử dụng CPU và ghi lại một workload tối thiểu, có thể tái hiện, hoặc cô lập thay đổi runtime chịu trách nhiệm; issue không nêu tên file mã nguồn hay test nào.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- javascript, linux, node.js
- Lĩnh vực
- backend, performance
- Loại issue
- Lỗi
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Cần làm rõ
- Mức phù hợp với người mới
- 35/100