Memory leak seemingly caused by typescript __awaiter helper
See original GitHub issueWe have been investigating a memory leak in our GraphQL server implementation and believe we have a root cause. We eliminated a lot of the network stack and other external things, and still have a leak.
There is a large retained memory in a Generator
. We believe this is caused by https://github.com/microsoft/TypeScript/issues/36056, which is also referenced in https://stackoverflow.com/questions/58875158/nodejs-memory-growth-memory-leak-in-system. This matches our findings. We do not use any generators in our code, and we compile with babel using latest, which uses async/await
natively.
Looking at the compiled Apollo source, it is littered with __awaiter
.
I am wondering if Apollo can address this by releasing a version that does not use __awaiter
and relies on native async/await?
We do not have many options to address this issue otherwise.
I can add additional information here from the heap dumps if necessary. I believe a test case can be created, unfortunately I do not have one readily available because I have been using our own internal (closed source) Apollo GraphQL server implementation.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:8 (4 by maintainers)
Top GitHub Comments
V8’s https://github.com/v8/v8/commit/d3a1a5b6c491, with the fix for this memory leak, has landed (after being delayed by the v12.15.0 security release) in Tuesday’s v12.16.0 as https://github.com/nodejs/node/commit/c004cf51c6 in https://github.com/nodejs/node/pull/31691.
That’s all to say, I hope you can upgrade to v12 again and be free of this! We’ll still bump the ECMAScript compilation target in the next major version.
I’m going to close this, but please feel free to ping me if it’s not in fact fixed. Thanks so much for reporting this originally! And a salute to @4n3ver for identifying the culprit. ❤️
I want to close the loop. We have downgraded to Node 10 and we are seeing stable memory usage in production.