Почему одна и та же БД летает на staging и тормозит в проде
Знакомо? На staging сервере — отклик 100мс, на проде — секундные таймауты. Хотя база одна и та же, схема такая же. Что не так?
Вот 5 частых причин:
1. Разный объём данных
На staging — 10k строк, на проде — 10 млн. Индексы, которые "и так нормально", внезапно перестают справляться.
2. Отсутствие/различие индексов
DevOps мог не раскатить нужные индексы в прод. Или, наоборот, staging набит экспериментальными индексами.
3. Параметры конфигурации БД
work_mem, shared_buffers, max_connections — часто в staging минимальны, но в проде тоже забывают подкрутить.
4. Статистика устарела
На проде реже делается ANALYZE, планировщик начинает строить неэффективные планы. Итог — ползёт.
5. Разное поведение приложения
Прод нагружается параллельно десятками потоков. Staging — ты и Postman.
Что делать:
– Сравни настройки сервера (SHOW ALL; )
– Проверь EXPLAIN ANALYZE
– Не доверяй staging — тестируй на продоподобных данных
Знакомо? На staging сервере — отклик 100мс, на проде — секундные таймауты. Хотя база одна и та же, схема такая же. Что не так?
Вот 5 частых причин:
1. Разный объём данных
На staging — 10k строк, на проде — 10 млн. Индексы, которые "и так нормально", внезапно перестают справляться.
2. Отсутствие/различие индексов
DevOps мог не раскатить нужные индексы в прод. Или, наоборот, staging набит экспериментальными индексами.
3. Параметры конфигурации БД
work_mem, shared_buffers, max_connections — часто в staging минимальны, но в проде тоже забывают подкрутить.
4. Статистика устарела
На проде реже делается ANALYZE, планировщик начинает строить неэффективные планы. Итог — ползёт.
5. Разное поведение приложения
Прод нагружается параллельно десятками потоков. Staging — ты и Postman.
Что делать:
– Сравни настройки сервера (SHOW ALL; )
– Проверь EXPLAIN ANALYZE
– Не доверяй staging — тестируй на продоподобных данных