pgstat wait timeout
Сегодня я бы хотел рассказать о такой ошибке как "pgstat wait timeout". Довольно малоинформативное сообщение, не так ли?
Если вы увидели эту ошибку в логах PostgreSQL, значит у вас перестал работать сбор статистики. А между тем статистика играет очень важную роль в работе PostgreSQL. Статистика используется планировщиком запросов для составления планов запросов и выбора оптимального плана для запроса. Если у вас сбилась статистика, планировщик может начать строить неверные планы. Неправильные планы запросов приводят к плохой производительности.
Сегодня я бы хотел рассказать о такой ошибке как "pgstat wait timeout". Довольно малоинформативное сообщение, не так ли?
Если вы увидели эту ошибку в логах PostgreSQL, значит у вас перестал работать сбор статистики. А между тем статистика играет очень важную роль в работе PostgreSQL. Статистика используется планировщиком запросов для составления планов запросов и выбора оптимального плана для запроса. Если у вас сбилась статистика, планировщик может начать строить неверные планы. Неправильные планы запросов приводят к плохой производительности.
Давайте попробуем разобраться почему это происходит.
Первым делом я бы хотел вкратце напомнить что такое подсистема сбора статистики. В СУБД есть выделенный процесс - stats collector process. Именно этот процесс и занимается сбором информации об активности внутри базы данных. В частности коллектор статистики собирает данные о таблицах, индексах, пользовательских функциях, о количестве строк внутри таблиц, о том сколько блоков прочитано с диска или из буфера. Также он собирает информации в процессе выполнения таких операций как vacuum и analyze. То есть в процессе изменения данных в таблицах, stats collector старается поддерживать актуальность статистики. Кроме того часть статистики обновляется процессами автовакуума.
В файле конфигурации есть несколько параметров которые отвечают за работу колектора статистики:
track_activities собирает информацию о командах выполняемых серверными процессами на данный момент.
Первым делом я бы хотел вкратце напомнить что такое подсистема сбора статистики. В СУБД есть выделенный процесс - stats collector process. Именно этот процесс и занимается сбором информации об активности внутри базы данных. В частности коллектор статистики собирает данные о таблицах, индексах, пользовательских функциях, о количестве строк внутри таблиц, о том сколько блоков прочитано с диска или из буфера. Также он собирает информации в процессе выполнения таких операций как vacuum и analyze. То есть в процессе изменения данных в таблицах, stats collector старается поддерживать актуальность статистики. Кроме того часть статистики обновляется процессами автовакуума.
В файле конфигурации есть несколько параметров которые отвечают за работу колектора статистики:
track_activities собирает информацию о командах выполняемых серверными процессами на данный момент.
track_counts собирает информацию об использовании таблиц и индексов.
track_functions включает сбор статистики об использовании пользовательских функций.
track_io_timing включает сбор информации о времени выполнения блочных операций (чтение/запись).
Напоследок стоит отметить что коллектор статистики, хранит информацию во временных файлах. Каталог где размещены файлы статистики определяется параметром stats_temp_directory в postgresql.conf. По умолчанию это каталог pg_stat_tmp. При выключении постгреса, копия статистики сохраняется в каталоге pg_stat.
Теперь вернемся к нашей ошибке "pgstat wait timeout". Такая ошибка может возникать в трех случаях:
Чрезмерная нагрузка на дисковый ввод-вывод.
В случае когда дисковая подсистема полностью загружена и процессы автовакуума не могут записать данные статистики в "stats_temp_directory" мы можем увидеть эти WARNING сообщения. Для подтверждения этой гипотезы следует воспользоваться утилитой iostat из пакета sysstat. Эта утилита предоставляет данные об утилизации дисков. Если значение утилизации колеблется в пределах 90-100% значит можно рассматривать эту версию.
Неправильное размещение stats_temp_directory.
Второй случай, наименее вероятный, это неверное размешение временного каталога для хранения статистики. Например в случае когда для временного хранения использовался RAM диск который по какой-то причине стал недоступен. В такой ситуации, вам следует проверить значение параметра stats_temp_directory и затем посмотреть как обстоят дела с этим каталог в файловой системе. Убедитесь что он существует и на него назначены соответствующий владелец (аккаунт postgres) и права доступа. Если параметр указывает на несуществующий каталог, вы можете либо создать этот каталог, лиюо указать новый каталог в опции stats_temp_directory и сделать reload конфигурации.
Изменения в сетевой конфигурации.
Третий случай, наиболее часто встречающийся, происходит когда администратор вносит изменения в сетевую конфигурацию. Самый частый случай - отключает ipv6 через sysctl. Что происходит в данной ситуации? При отключении ipv6, все адреса ipv6 исчезают (localhost). PostgreSQL не может обработать такую ситуацию что приводит к невозможности сохранить статистику. В результате появляются WARNING сообщения. Решение в данной ситуации следующее: нужно откатить изменения в сетевой конфигурации назад, проверить файл конфигурации /etc/hosts что он содержит верные значения, включить ipv6. Либо как вариант просто перезагрузите postrgesql сервис.
Как видите причин для появления такого собщения немного и проверить варианты можно достаточно быстро.
В заключении хочу отметить один момент. Начиная с PostgreSQL 9.4.1 сообщение "pgstat wait timeout" переименовано в более информативное и понятное "using stale statistics instead of current ones because stats collector is not responding". А важность сообщения снижена с WARNING до LOG. Спасибо Tom Lane.
На этом все, до новых встреч!
track_functions включает сбор статистики об использовании пользовательских функций.
track_io_timing включает сбор информации о времени выполнения блочных операций (чтение/запись).
Напоследок стоит отметить что коллектор статистики, хранит информацию во временных файлах. Каталог где размещены файлы статистики определяется параметром stats_temp_directory в postgresql.conf. По умолчанию это каталог pg_stat_tmp. При выключении постгреса, копия статистики сохраняется в каталоге pg_stat.
Теперь вернемся к нашей ошибке "pgstat wait timeout". Такая ошибка может возникать в трех случаях:
Чрезмерная нагрузка на дисковый ввод-вывод.
В случае когда дисковая подсистема полностью загружена и процессы автовакуума не могут записать данные статистики в "stats_temp_directory" мы можем увидеть эти WARNING сообщения. Для подтверждения этой гипотезы следует воспользоваться утилитой iostat из пакета sysstat. Эта утилита предоставляет данные об утилизации дисков. Если значение утилизации колеблется в пределах 90-100% значит можно рассматривать эту версию.
Неправильное размещение stats_temp_directory.
Второй случай, наименее вероятный, это неверное размешение временного каталога для хранения статистики. Например в случае когда для временного хранения использовался RAM диск который по какой-то причине стал недоступен. В такой ситуации, вам следует проверить значение параметра stats_temp_directory и затем посмотреть как обстоят дела с этим каталог в файловой системе. Убедитесь что он существует и на него назначены соответствующий владелец (аккаунт postgres) и права доступа. Если параметр указывает на несуществующий каталог, вы можете либо создать этот каталог, лиюо указать новый каталог в опции stats_temp_directory и сделать reload конфигурации.
Изменения в сетевой конфигурации.
Третий случай, наиболее часто встречающийся, происходит когда администратор вносит изменения в сетевую конфигурацию. Самый частый случай - отключает ipv6 через sysctl. Что происходит в данной ситуации? При отключении ipv6, все адреса ipv6 исчезают (localhost). PostgreSQL не может обработать такую ситуацию что приводит к невозможности сохранить статистику. В результате появляются WARNING сообщения. Решение в данной ситуации следующее: нужно откатить изменения в сетевой конфигурации назад, проверить файл конфигурации /etc/hosts что он содержит верные значения, включить ipv6. Либо как вариант просто перезагрузите postrgesql сервис.
Как видите причин для появления такого собщения немного и проверить варианты можно достаточно быстро.
В заключении хочу отметить один момент. Начиная с PostgreSQL 9.4.1 сообщение "pgstat wait timeout" переименовано в более информативное и понятное "using stale statistics instead of current ones because stats collector is not responding". А важность сообщения снижена с WARNING до LOG. Спасибо Tom Lane.
На этом все, до новых встреч!
Комментариев нет:
Отправить комментарий