Repository navigation
Support percentage-based --max-old-space-size option for dynamic memory allocation #57447
Description
Activity
--max-old-space-size is a V8 flag, not a Node.js flag. It's technically possible to intercept and rewrite V8 flags but we've never done that before and personally I see no reason to start now.
Also, percentages seems like a bad idea in general. What happens when I start two node processes with
--max-old-space-size=80%? Boom, is what.Not a hypothetical. The flag is allowed in
NODE_OPTIONS. Child processes inherit it.Hi bnoordhuis,
I appreciate your points about the potential complexities of using --max-old-space-size with percentages, especially when dealing with multiple Node.js processes. However, I believe there are compelling reasons to consider allowing this functionality.
One significant advantage of supporting percentage values is the potential for dynamic resource allocation, similar to what's seen with Vertical Pod Autoscaler (VPA) in Kubernetes. By utilizing percentages, we can enable applications to adapt their memory usage based on the available resources at runtime. This flexibility could lead to more efficient memory management, especially in containerized environments where resource limits can change.
Moreover, allowing percentage-based configurations could help developers optimize their applications without the need to hardcode specific values, which might not suit varying production environments. It empowers users to maintain better control over their applications' memory usage, potentially improving performance and resource utilization.
Thanks for your input!
Hi bnoordhuis,
While the implications of more config permutations cannot be ignored, percentage-based is a pattern reliably utilized in production environments in other platforms, notably Java with
-XX:MaxRAMPercentage=nn%. Allowing percentages would let our JS developers unify these configs across the enterprise.Are there popular frameworks/libaries for Node which fork processes in their standard functionality?
Are there popular frameworks/libaries for Node which fork processes in their standard functionality?
Yes, plenty. The built-in
clustermodule, for starters.I'd like to emphasize that even with fixed values, we can still encounter similar problems.
When we set a fixed value for --max-old-space-size, if both the parent and child processes are given a substantial allocation, the combined memory usage can easily exceed the available system memory, leading to crashes or performance issues.
Moreover, this feature shouldn't introduce any regressions or breaking changes; hence, any existing codebase won't break
I'd like to emphasize that even with fixed values, we can still encounter similar problems.
Yes, obviously.
To set expectations: don't expect anyone to work on this. Open a pull request yourself if you want to see it happen. Keep in mind there's no guarantee it's going to get merged.
In your pull request you're going to have to answer the question what 80% really means. 80% of total system memory? What if the process is in a cgroup? Does it make sense to limit yourself to 80% of the cgroup's memory limit? If yes, why? If not, why not?
I'd like to emphasize that even with fixed values, we can still encounter similar problems.
Yes, obviously.
To set expectations: don't expect anyone to work on this. Open a pull request yourself if you want to see it happen. Keep in mind there's no guarantee it's going to get merged.
In your pull request you're going to have to answer the question what 80% really means. 80% of total system memory? What if the process is in a cgroup? Does it make sense to limit yourself to 80% of the cgroup's memory limit? If yes, why? If not, why not?
Thanks, @bnoordhuis , for your feedback!
One last question, if I may: would it be more fitting to try to contribute this effort to the V8 engine instead of Node.js?
V8 is the better place, the question is if they'd accept it.
I reached out to the V8 community regarding this feature, and they indicated that it would be more appropriate to contribute it to the Node.js project. You can find the relevant discussion here.
In light of this feedback, I intend to proceed with contributing this feature to the Node.js project. Any assistance or guidance on this would be greatly appreciated!
Reacted by Miloš Lapiš, Bruno Ferreira, Joel van Velden and Yonatan Arbel@bnoordhuis @Asaf-Federman You are right. The containerized environments and their dynamic ability to scale the amount of memory resources for each container are a long-term, underutilized potential, especially if those environments can scale the allocated memory in minutes and charge based on exact consumption. It is a growing, serious disadvantage of the Node.js platform.
I'm still working on the percentage implementation for --max-old-space-size. A functional version is now complete, but it requires code cleanup, proper testing, etc before a pull request can be submitted.
Reacted by prd-da-doReacted by Phuong Nguyen and Yonatan Arbel- added 2 commits that reference this issue
on Jul 23, 2025 - added a commit that references this issue
on Jul 28, 2025 - added a commit that references this issue
on Aug 8, 2025 - added a commit that references this issue
on Aug 20, 2025 - added a commit that references this issue
on Oct 17, 2025 @Asaf-Federman, will the percentage implementation need a pod restart? The The latest Kubernetes version allows in-place resource modifications without recreating the pod. https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
@Asaf-Federman, will the percentage implementation need a pod restart? The The latest Kubernetes version allows in-place resource modifications without recreating the pod. https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
While I haven't tested this specific scenario, a container/process restart would likely still be required.
The reason is that the percentage calculation happens before the Node.js process is started, and the resulting fixed value (in MB) is what's actually passed to the V8 engine via the --max-old-space-size flag. The V8 engine itself isn't aware of the percentage or the cgroup limit, only the fixed value it was given at launch.
@Asaf-Federman, will the percentage implementation need a pod restart? The The latest Kubernetes version allows in-place resource modifications without recreating the pod. https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
While I haven't tested this specific scenario, a container/process restart would likely still be required.
The reason is that the percentage calculation happens before the Node.js process is started, and the resulting fixed value (in MB) is what's actually passed to the V8 engine via the --max-old-space-size flag. The V8 engine itself isn't aware of the percentage or the cgroup limit, only the fixed value it was given at launch.
If that were possible, it would have been a very cool feature to use with Kubernetes VPA. As soon as VPA starts taking advantage of the in-place resource modifications feature, we can use VPA in auto mode that would change resources without pods restarting, and Node.js/V8 would adapt the percentage to the new resources requests without restarting the application.
What is the problem this feature will solve?
Currently, --max-old-space-size requires a fixed memory value in MB. However, in containerized environments (Docker, Kubernetes, etc.), available memory can vary. A percentage-based option would allow Node.js to dynamically adjust its memory usage based on the environment, reducing the risk of OOMKills while optimizing performance.
Why is this needed?
What is the feature you are proposing to solve the problem?
Introduce a new syntax for --max-old-space-size, allowing it to accept percentages of total system memory (e.g., --max-old-space-size=80%).
For example:
node --max-old-space-size=80% app.jsIf the system has 4GB RAM, this would set 3.2GB (80%) as the old space size.
If the system has 1GB RAM, it would set 800MB (80%).
What alternatives have you considered?