Добрый день

Есть два похожих больших приложения. На одном 9.3.4, на втором 9.2.9. Ситуация и там и там одна и таже.
Потоковая репликация, по 1-3 слейва. На каждой машине баунсер.

Есть регулярный ночной процесс, в котором меняется много данных.
Есть в этом процессе один этап, в котором удаляется чистится таблица (делит), делается большой инсерт в эту таблицу.
Таблица 100 мб, индексов 50 мб. Данных вставляется не много, но для что бы их посчитать уходит много времени и ресурсов. Там запрос по нескольким большим таблицам (десятки гб) с группировкой, агрегатами и юнионами.

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

Проблема в том, что постгрес вешается очень зло. Все новые соединения получают accept(), но дальше постгрес их не обрабатывает.
Таким образом любое подключение к постгресу в этот момент висит до бесконечности.

Чем занят постгрес в это время пока не смотрели. Мониторинг в это время так же не работает, т.к. его конекты к постгресу так же висят и прерывается процесс опроса метрик.

На слейвах в этот момент есть читающая нагрузка. Причем эта таблица так же активно читается.

Есть понимание что процесс нужно облегчать, уходить от полной перезаписи, уменьшать кол-во изменений.
Не понятно почему мастер переваривает, а слейв, который должен только накатить логи (таблица 100 мб), так вешается.

Планируем переделку процесса, обновление ПГ до 9.3.6.

Есть мысли о том, что происходит?

Gold_,

В этой транзакции или в другой до?

В этой транзакции в одном аппликейшене делается create/drop temp table + индекс на ней.
В этой транзакции в другом аппликейшене не делается DDL.

В другой транзакции, раньше, делается:
TRUNCATE TABLE
setval
create/drop temp
SET CONSTRAINTS ALL DEFERRED
SET CONSTRAINTS ALL IMMEDIATE

Gold_,

Нет это постоянная таблица используется как "временная" в регулярном процессе. Пишется и читается только на мастере одним процессом. В нее заливаются данные из внешней системы.

В логах баунсера:
2015-02-16 03:39:10.520 15817 LOG S-0xeadc70: user/user@ip:5432 new connection to server
2015-02-16 03:39:11.813 15817 LOG S-0xeadb50: user/user@ip:5432 new connection to server
2015-02-16 03:39:13.154 15817 LOG S-0xeae450: user/user@ip:5432 new connection to server
2015-02-16 03:39:13.282 15817 LOG S-0xead910: user/user@ip:5432 new connection to server
2015-02-16 03:39:14.178 15817 LOG S-0xeae0f0: user/user@ip:5432 new connection to server
2015-02-16 03:39:15.903 15817 LOG S-0xeada30: user/user@ip:5432 new connection to server
2015-02-16 03:39:24.996 15817 LOG S-0xead5b0: user/user@ip:5432 new connection to server
2015-02-16 03:39:40.309 15817 LOG S-0xead5b0: user/user@ip:5432 closing because: connect timeout (age=15)
2015-02-16 03:39:40.309 15817 LOG S-0xeae330: user/user@ip:5432 new connection to server
2015-02-16 03:39:55.341 15817 LOG S-0xeae330: user/user@ip:5432 closing because: connect timeout (age=15)
2015-02-16 03:39:55.341 15817 LOG S-0xead5b0: user/user@ip:5432 new connection to server
2015-02-16 03:40:00.147 15817 LOG Stats: 115 req/s, in 24863 b/s, out 388726 b/s,query 92157 us
2015-02-16 03:40:10.371 15817 LOG S-0xead5b0: user/user@ip:5432 closing because: connect timeout (age=15)
2015-02-16 03:40:10.462 15817 LOG S-0xead5b0: user/user@ip:5432 new connection to server
2015-02-16 03:40:25.741 15817 LOG S-0xead5b0: user/user@ip:5432 closing because: connect timeout (age=15)
2015-02-16 03:40:25.741 15817 LOG S-0xeae330: user/user@ip:5432 new connection to server
2015-02-16 03:40:40.779 15817 LOG S-0xeae330: user/user@ip:5432 closing because: connect timeout (age=15)
2015-02-16 03:40:40.779 15817 LOG S-0xead5b0: user/user@ip:5432 new connection to server
2015-02-16 03:40:48.447 15817 LOG S-0xeae330: user/user@ip:5432 new connection to server


много новых коннектов, видимо потому-что сервер начал тормозить, запросы медленно выполняются

В лога ПГ из интересного только:
Feb 16 03:38:29 x postgres[8085]: [4-1] ERROR: recovery is in progress
Feb 16 03:38:29 x postgres[8085]: [4-2] HINT: WAL control functions cannot be executed during recovery.
Feb 16 03:38:29 x postgres[8085]: [4-3] STATEMENT: select pg_xlogfile_name(pg_current_xlog_location())
...
Feb 16 03:56:30 x postgres[28121]: [30659-1] LOG: restartpoint complete: wrote 346060 buffers (9.0%); 0 transaction log file(s) added, 0 removed, 139 recycled; write=1079.643 s, sync=1.138 s, total=1080.872 s; sync files=572, longes
t=0.706 s, average=0.001 s
Feb 16 03:56:30 x postgres[28121]: [30660-1] LOG: recovery restart point at FB3/5075A350
Feb 16 03:56:30 x postgres[28121]: [30660-2] DETAIL: last completed transaction was at log time 2015-02-16 03:43:32.929472+05


но это же просто накат лога.

и это из интересного
Feb 16 03:42:46 x postgres[9644]: [4-1] LOG: expected password response, got message type 88


плюс из-за кривого запроса, регулярная запись темп файла на 170 мб.

Maxim Boguk,

Правильно я понимаю, что важность принудительного analyze стремится к нулю если таблица по сути не меняется?
Кол-во записей и их распределении меняется по минимуму. Меняется какая-то внутренняя статистика.