Интересная и полная статья, спасибо. Появилась идея по прогреву локального кэша -- можно, как минимум, добавить распределенный кэш между локальным и источниками; а в максимуме -- по какому-нибудь gossip-like алгоритму распространять данные по локальным кэшам (но про это ничего не нагуглил :)), либо прямо через балансировщик запрашивать данные с уже прогретых (ready) сервисов
А насколько это хорошая идея - периодически запускать pg_repack (например, раз в день во время минимальной нагрузки), учитывая, что между запусками новые данные, получается, все равно будут "в конце"? Кажется, что все равно можно получить профит от этого, т. к. большая часть данных будет распределена по индексу, но я не до конца уверен. Или предполагается другое использование pg_repack?
Причина скорее всего в хранении конфигов именно рядом с исходным кодом, и смешивании конфигов для разных окружений. Можно хранить их в отдельном репозитории, или настроить дополнительные проверки (хуки, ревьюверы) при изменении продового конфига.
Интересная и полная статья, спасибо. Появилась идея по прогреву локального кэша -- можно, как минимум, добавить распределенный кэш между локальным и источниками; а в максимуме -- по какому-нибудь gossip-like алгоритму распространять данные по локальным кэшам (но про это ничего не нагуглил :)), либо прямо через балансировщик запрашивать данные с уже прогретых (ready) сервисов
Извините, не мог пройти мимо
А почему тогда не продусер? :)
Здесь как раз не должен превышать именно session.timeout.ms. Про эти две настройки хорошо написано здесь
Но как раз таки session.timeout.ms не должен быть таким большим. Осталось загадкой, понизили ли вы его до разумных в итоге, или нет :)
А насколько это хорошая идея - периодически запускать pg_repack (например, раз в день во время минимальной нагрузки), учитывая, что между запусками новые данные, получается, все равно будут "в конце"? Кажется, что все равно можно получить профит от этого, т. к. большая часть данных будет распределена по индексу, но я не до конца уверен. Или предполагается другое использование pg_repack?
Причина скорее всего в хранении конфигов именно рядом с исходным кодом, и смешивании конфигов для разных окружений. Можно хранить их в отдельном репозитории, или настроить дополнительные проверки (хуки, ревьюверы) при изменении продового конфига.
А как по этому тегу потом понять, какая версия кода выполняется (какой коммит конкретно был собран)?