Прилетает мне баг значит - "нажимаем сформировать отчет в pdf, отчет в статусе "формируется", висит так сутки уже, ниче не происходит дальше" ❌
Смотрю код, докидываю логов в месте формирования отчета. Нахожу, что для отчета выполняется последовательно +- 15 запросов SQL, причем бОльшая часть сложных. Какие-то выполняются 3-5 минут, а какие-то 2-3 часа. А последний вообще через 40 минут падает с ошибкой превышения лимита массива 🤯
Ну я, как профессиональный разработчик, иду сразу
Предложения от индексирования до использования подзапросов. Тут не буду прямо подробно описывать все методы, которые я испробовал, допилил и проверил (а это до 4 часов теста на каждый вариант...). скажу лишь одно - ни хера не изменилось 😭
Но зато удалось выяснить почему так долго. Тут стоит наверное рассказать, о чем вообще отчет - отчет по трафику и событиям за выбранный период в разрезе протоколов и узлов, по дефолту фильтры это последняя неделя, все узлы, все события, ничего такого...
...Пока мы не начинаем понимать, что происходят джойны 24 млн записей соединений с фильтрами по нескольким тысячам протоколов ☝️
Оптимизировать тут нечего, тупо упираемся в лимит памяти.
Варианты:
1. Хотфикс - это увеличивать в конфиге посгри эту память, но это временное решение, так как объемы данных только растут постоянно.
2. Перед формированием отчета отправлять запрос в БД на количество соединений и на уровне фронта предупреждать или не давать формировать отчет с сообщением, что слишком много данных, уменьшите выборку по фильтрам.
3. Решение уровня фичи - переделывать формат отчета. Мне удалось сформировать его за 3 дня и получить 500+ страниц pdf 😄 То есть уменьшит количество информации в нем.
Сам запрос я не буду вам показывать, он не страшный и не подлежит оптимизации. Уверяю, что там ничего такого в нем) А вот опыт поиска проблем в SQL я получил в этот раз хороший и полезный ❤️