TFTL · Технічна діагностика · для Avalon · Червень 2026
Підсумок глибокого технічного розслідування простими словами: що сталося, чому, і який план дій, щоб сайт витримав рекламний трафік.
Коротко
Сервер впав не від напливу відвідувачів, а тому що його налаштування памʼяті не залишали жодного запасу. Ми знайшли першопричину, перевірили її з усіх боків і підготували конкретний план, щоб до старту кампанії сервер був стабільним і швидким.
11 GB
зайвих службових даних накопичилось у базі
177тис.
повільних запитів проаналізовано в логах
10
окремих причин навантаження знайдено
3
невідкладні виправлення до кампанії
Простими словами
Памʼять сервера — як робочий стіл. Ми наказали базі зайняти більше місця, ніж є на столі.
Поки роботи мало — наче нормально. Але база поступово розкладає свої «папери», місце закінчується, і коли потрібен ще бодай аркуш — усе валиться на підлогу. Саме це й сталося: за кілька діб памʼять заповнилась під стелю, і система аварійно зупинила базу.
8.25 GB > 7.3 GB
Базі дозволили зайняти до 8.25 GB памʼяті на сервері, де її всього 7.3 GB — та ще й половину з них займають інші програми. Запас памʼяті = нуль.
Крива росту перед падінням
Памʼять бази повільно росла впродовж ~4 діб, поки вільного місця на сервері не лишилось зовсім. Падіння — це не різкий стрибок, а накопичення.
Безперервний моніторинг памʼяті веде Zabbix на окремому сервері. Ця крива реконструйована за подією аварії та замірами після перезапуску (точки «✓» — фактично виміряні). Точні графіки Zabbix додамо за наявності доступу до панелі моніторингу.
Що ми знайшли
Причина №1 · головна
Базі дозволено зайняти 8.25 GB при наявних 7.3 GB. Запасу немає — і будь-яке коливання навантаження валить сервер. Виправляється зміною одного рядка налаштувань.
Причина №2
Службовий модуль Telescope у бойовому режимі записує кожен клік і кожен запит — ~14 записів щосекунди. За ~2 доби це 2.8 млн рядків і 11 GB зайвих даних, які перевантажують базу. Він потрібен лише для розробки.
Причина №3
Найпопулярніша сторінка — каталог квартир (11 580 відкривань/добу) — щоразу перебирає й сортує весь список наново, бо бракує правильного «покажчика». Під трафіком це головне гальмо.
Причина №4
На тій самій машині працює GitLab та інші сервіси, які забирають ще ~1.5 GB. Для бойової бази даних це ризиковане сусідство — стратегічно її варто винести окремо.
Глибина дослідження
Розслідування велося за інженерною методикою: спершу докази, потім висновки. Кожну версію перевіряли окремими незалежними перевірками.
Ми перевірили й відкинули 4 хибні версії — включно з нашою власною першою гіпотезою. Те, що ви читаєте, витримало спробу спростування.
Чому це важливо саме зараз
Сьогодні сайт уже в спокої завантажує сервер на дві третини памʼяті. Рекламний трафік — це кратне зростання навантаження. Ось що станеться:
×5
трафіку — і сервер починає аварійно перезапускатись під сталим напливом
×10
трафіку — гарантоване падіння бази та хвиля помилок у відвідувачів
×50
трафіку — сервер лягає за секунди, ще до пікового інтересу до реклами
Важливо: вузьке місце — це памʼять, а не потужність процесора. Тому додати «трохи більше CPU» не врятує — потрібні саме виправлення нижче.
План дій
Невідкладно — до старту кампанії
Привести налаштування памʼяті у відповідність до сервера
Опустити ліміт памʼяті бази нижче обсягу сервера — зʼявиться реальний запас. Робочі дані повністю влазять, тож швидкість не постраждає. Один рядок налаштувань + перезапуск.
Зняти ризик напливу з’єднань і прискорити каталог
Обмежити одночасні з’єднання до розумного рівня, зменшити «апетит» кожного, і ввімкнути кешування каталогу на Cloudflare — щоб реклама не била напряму в базу.
Вимкнути запис Telescope у бойовому режимі
Зупинити цілодобовий запис службових даних у базу — це найбільший драйвер її роздування та зайвого навантаження.
Стабілізація та швидкодія
Прибрати 11 GB зайвих даних і навести лад у резервних копіях
Регулярно чистити службові таблиці й ущільнити базу — повернемо дисковий простір і знімемо навантаження з нічних бекапів.
Прискорити каталог квартир індексом
Було: сторінка пересортовує весь список щоразу. Стане: миттєва видача за готовим покажчиком — без зайвої роботи бази.
Прискорити перевірку броні квартир
Було: щохвилини база перечитує всю таблицю квартир. Стане: точковий пошук за індексом — у рази менше навантаження.
Гігієна та стратегія
Оптимізувати важкі вивантаження (фіди) та новини
Кешувати рідкозмінні дані й не вантажити по 20 тисяч записів у памʼять там, де це не потрібно.
Винести базу даних на окремий сервер
Стратегічний крок: розділити бойову базу та систему складання коду — щоб вони більше не конкурували за памʼять.
Очікуваний результат
Усі зміни оборотні й безпечні. На час дослідження ми нічого не змінювали на сервері — лише читали дані. Застосування — за вашим погодженням, із контролем результату.