Проблема статистики PostgreSQL - не удалось переименовать временный файл статистики

после моего первоначального ответа, я решил исследовать работу сборщик статистики и, в частности, что он делает с файлами в pg_stat_tmp. В результате я существенно переписал ответ.

какие глобальные.stat / global.tmp файлы, используемые для?

Postgresql содержит функциональные возможности для сбора статистики и информации о состоянии Его работы. Функция описана в 27.2 из руководство.

эта информация сопоставляется stats collector process. Он доступен для других процессов postgresql через . При первом запуске запроса, который обращается к этим данным в транзакции, сервер, к которому вы подключены, будет читать global.stat файл и кэшировать результат, используя его до конца транзакции.

чтобы сохранить этот файл в актуальном состоянии, процесс сбора статистики периодически переписывает его с обновленной информацией. Он обычно это несколько раз в секунду. Процесс выглядит следующим образом:

1. создать новый глобальный файл.tmp
2. запись данных в этот файл
3. переименовать global.tmp в качестве глобального.stat, перезапись предыдущего глобального.stat

на global.tmp и global.stats файлы записываются в каталог, настроенную stats_temp_directory параметр конфигурации. Обычно это установлено в $PGDATA/pg_stat_tmp.

на отключение, файл статистики записывается в файл $PGDATA/global/pgstat.stat, и файлы в каталоге tmp выше удаляются. Этот файл затем считывается и удаляется при повторном запуске базы данных.

почему процессор сборщика статистики создает так много нагрузки ввода-вывода?

обычно, объем данных, записанных в глобальный.статистика относительно скромная и написание ее не генерирует столько трафика ввода-вывода. Однако при некоторых обстоятельствах он, кажется, очень раздут. Когда это произойдет, количество создаваемой нагрузки может начать становиться чрезмерным, так как весь файл переписывается более одного раза в секунду.

у меня был один опыт, когда он вырос в 10 или более раз по сравнению с другими подобными серверами. У этой машины было необычно большое количество баз данных (для нашего приложения, по крайней мере, - 30-40 баз данных, но ничего похожего на 6000, которые вы говорите, что у вас есть). Возможно, что наличие большого количества баз данных усугубляет это.

некоторые из ссылки ниже говорят о шаблоне создания / удаления большого количества таблиц, вызывающих раздувание в этих файлах, и, возможно, autovacuum не работает достаточно агрессивно, чтобы удалить связанное раздувание. Возможно, вы захотите рассмотреть настройки autovac.

почему я получаю ошибки "отказано в разрешении" в Windows?

после изучения исходного кода postgresql я думаю, что может быть условие гонки при доступе к global.stats файл, который может произойти в любое время, но усугубляется размером файла.

режим работы по умолчанию в Windows заключается в том, что невозможно переименовать или удалить файл, пока он открыт другим процессом. Это отличается от Linux (или Unix), где файл может быть переименован или удален, в то время как другие процессы обращаются к нему.

в последовательности выше вы можете видеть, что если один из бэкэнд-процессов читает файл в то же время, как сборщик статистики переписывает его, то бэкэнд-процесс может все еще имейте файл открытым во время попытки переименования. Это приводит к ошибке "отказано в разрешении", которую вы видите.

естественно, когда файл становится очень большим, то количество времени, необходимое для его чтения, становится более значительным, поэтому вероятность процесса сборщика статистики, пытающегося переименовать, пока бэкэнд все еще открыт, увеличивается.

однако, поскольку файл часто переписывается, влияние этих ошибок относительно мягкое. Он просто означает, что это конкретное обновление терпит неудачу, что приводит к тому, что бэкэнды получают немного устаревшую статистику. Следующее обновление, вероятно, будет успешным.

обратите внимание, что Windows предлагает режим открытия файлов, который позволяет удалять или переименовывать файлы во время их открытия другим процессом, однако, насколько я могу судить, этот режим не используется Postgresql. Я не мог найти никакого отчета об ошибке на этом-кажется, это должно быть сообщено.

таким образом, эти ошибки являются побочным эффектом основной проблемы, которая является чрезмерным размером .

я track_activities, но файл все равно пишется - почему?

из того, что я вижу, track_activites влияет только на один из наборов информации, которую собирает сборщик статистики.

кроме того, похоже, что процесс сбора статистики запускается независимо от этих настроек и будет продолжать перезаписывать файл. Параметры контролируйте только сбор свежих данных.

мой вывод заключается в том, что как только файл стал раздутым, он останется таким и будет продолжать переписываться, даже если все параметры сбора статистики будут отключены.

что я могу сделать, чтобы избежать этой проблемы?

как только файл стал раздутым, кажется, что самый простой способ вернуть базу данных в хорошее рабочее состояние-удалить файл, используя следующее шаги:

1. остановить базу данных

2. когда БД остановлена, каталог pg_stat_tmp пуст и файл $PGDATA/global/pgstat.stat написано. Мы переименовали этот файл в pgstat.stat.old.

3. запустить базу данных. Он создает новый набор файлов pgstat. После подтверждения правильной работы сервера вы можете удалить старый переименованный файл.

это процесс, который мы использовали, когда один из наши серверы пострадали от этой проблемы.

Излишне говорить, что будьте очень осторожны при ручном управлении любыми файлами в каталоге данных Postgresql.

после этого вы можете контролировать сервер, чтобы увидеть, если он файл становится раздутым снова. Если это так, то вот некоторые дополнительные идеи для рассмотрения:

• как упоминалось выше, я видел, что некоторые ссылки на этот файл становятся раздутыми, если autovacuum не работает агрессивно достаточно. Вы можете настроить настройки autovacuum

• отключение любого из track_xxx параметры, описанные в разделе 18.9.1 руководства, которые не требуются может помочь

• можно поставить pg_stats_tmp каталог в файловой системе tmpfs (или любая эквивалентная файловая система на основе ОЗУ доступна в windows). Это должно устранить I / O как проблему для этих файлы.

ссылки:

• Postgres статистика коллектор показывает высокий диск ввода / вывода
• слишком много ввода / вывода, сгенерированного postgres stats collector process
• статистика коллектор внезапно вызывает много IO