![]() Also most Chrome-based libraries like CEF were always leaky.Īlso, as always, I added "type": "module", to my package.json so my nodejs (v16) will have imports support. In future versions of Puppeteer or underlying Chrome probably RAM leak will receive appropriate true fix, but assuming how long this issue is there, I think it might never happen. Code which leaksįirst of all start a new NPM project and install puppeteer: npm init npm i puppeteerįor me this code installed latest version which is 14.2.1 (you can check this in package.json). The fix described here could be adopted to absolutely any issue caused by RAM leaks in external imported library, including casing when you need to pass data to/from child process. We will make some simple experiments which confirm RAM leaks and then show how to workaround them. In this post I will show how you can easily overcome such problems by using child processes. Basically, assumptions and suspicions based on developer's experience in combination with code experiments work here as well. What you might get is a huge amount of RAM reported by htop utility after couple of days of your process uptime and you will have no clues what caused it. There are reliable methods to understand it but we will not cover them in this post. Having lack of RAM on server is a terrible thing because it activates operation system's out-of-memory killer who starts killing any processes randomly causing service downtime or even touching system processes which destroy server connectivity until full reboot.Īnother challenge is to find which code or library caused the leak in your app. But when you use it in a long-running process your server monitoring tool starts reporting "RAM is almost full". This library is API-controlled wrapper over Chromium which allows you to load page, walk through selectors, make some clicks on site or enter some values in inputs on page. One of them is very popular Nodejs package called puppeteer which is a great tool for crawling, user-imitation and testing tasks. Library can be unreplaceable in own niche, have very simple API, and satisfy you in all other aspects but consume more and more RAM when you use it in long-running process.įor example, one of the most popular cases here are all libraries which are based on headless Chromium. Especially if they have some underlying native bindings. ![]() Nevertheless, all of these does not really save them from RAM leaks on a long run. They might work perfectly, have a lot of downloads on NPM and stars on the GitHub. RAM leaks is very common problem which happens in a big amount of external libraries.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |