Как не задушить self-hosted трекер под нагрузкой: серверный чек-лист
Первый узкий участок — не CPU, а I/O и база. Если трекер пишет сырые клики, постбэки и логи в один диск, под пиками он начнет терять задержки на записи. Разноси хранилище: приложение, БД, логи и бэкап-поток. Для БД важнее стабильная latency, чем «много ядер» на бумаге.
Дальше смотри на сеть и соединения: keep-alive, лимиты worker’ов, таймауты на API-гейтах и прокси. Если постбэк идет через длинную цепочку редиректов, сервер тратит ресурсы не на атрибуцию, а на ожидание. Сокращай маршрут, кэшируй справочники, выключай лишний уровень middleware.
Для высокой нагрузки критичны:
— очередь на запись событий, а не синхронный dump в БД
— отдельный сервер под базу с RAM под hot set
— ротация логов и агрегация метрик вне основного инстанса
— connection pooling для API и вебхуков
— мониторинг p95/p99, а не только средний CPU
Если трекер начинает «плавать», сначала чистим логи, проверяем постбэки. Потом ищем узкое место в диске, БД и очередях, а не лечим все апгрейдом железа. Data-driven подход или работа вслепую — выбор за тобой.
Трекер-стек
@tracker_stack_ubt
Как не задушить self-hosted трекер под нагрузкой: серверный чек-лист
Этот пост опубликован в Telegram-канале Трекер-стек. Подписаться можно по ссылке: @tracker_stack_ubt.