HikariCP в проде: три раза, когда пул соединений уронил сервис, и почему maximumPoolSize тут был ни при чём
<img src="https://habrastorage.org/getpro/habr/upload_files/618/9ce/630/6189ce630add4edfa51fa43e9e0ca7d5.png" /><p>В <a href="https://habr.com/ru/articles/1079692/" rel="noopener nofollow">прошлой статье про PostgreSQL</a> я разбирал три инцидента на стороне базы — блокировки, bloat и ночные пересчёты. В комментариях несколько человек написали примерно одно и то же: «база базой, а покажи, что творилось на стороне приложения — пул-то небось тоже горел».</p><p>Горел. Ещё как.</p><p>Это продолжение того же разбора, но на слой выше — про <strong>HikariCP</strong>, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в <a href="https://habr.com/ru/articles/1074552/" rel="noopener nofollow">статье про миграцию</a> и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах <code>Connection is not available</code>, и первое, что делает любой человек, — лезет крутить <code>maximumPoolSize</code>. И почти всегда делает хуже.</p><p>Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».</p><p>Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.</p><p><em>Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.</em></p> <a href="https://habr.com/ru/articles/1081494/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1081494#habracut">Читать далее</a>