-
-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3.0.0 leaks memory #379
Comments
clinicjs will help you debugging this: |
It's kind of impossible to help with this without a way to reproduce the problem you are facing. Could you create a small server that reproduce your problem? |
Thanks for the clinic suggestion. I’ll run clinic benchmark with both 3.0.0 and 2.7.13 and compare the results to find a way to produce a test.
—
Matt Bishop
… On Jan 15, 2022, at 7:44 AM, Matteo Collina ***@***.***> wrote:
It's kind of impossible to help with this without a way to reproduce the problem you are facing. Could you create a small server that reproduce your problem?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
Clinic can’t measure benchmark’s runs. I resorted to using node -trace_gc with benchmark and saw some differences in GC between 3.0.0 and 2.7.13 but no smoking gun.
I’ll go back to my app and see what I can do to narrow it down there. The difference between the two versions is immediate. Load tests run forever with 2.7.13 but crash within a minute on 3.0.0. GC shows the newer version, garbage is not getting collected like the old version which stays between 63 and 75mb under load.
I am using fastify for the API framework.
—
Matt Bishop
… On Jan 15, 2022, at 9:21 AM, Matthew Bishop ***@***.***> wrote:
Thanks for the clinic suggestion. I’ll run clinic benchmark with both 3.0.0 and 2.7.13 and compare the results to find a way to produce a test.
—
Matt Bishop
>> On Jan 15, 2022, at 7:44 AM, Matteo Collina ***@***.***> wrote:
>>
>
> It's kind of impossible to help with this without a way to reproduce the problem you are facing. Could you create a small server that reproduce your problem?
>
> —
> Reply to this email directly, view it on GitHub, or unsubscribe.
> You are receiving this because you authored the thread.
|
How are you using this module? You should work to create a minimal, reducible example of your leak just with a simplified case so that we can help. Note that heap profiling show you what function is allocating this much and what kind of data is leaking. |
Since the major change from We may need to identify a new way to initialize the |
I think it can be confirmed the issue should be related to how we use Line 878 in 89c63a6
Line 1228 in 89c63a6
Line 1245 in 89c63a6
Based on the lines above and the information inside the issue. |
Good spot! Looks like we should definitely fix this. It seems this function is really incorrect too: Lines 88 to 107 in 89c63a6
I think the solution should be to move the Line 44 in 7ae2611
|
@mcollina I wrote that function, at the time it was a hack to get around |
Prerequisites
Last working version
2.7.13
Stopped working in version
3.0.0
Node.js version
16.13.2
Operating system
macOS
Operating system version (i.e. 20.04, 11.3, 10)
12.1
💥 Regression Report
I have been using fast-json-stringify directly in a web app the streams JSON data into ndjson. This app is about a year old. The app runs in 512mb RAM and has been stable, memory-wise, for the entire year.
Earlier this week I upgraded to fast-json-stringify 3.0.0 and my load tests have been causing the app to fail with OOM errors. I profiled the memory using Chrome dev tools and found that the validateSchema method was consuming more and more RAM as the test progressed before crashing due to inability to allocate memory.
I reverted back to 2.7.13, reran my tests and they passed as before.
Steps to Reproduce
I tried using leakage to create a test (https://www.npmjs.com/package/leakage) but it would not compile on my environment.
Expected Behavior
Same memory usage as 2.7.13.
The text was updated successfully, but these errors were encountered: