База 9Gb за три месяца работы, примерно 2,5 месяца все было в целом не плохо, потом началось следующее
Симптомы, отмена проведения документа "Расчет себестоимости выпуска" длится N-часов, до 8.......
Что удалось понять, 1С удаляет данные о движениях из регистров бухгалтерии, потом пересчитывается остатки в таблицах остатков по счетам, основное время уходит на обсчет второго субконто.
Формируются запросы вида
UPDATE _AccRgAT21278
SET _Fld1256 = _AccRgAT21278._Fld1256 + T2._Fld1256, _TurnoverDt1268 = _AccRgAT21278._TurnoverDt1268 + T2._TurnoverDt1268, _TurnoverCt1269 = _AccRgAT21278._TurnoverCt1269 + T2._TurnoverCt1269, _Turnover1270 = _AccRgAT21278._Turnover1270 + T2._Turnover1270, _Fld1257 = _AccRgAT21278._Fld1257 + T2._Fld1257, _TurnoverDt1271 = _AccRgAT21278._TurnoverDt1271 + T2._TurnoverDt1271, _TurnoverCt1272 = _AccRgAT21278._TurnoverCt1272 + T2._TurnoverCt1272, _Turnover1273 = _AccRgAT21278._Turnover1273 + T2._Turnover1273, _Fld1258 = _AccRgAT21278._Fld1258 + T2._Fld1258, _TurnoverDt1274 = _AccRgAT21278._TurnoverDt1274 + T2._TurnoverDt1274, _TurnoverCt1275 = _AccRgAT21278._TurnoverCt1275 + T2._TurnoverCt1275, _Turnover1276 = _AccRgAT21278._Turnover1276 + T2._Turnover1276
FROM tt14 T2
WHERE (T2._Period = _AccRgAT21278._Period AND T2._AccountRRef = _AccRgAT21278._AccountRRef AND T2._Fld1254RRef = _AccRgAT21278._Fld1254RRef AND (T2._Fld1255RRef == _AccRgAT21278._Fld1255RRef) AND (T2._Value1_TYPE == _AccRgAT212
99% времени выполняются такие запросы с разными наборами where.
При этом в файловом режиме 1С этаже операция выполняется за 10 минут.
Тестировалось на linux и на windows, эффект одинаковый. Уважаемый ALL подскажите куда копать, как вернуть живость системе.
Мне кажется вам лучше в
Мне кажется вам лучше в поддержку 1С обратится, там вам более квалифицированную помощь смогут оказать.
Я лишь могу посоветовать посмотреть планы запросов и проверить наличие необходимых индексов.
Про 1С, мне кажется что 1С
Про 1С, мне кажется что 1С тут не причем. 1С выдает вполне разумный запрос, а вот постгри его выполняет непозволительно медленно. Причем одинаково медленно на ноутбуке под W7 версия 9.1 и на сервере c двумя ксеонами и рейдами под Linux версия 9.0.
База маленькая, количество записей к изменению тоже не так что примерно 90000. Мое личное мнение что это или особенность постгри или что-то надо подкрутить. Эти же данные в файлом режиме 1С обрабатываются за 10 минут. Сегодня поставлю MS SQL для сравнения посмотрю на этот запрос, но там такого размера базы проблем никогда не было.
Подскажите как посмотреть на план исполнения запроса в котором выборка идет из временной таблицы.
Про 1С я сказал, потому что
Про 1С я сказал, потому что они лучше знают свой продукт и должны уже бы иметь решение возникшей у вас проблемы - не одни же вы с ней столкнулись наверняка.
план запроса смотрится через EXPLAIN. Моё мнение - где-то у вас либо не созданы, либо не используются индексы. Надо это место найти через EXPLAIN и заставить индексы работать.
Подскажите пожалуйста, запрос
Подскажите пожалуйста, запрос использует временные таблицы, как мне их подсунуть в EXPLAIN?
Я пробовал получить схему запроса через pgAdmin, но он не видит временных таблиц.
Вот что указано на сайте 1С по этому поводу, проблем зарегистрирована пол года назад, решение пока не опубликовано.
"Причиной зависания является отсутствие актуальной статистики по таблицам, участвующим в запросе. Количество записей в этих таблицах сильно изменилось с начала транзакции (было 0 стало 140000). Autovacuum не видит этих изменений снаружи транзакции и статистика остается неактуальной."
Возможно вы сможете подсказать, какое-нибудь решение.
Если автовакуум не видит, то
Если автовакуум не видит, то никто не мешает вам прогнать по таблицам ручной сбор статистики:
VACUUM ANALYZE таблица
или даже
VACUUM FULL таблица
> Я пробовал получить схему запроса через pgAdmin, но он не видит временных таблиц.
А где в том запросе, что вы привели временные таблицы - не вижу.
1. VACUUM FULL таблица -
1. VACUUM FULL таблица - можно использовать снаружи транзакции?
2. tt14 - это предварительно сформированная временная таблица.
1. Все VACUUM выполняются вне
1. Все VACUUM выполняются вне транзакций. Выполнить надо один раз перез запуском просчёта для всех таблиц, которые в этом просчёте участвуют.
2. Ну так и чем отличается её использование от обычной в таком случае? Только тем, что вы удалите временную после отчёта, не более того. Так что EXPLAIN должен вам всё показать
Отличается тем что эта
Отличается тем что эта таблица не видна другой сессии. Т.е. получается что мне нужно создать полный пакет запросов, включая формирование всех временных таблиц? Или можно получить возможность отладки приостановив и подключиться к текущей сессии.
Извините если вопрос глупый, опыта с постгри у меня очень мало.
А вы знаете какая должна быть
А вы знаете какая должна быть эта временная таблица? Если да, просто создайте аналогичную и сделайте план запроса.
Там все не просто, этих
Там все не просто, этих временных таблиц создается штук 10-15, конечно по логам их можно выловить, но не хотелось бы, так не будет частоты эксперимента, так как в одной транзакции эти временные таблицы создаются неоднократно потом по ним запускается указанный update. Поэтому кончено интересно было бы смотреть план запроса внутри действующей транзакции с существующими временными таблицами.
Ну и что что неоднократно? По
Ну и что что неоднократно? По большому счёту вы мало что можете сделать с временными таблицами в плане индексов, а вакуум на них делать не надо, потому что они создаются с нуля и затем удаляются. Вам больше интересны постоянные таблицы и использование их индексов.
Вы кстати попробовали VACUUM ANALYZE на те постоянные таблицы, что используются в запросе перед запуском отчёта? Может этого и будет достаточно.
если не обращать внимания на
если не обращать внимания на временную таблицу, просто в запрос подставить таблицу из которой выбирается временная, получаю вполне разумную схему запроса, выборка по индексу и запись.
На сколько я понимаю ситуацию, тормоза начинаются в транзакции если количество изменяемых записей превышает примерно 20 тыс., учитывая что один апдейт меняет две три записи, наблюдать за ситуацией вне транзакции не интересно. Без транзакции запрос выполняется мгновенно, в транзакции доходит до полутора минут.
VACUUM ANALYZE перед запуском транзакции не помог.
проблемма при выгрузке в базу
вобшем поставили пропатченый постгрес на убунту подключили к нему 1с ку начали выгружать в информационную базу и вот ошибки повалились
Попытка вставки неуникального значения в уникальный индекс:
ERROR: could not create unique index "files_pkey"
DETAIL: Key (filename)=(id.pfl_) is duplicated