В субботу, в 2 часа ночи, разбираясь с очередной аварией в Postgres на Heroku (запросы по 35 минут, IOPS на пределе), автор статьи понял, что пора уже разобраться по-человечески: что вообще значит читать с диска? Оказалось, что между SELECTом и железкой аж три слоя кэширования: shared buffers (внутренний кэш Postgres), page cache (кэш на уровне ядра Linux) и сам диск (в случае Heroku - сетевой EBS от AWS). Покопавшись в логах, он выяснил, что проблема не в железе, а в кривых запросах - они тупо выгребали по индексу десятки тысяч строк с нужным id, потом применяли фильтры к JSONB и выбрасывали почти всё, сжигая IOPS и читая сотни мегабайт с диска впустую
17.02.2026
Похожее
05.08.2026
mmap
Автор, три года строивший append-only базы данных на терабайтных масштабах, подр...
03.08.2026
Выживание с постгрей
Руководство по выживанию с Postgres для стартапов, основанное на двухлетнем опыт...
29.07.2026
768 серверов Postgres
Статья рассказывает, как PlanetScale заставляет 768 серверов Postgres, хранящих ...
20.07.2026
Запускаем DOOM на базе данных
Разработчики Turso портировали оригинальный Doom на байткод VDBE — виртуальную м...