У одного клиента в отличии от большинства остальных стоит не CentOS, а Win2008 R2 x64. Причем именно у него достаточно простая логика и относительно не сложные запросы. Так вот раз в месяц три процесса начинают серьезно тормозить сервер, из-за жесткого насилования веника на чтение. При этом как правило повисают надолго именно на командах типа DELETE FROM t_число где t_число временная таблица. В логах ничего особенного нет. Конфигурация достаточно стандартная:
Версия:
PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 64-bit
При этом свободной оперативки минимум 2-3 Gb. Все три процесса насилуют следующие файлы:
C:\Program Files\PostgreSQL\9.3\data\base\16396\t19_347016 (у каждого свои циферки)
С чем все это может быть связано, в смысле как диагностировать и лечить такие явления природы.
HawkmoonПроверено (на 8.4) что чем больше shared_buffers под виндой , тем хуже.
Оптимум в районе где-то 256MB-512MB
Что интересно через пару часов все приходит в норму. Но вообще да, похоже есть какой-то косяк с shared_buffers под виндой. Жаль пока не так много где проверить, везде CentOS в основном ставим :(
Временные таблицы, да? Надо бы изучить вопрос как в 9.3 обстоят дела с взаимодействием автовакуума с ними.
Раньше он их просто игнорировал, возможно в 9.3 это уже не так и массовые удаления вызывают потребность в резком
пересчете статистики итп?
НезалогинившийсяВременные таблицы, да? Надо бы изучить вопрос как в 9.3 обстоят дела с взаимодействием автовакуума с ними.
Раньше он их просто игнорировал, возможно в 9.3 это уже не так и массовые удаления вызывают потребность в резком
пересчете статистики итп?
в 9.3 временные таблицы так и игнорируются автовакумом... и будут игнорироваться и дальше (если вдруг временные таблицы с 0 не перепишут).... там архитектурные причины почему автовакум с ними работать не может
Разобрались. Проблема похоже во временных таблицах, которые pool'ся и при переиспользовании делается DELETE FROM, заполнение данных и ANALYZE, но не делается VACUUM. В результате через некоторое время они дорастают до огромных размеров на диске (правда непонятно почему через некоторое время работа восстанавливалась, видимо все же по какому то событию VACUUM все же trigger'ся).
Там то, как раз не должно быть момента отваливания connection'а, так что дело в чем то другом.
Что значить не должно быть? даже при использованиии пулера коннекто у коннекта к базе есть TTL свой (максимальный возраст коннекта к базе после чего он принудительно закрывается)
что для pgbouncer
что для pgpool
что для любых java connnectoon pooler (Типа c3p0)
что для любых известных мне велосипедов
Ну в данном случае, речь идет о собственном пулинге, и если в спецификации jdbc, в стандартном драйвере, и у самой СУБД TTL нет по умолчанию, то дело все же не в этом :)
Ну в данном случае, речь идет о собственном пулинге, и если в спецификации jdbc, в стандартном драйвере, и у самой СУБД TTL нет по умолчанию, то дело все же не в этом :)
ttl есть всегда... в самом плохом случае ttl наступает когда процессы базы начинает операционка отстреливать по OOM
вечноживые коннекты к базе это очень плохо... 1-2-12 часов это разумно... больше нет...
и еще раз скажу что место во временных таблицах можно почистить только через:
1)disconnect процесса базы
2)truncate Этих таблиц
3)drop эти таблиц...
autovacuum с ними никогда не работал и работать не будет/может так как они существуют только в приватной памяти конкретного процесса базы и к их данным никто кроме этого процесса базы добраться не может.
На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых
сервисов с использованием метрической программы Яндекс.Метрика.
Продолжая использовать сайт, вы даёте согласие на обработку файлов cookie, необходимых для работы сайта. Другие опции вы можете выбрать по своему усмотрению.
По нижеприведенным ссылкам мы можете ознакомиться с действующим на сайте пользовательским соглашением и политикой конфиденциальности.
