Оптимизация работы с PostgreSQL в Go: от 50 до 5000 RPS - Иван Осадчий

Transcript

1. Иван Осадчий Senior Engineer Москва — 2021 ОТ 50 ДО 5000
2. О чем? • Реальный кейс • Нюансы работы pgx и PgBouncer • Простой, легко применимый вывод
4. Зачем переделывать? • 98% создаваемость :( • масштабирование • тарифное API
5. Тарифное API для служб доставки Как было:
6. Тарифное API для служб доставки Как хотелось:
7. Пропустим: • как хранить тарифы и пункты выдачи • какую технологию выбрать
10. Тест “в лоб”
11. Оптимизация: шаги 1. Цели и метрики 2. Тестовые данные 3. Найти узкое место 4. Устранить
12. Цели и метрики RPS:
13. Цели и метрики Задержка, мс:
14. Лента в 20 тысяч запросов
15. Лента 150 тысяч
16. Почему тормозит?
17. LSR-1223: лёг item-storage. Куча 500-х ошибок. Из-за уменьшения кэша пошёл трафик в базу, из-за нагрузки база стала медленнее отвечать, из-за медленных ответов сервис стал килить коннекты к базе. Килл происходит через отдельные соединения, и из-за этого все коннекты в баунсере заполнились и новые перестали проходить. В item-storage обновили pgx на четвёртую версию, где нельзя отключить cancelContext.
18. Отмена запроса
19. Отмена запроса при наличии pgbouncer
23. Отключили отмены запросов
24. PgBouncer: активные соединения
25. 130 RPS
26. БД: нагрузка на диск
27. Отменяем квоту на диск
28. Съели весь диск на сервере Не повторять!
29. Втиснуть данные в память • данные + индексы = 27 Гб
30. Данные в памяти: 5440 RPS
32. Открытый тест: 4000 RPS
33. PgBouncer: sv_active vs cl_waiting • размер пула в сервисе: 24 • в базе: 12
34. Исправили конфигурацию БД: 5000 RPS
35. Переключение между соединениями - дорого
36. Почему не влияет на закрытый тест? “Планировщик” PgBouncer: • нет лимита активное использование соединения • под нагрузкой активное соединение все время загружено • шансы получить серверное соединение низкие ◦ когда параллельных запросов мало — это ок ◦ когда много — некоторые не успевают
37. Нет мультиплексированию соединений
38. Размер пула в сервисе • <= пула на стороне БД Оговорочки: • медленные транзакции • разнесенная по времени нагрузка
39. Чего добились • запас по производительности • победили 500ки • открыли дорогу к API
40. Takeaway • знать свой процесс (оптимизации или еще чего) • следить за пулом соединений
41. Спасибо за внимание GitHub, Habr: @iosadchiy