Тормоза базы после загрузки бэкапа

Форум Администрирование Производительность и оптимизация (HighLoad)

1. user691969_ur0ck89 23.01.22 18:16 Сейчас в теме

Здравствуйте,

Сервер БД: Postgresql 9.6.1
Версия платформы 1С: 8.3.17.1549
OS - Linux Ubuntu Server 16.04 LTS
БД на SSD, 16GB RAM, Core i7

Предыстория: главбух пыталась сделать копию базы, сделала через конфигуратор бэкап *.dt и загрузила его же в "боевую", основную базу. Грубо говоря, пятничный бэкап залила в рабочую базу и затёрла изменения за понедельник, откатила, так сказать. После этого начались проблемы: жутко тормозит при "крупных" операциях, например, закрытие месяца. Если ранее процедура занимала 7-8 минут - сейчас же это всё дело занимает 3 часа, а то и больше. Ребята 1Сники, у которых мы обслуживаемся со своей стороны всё посмотрели, протестировали, проблему не выявили. Настала очередь админа.
Размер БД небольшой, 3828 MB.
Поковырялся в настройках PostgreSQL, привёл конфиг по рекомендации сервиса PGtune, эффекта не возымело.
Так как autovacuum выключен, решил оптимизировать через vacuum, размер БД уменьшился до 2828 MB. Но результат опять отрицательный.

Подскажите пожалуйста, в какую сторону копать.
Заранее премного благодарен.

По теме из базы знаний

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

3. uriah 24 23.01.22 20:18 Сейчас в теме

(1)

Предыстория: главбух пыталась сделать копию базы, сделала через конфигуратор бэкап *.dt и загрузила его же в "боевую", основную базу. Грубо говоря, пятничный бэкап залила в рабочую базу и затёрла изменения за понедельник, откатила, так сказать. После этого начались проблемы: жутко тормозит при "крупных" операциях, например, закрытие месяца. Если ранее процедура занимала 7-8 минут - сейчас же это всё дело занимает 3 часа, а то и больше. Ребята 1Сники, у которых мы обслуживаемся со своей стороны всё посмотрели, протестировали, проблему не выявили. Настала очередь админа.

А если пересоздать базу на постгрес и тудf залить dt

7. XAKEP 24.01.22 13:41 Сейчас в теме

(1)

Подскажите пожалуйста, в какую сторону копать.

ограничить права на такие действия :
главбух пыталась сделать копию базы, сделала через конфигуратор бэкап *.dt и загрузила его же в "боевую", основную базу. Грубо говоря, пятничный бэкап залила в рабочую базу и затёрла изменения за понедельник, откатила, так сказать.

8. user691969_ur0ck89 24.01.22 16:44 Сейчас в теме

(6) спасибо, вернул назад, протюнил, не помогло.
Итоги пересчитал через конфигуратор.
Базу пропылесосил вакуумом: vacuumdb -U postgres --full --analyze --dbname=имя_бд
Вроде всё завершилось корректно, в консоли ошибок небыло, но всё по прежнему крайне долго.

(7) увы, в конфигуратор у неё доступ должен быть...

2. testerpro1 23.01.22 19:17 Сейчас в теме

Комманда analyze выполняется? Если analyze не поможет, взять копию до "бэкапа", после и проверить на другом компьютере.

4. ansh15 23.01.22 21:57 Сейчас в теме

Здесь просто заново пересчитали статистику.
Собственно в (2) об этом сказано.
После загрузки из dt, как и после загрузки дампа( pg_dump/pg-restore) статистику надо создать вручную, так как в выгрузках ее нет. vacuumdb --analyze имябазы, начиная с 9.5 редакции PostgreSQL этот процесс может выполняться параллельно в несколько потоков.
И включить autovacuum, так же нельзя.
Заодно и итоги посмотреть, может слетело что..

5. user691969_ur0ck89 24.01.22 07:28 Сейчас в теме

Ребят, всем спасибо.
В postgresql.conf поставил enable_nestloop=off, как рекомендуют на ИТС, вроде зашевелилось.

6. user1326147 24.01.22 09:29 Сейчас в теме

(5)https://infostart.ru/public/733782/

Для отправки сообщения требуется регистрация/авторизация