Как понять хватает ли памяти серверу PostgreSQL 2.0
Ранее мы уже получили верхнеуровневую информацию о заполненности кэша СУБД
https://max.ru/explorer1c/AZ4g2XVbeoY
Но этой информации не всегда достаточно чтобы принять решение хватает ли нам уже выделенного объёма.
Тут нам на помощь приходит ещё один столбец из pg_buffercache_summary(), а именно usagecount_avg, который даёт информацию о среднем значении счётчика использования буферов в кэше.
Сам процесс "нагревания" и "охлаждения" буферного кэша основан на алгоритме Clock-Sweep.
Краткий смысл алгоритма:
Процесс "нагревания" - при каждом обращении к странице в кэше счётчик её использования (usage_count) увеличивается на единицу.
Чтобы избежать зацикливания в бесконечном круге горячих страниц максимальное значение ограничено, например в postgresql, числом 5.
Процесс "охлаждения" - циклически обходим страницы в буферном кэше.
- Если usage_count > 0, то уменьшаем его значение на единицу.
- Если usage_count = 0, то эта страница может быть вымещена из кэша, а на её место загружена новая.
Таким образом эффективность кэша можно оценить значением usagecount_avg > 2,5.
Если же значение usagecount_avg часто оказывается меньше единицы, то буферного кэша недостаточно и страницы постоянно оттуда вымещаются.
Сильно высокое значение usagecount_avg (4-5) наоборот говорит о том, что у нас слишком большой буферный кэш и его можно уменьшить.
Более подробную раскладку, какое количество страниц с каким значением счётчика в кэше можно получить запросом:
Получив, например такой расклад:
usage_count | buffers
0 | 441196
1 | 236729
2 | 81823
3 | 44989
4 | 214970
5 | 159941
При этом usagecount_avg = 1,86
❗Конечно и это ещё не вся информация для тончайшей настройки PostgreSQL, но надеюсь что она даст ещё больше понимания как работает кэш и что с ним можно делать и нужно ли это делать.
Собирать данные необходимо за достаточно длительный период времени, в котором очень желательно не менять кардинально нагрузку, чтобы не получить искажённые результаты.
Ранее мы уже получили верхнеуровневую информацию о заполненности кэша СУБД
https://max.ru/explorer1c/AZ4g2XVbeoY
Но этой информации не всегда достаточно чтобы принять решение хватает ли нам уже выделенного объёма.
Тут нам на помощь приходит ещё один столбец из pg_buffercache_summary(), а именно usagecount_avg, который даёт информацию о среднем значении счётчика использования буферов в кэше.
select usagecount_avg from pg_buffercache_summary()
Сам процесс "нагревания" и "охлаждения" буферного кэша основан на алгоритме Clock-Sweep.
Краткий смысл алгоритма:
Процесс "нагревания" - при каждом обращении к странице в кэше счётчик её использования (usage_count) увеличивается на единицу.
Чтобы избежать зацикливания в бесконечном круге горячих страниц максимальное значение ограничено, например в postgresql, числом 5.
Процесс "охлаждения" - циклически обходим страницы в буферном кэше.
- Если usage_count > 0, то уменьшаем его значение на единицу.
- Если usage_count = 0, то эта страница может быть вымещена из кэша, а на её место загружена новая.
Таким образом эффективность кэша можно оценить значением usagecount_avg > 2,5.
Если же значение usagecount_avg часто оказывается меньше единицы, то буферного кэша недостаточно и страницы постоянно оттуда вымещаются.
Сильно высокое значение usagecount_avg (4-5) наоборот говорит о том, что у нас слишком большой буферный кэш и его можно уменьшить.
Более подробную раскладку, какое количество страниц с каким значением счётчика в кэше можно получить запросом:
select usage_count, buffers from pg_buffercache_usage_counts()
Получив, например такой расклад:
usage_count | buffers
0 | 441196
1 | 236729
2 | 81823
3 | 44989
4 | 214970
5 | 159941
При этом usagecount_avg = 1,86
❗Конечно и это ещё не вся информация для тончайшей настройки PostgreSQL, но надеюсь что она даст ещё больше понимания как работает кэш и что с ним можно делать и нужно ли это делать.
Собирать данные необходимо за достаточно длительный период времени, в котором очень желательно не менять кардинально нагрузку, чтобы не получить искажённые результаты.