# 🐛 Как отсутствующий блок `finally` съедал 300 МБ оперативной памяти на каждый неудачный скрапинг

Приложение испытывало периодические сбои Docker из-за утечки памяти в скрапере на основе Puppeteer. Скрапер, используемый для сбора данных о пропускной способности, часто выходил из строя из-за недоступных маршрутизаторов, что вызывало ошибки. Эти сбои приводили к появлению осиротевших процессов Chromium, потребляющих чрезмерный объем оперативной памяти на виртуальной машине Azure. Отсутствие надлежащего закрытия браузера в коде скрапера было основной причиной утечки памяти. В частности, функция `browser.close()` не гарантированно выполнялась после неудачных скрапингов. Это приводило к накоплению экземпляров Chromium и исчерпанию ресурсов виртуальной машины. Решение заключалось в использовании блока `try/catch/finally`, чтобы гарантировать, что `browser.close()` всегда выполнялся, и добавлении проверки на null в вызывающей функции. Внедрение исправления значительно снизило использование памяти и устранило осиротевшие процессы. Главный вывод заключается в том, чтобы всегда гарантировать очистку браузера Puppeteer с помощью `try/catch/finally`. Разработчики также должны избегать параллельного скрапинга и следить за процессами Chromium. Наконец, добавление таймаутов и проверок на null дополнительно повышает надежность кода. Предоставленный код также включает метод немедленной очистки осиротевших процессов Chromium и освобождения памяти.