я бы сбросил, сделал руками один чекпойнт и смотрел бы таким запросом (в нём нет проверки деления на ноль, поэтому нужен чекпойнт, запускать в psql ) :
SELECT round(100.0*checkpoints_req/checkpoints,1) "Forced checkpoint ratio (%)",
round(min_since_reset/checkpoints,2) "Minutes between checkpoints",
round(checkpoint_write_time::numeric/(checkpoints*1000),2) "Average write time per checkpoint (s)",
round(checkpoint_sync_time::numeric/(checkpoints*1000),2) "Average sync time per checkpoint (s)",
round(total_buffers/128.0,1) "Total MB written",
round(buffers_checkpoint/(128.0*checkpoints),2) "MB per checkpoint",
round(buffers_checkpoint/(128.0*min_since_reset*60),2) "Checkpoint MBps",
round(buffers_clean/(128.0*min_since_reset*60),2) "`bgwriter` MBps",
round(buffers_backend/(128.0*min_since_reset*60),2) "Backend MBps",
round(total_buffers/(128.0*min_since_reset*60),4) "Total MBps",
round(100.0*buffers_checkpoint/total_buffers,1) "Clean by checkpoints (%)",
round(100.0*buffers_clean/total_buffers,1) "Clean by `bgwriter` (%)",
round(100.0*buffers_backend/total_buffers,1) "Clean by backends (%)",
round(100.0*maxwritten_clean/(min_since_reset*60000/bgwriter_delay),2) "`bgwriter` halt-only length (buffers)",
coalesce(round(100.0*maxwritten_clean/(nullif(buffers_clean,0)/bgwriter_lru_maxpages),2),0) "`bgwriter` halt ratio (%)",
round(1.0*buffers_alloc/total_buffers,3) "New buffer allocation ratio",
min_since_reset "Minutes since reset",
now()-pg_postmaster_start_time() "Uptime",
'-------' "-------------------------------------",
*
FROM (
SELECT checkpoints_timed,
checkpoints_req,
checkpoints_timed + checkpoints_req checkpoints,
checkpoint_sync_time,
checkpoint_write_time,
buffers_checkpoint,
buffers_clean,
maxwritten_clean,
buffers_backend,
buffers_backend_fsync,
buffers_alloc,
buffers_checkpoint + buffers_clean + buffers_backend total_buffers,
pg_postmaster_start_time() startup,
stats_reset,
round(extract('epoch' from now() - stats_reset)/60)::numeric min_since_reset,
delay.setting::numeric bgwriter_delay,
lru.setting::numeric bgwriter_lru_maxpages,
ratio.setting::numeric bgwriter_lru_multiplier,
ckpt_s.setting::numeric max_wal_size,
ckpt_t.setting::numeric checkpoint_timeout
FROM pg_stat_bgwriter
JOIN pg_settings lru ON lru.name = 'bgwriter_lru_maxpages'
JOIN pg_settings delay ON delay.name = 'bgwriter_delay'
JOIN pg_settings ratio ON ratio.name = 'bgwriter_lru_multiplier'
JOIN pg_settings ckpt_s ON ckpt_s.name = 'max_wal_size'
JOIN pg_settings ckpt_t ON ckpt_t.name = 'checkpoint_timeout'
) bgstats\gx
кстати спасибо за запрос...тоже очень пригодился)
1. Если честно, не знаю насчет временных файлов. Во-первых, я в администрировании PG скорее новичок, во-вторых, я не знаю, как это посмотреть в Яндекс.Облаке. Могу только предположить исходя из документации, что with hold курсоры во временные файлы пишутся. 2. Спасибо за скрипт, посмотрю.
> исходя из документации, что with hold курсоры во временные файлы пишутся. Хмм... разве там такое написано? Хотя, если результаты большие, то пишутся. > Explain analyze? ) Да. > По сессиям - в облаке автоматом стоит 1200 сессий на всё для этой конфигурации хоста, больше нельзя. А я пишу, что нужно меньше. Если речь о max_connections.
> Хмм... разве там такое написано? Хотя, если результаты большие, то пишутся. Да, я неправ, от количества информации всё смешалось в голове ) https://stackoverflow.com/questions/33635405/postgres-cursor-with-hold > Explain analyze Для курсора не показывает ничего связанного с памятью. Без курсора один из самых долгих запросов: Sort Method: quicksort Memory: 25kB Worker 0: Sort Method: quicksort Memory: 25kB Worker 1: Sort Method: quicksort Memory: 25kB Выглядит смешно ) > А я пишу, что нужно меньше. Если речь о max_connections. Я понимаю. Из-за этого меньше я ушел с GreenPlum. И мне не скажут спасибо, если опять у кого-то вылезет ошибка с одновременными подключениями. Скорее согласятся потормозить ) Реальная картина будет после публикации приложения, когда 100+ пользователей ломанутся в базу. Пока пытаюсь подготовиться, куда бежать в случае чего )))
> Без курсора один из самых долгих запросов: Так это не обязательно долгие. Нужно, как раз, "типичные" смотреть.
Их полторы сотни :( И все типичные :) И это без всевозможных фильтров.
Ну так это ничто, если они все известны — выполнить (можно с auto_explain + вытащить планы из лога), просто поискать "развесистые". :) И "фильтры" могут запросто менять планы. А можно этим не заморачиваться, просто примерно посчитать, а с появлением реальной нагрузки уже окончательно настроить (если вообще придётся).
Насчет auto_explain не подумал, спасибо ) Фильтры меняют планы на очень хорошие, всё по индексам попадает) Курсоры подгаживают, не дают параллелизм (((
Обсуждают сегодня