Автор статьи прямо указывает что НЕиспользовать большие страницы НЕ рекомендуется — Especially when not utilizing huge_pages (not recommended)
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.
Репортинг памяти самим постгресом, сделан не очень удачно имхо (((.
Репортинг в консоль работает только для текущей сессии, при этом нельзя также взять и посмотреть репорт по соседней сессии, только через функцию pg_log_backend_memory_contexts сбросить дамп в лог и потом грепать его. Печаль.
Планы расширения конечно есть, на очереди odyssey, patroni и pgbackrest (потом wal-g, и возможно pg_probackup т.к. с ним меньше всего опыта).
Дашбордов нет, пока руки не дошли. Первым по плану для графаны, потом возможно для заббикса. С последним сложно, т.к. у меня вообще его нигде нет.
Большое спасибо за развернутый ответ по пп 1 и 2, так стало сильно понятней.
Но по п.3 в итоге все равно получается так что может быть только один метод Get и он всегда возвращает только либо успех (err == nil), только либо ошибку (err != nil).
Спасибо за статью, есть несколько вопросов по п.1 «Используем интерфейсы при разработке»:
1. как быть если методов относительно много? в той же redis библиотеке их довольно много — выходит что каждый внешний метод нужно оборачивать в свой или идти в сторону кодогенерации?
2. как быть если внешний метод возвращает какой-то свой интерфейс? например pgx.Begin, возвращает транзакцию pgx.Tx (которая тоже интерфейс) — для транзакции тоже нужно писать свой интерфейс обертку и затем писать обертки для методов?
3. в обертках всегда возвращается «успех», а как быть если нужно также тестировать и случаи когда возвращаются ошибки? Ну то есть как сделать так чтобы метод-обертка мог возвращать не только успех, но и error.
Лично мне — на случай если нужно локально что-то выполнить, например погнать тесты или собрать бинарник.
Судя по вашему комментарию я так понимаю что вы знаете о GH Actions больше чем я, тогда вам встречный вопрос — нет ли у вас готовых примеров (с гитхаба) по сборке докер образов и их выкладке в registry. Я понимаю что описание можно найти в их документации, но хотелось бы увидеть как это устроено в реальных workflow.
Согласен, периодически от него подгорает, но пока в целом Makefile удовлетворяет мои скромные потребности. За альтернативы спасибо, а из этих двух сами к чему склоняетесь больше и почему?
Зависит от кейса:
— если «что-то» что лежит в коде, то просто кладем в целевой контейнер через COPY/ADD
— если «что-то» принадлежит другому пакету (корневые сертификаты), то это также можно через multi-stage сделать — установить пакет в одном контейнере и затем оттуда скопировать в целевой.
— если «что-то» создается самим пользователем (конфиги например) — то это создается отдельно до запуска контейнера, а при запуске контейнера подкладывается через тома (volumes).
Спасибо за проделанную работу, но перевод хромает. Переводчку надо повышать свою тех.грамотность и избегать англицизмов (консюмер) и английских слов в переведенном тексте (fan-out, amplification и т.п) — для большинства слов уже давно есть устоявшиеся термины на русском языке.
RED и Golden Signals это набор метрик для поверхностной оценки состояния сервиса. Первым появился GS в недрах гугла, почитать можно в SRE Book, RED это уже наложение USE метода на GS. Суть методов в том что сервис обрабатывает запросы, часть из них может быть ошибочными, и запросы обрабатываются с разными временем. Получается что накладывая метрики на то как обрабатываются запросы, мы можем оценить насколько хорошо справляется наш сервис со своей работой или нет. Если вы не знакомы с темой рекомендую начать с приведенных ссылок.
> ну вот например по блокировкам и ожиданиям, какие будут подсказки?
сначала посмотрим включен ли log_lock_waits, если не включен то скажем включить и через некоторое время проверить логи. Если уже включен, скажем смотреть логи на предмет waiting и дальше инспектировать приложение и фиксить там.
> Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
Не, пока такого нет
> ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?
Если запрос всего один, то есть вероятность что он потеряется на фоне других (при большом rate). Если таких запросов много, то вы пятикратное увеличение времени вы увидите в durations. Ну а дальше надо идти в отдельный дашборд в котором собрана стата по запросам и там смотреть что за тип запросов стал выполняться дольше (а затем explain и вот это все).
Задача RED и Golden Signals дать способ быстро ответить на вопрос, все хорошо с сервисом. Детали работы сервиса уже покрываются отдельными метриками.
1) total_time показывает сумму всех времен выполнения этого запроса, условно говоря если запрос выполняется ~1ms и выполнялся 1000 раз, то в total time будет ~1000 (ms).
2) Через pg_stat_statements увы нет, нельзя. там только агрегаты. Точное время выполнения конкретного запроса можно получить через логи (при условии что логирование настроено).
3) Пока подсказки довольно простые и просто указывают на наличие проблемы и пути дальнейшего действий что с этим делать. Например для idle транзакций устранить их в приложении, включить автоматическое завершение idle транзакций по таймауту и т.д.
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.
Репортинг в консоль работает только для текущей сессии, при этом нельзя также взять и посмотреть репорт по соседней сессии, только через функцию pg_log_backend_memory_contexts сбросить дамп в лог и потом грепать его. Печаль.
Дашбордов нет, пока руки не дошли. Первым по плану для графаны, потом возможно для заббикса. С последним сложно, т.к. у меня вообще его нигде нет.
Но по п.3 в итоге все равно получается так что может быть только один метод Get и он всегда возвращает только либо успех (err == nil), только либо ошибку (err != nil).
1. как быть если методов относительно много? в той же redis библиотеке их довольно много — выходит что каждый внешний метод нужно оборачивать в свой или идти в сторону кодогенерации?
2. как быть если внешний метод возвращает какой-то свой интерфейс? например pgx.Begin, возвращает транзакцию pgx.Tx (которая тоже интерфейс) — для транзакции тоже нужно писать свой интерфейс обертку и затем писать обертки для методов?
3. в обертках всегда возвращается «успех», а как быть если нужно также тестировать и случаи когда возвращаются ошибки? Ну то есть как сделать так чтобы метод-обертка мог возвращать не только успех, но и error.
Судя по вашему комментарию я так понимаю что вы знаете о GH Actions больше чем я, тогда вам встречный вопрос — нет ли у вас готовых примеров (с гитхаба) по сборке докер образов и их выкладке в registry. Я понимаю что описание можно найти в их документации, но хотелось бы увидеть как это устроено в реальных workflow.
— если «что-то» что лежит в коде, то просто кладем в целевой контейнер через COPY/ADD
— если «что-то» принадлежит другому пакету (корневые сертификаты), то это также можно через multi-stage сделать — установить пакет в одном контейнере и затем оттуда скопировать в целевой.
— если «что-то» создается самим пользователем (конфиги например) — то это создается отдельно до запуска контейнера, а при запуске контейнера подкладывается через тома (volumes).
сначала посмотрим включен ли log_lock_waits, если не включен то скажем включить и через некоторое время проверить логи. Если уже включен, скажем смотреть логи на предмет waiting и дальше инспектировать приложение и фиксить там.
> Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
Не, пока такого нет
> ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?
Если запрос всего один, то есть вероятность что он потеряется на фоне других (при большом rate). Если таких запросов много, то вы пятикратное увеличение времени вы увидите в durations. Ну а дальше надо идти в отдельный дашборд в котором собрана стата по запросам и там смотреть что за тип запросов стал выполняться дольше (а затем explain и вот это все).
Задача RED и Golden Signals дать способ быстро ответить на вопрос, все хорошо с сервисом. Детали работы сервиса уже покрываются отдельными метриками.
2) Через pg_stat_statements увы нет, нельзя. там только агрегаты. Точное время выполнения конкретного запроса можно получить через логи (при условии что логирование настроено).
3) Пока подсказки довольно простые и просто указывают на наличие проблемы и пути дальнейшего действий что с этим делать. Например для idle транзакций устранить их в приложении, включить автоматическое завершение idle транзакций по таймауту и т.д.