Есть достаточно большая база - postgre показывает 50 Гб. Типовая бухгалтерия 3.0 на последней версии платформы, сервер 64 бит. Начала сильно тормозить. Обычные несложные запросы долго выполняются. Например, сверка по контрагенту за пару лет с парой десятков документов заполняется минут 5. Какие операции можно выполнить, чтобы ускорить/оптимизировать?
По колёсам стучал, стекла протирал. В postgre полный vacuum с анализом и реиндексацией сделал. Эффекта нет. Может быть что-то ещё?
Что может помочь из действий в 1С? Пересчёт итогов?

(0) "Есть достаточно большая база - postgre показывает 50 Гб." - это разве большая?)
замер производительности, посмотреть планы запросов и т.д.

когда последний раз делали вакуум?

Может вообще вирусняк поймали и сервак ваш майнит дяде Пете крипту?

(0) как часто делаешь вакуум? Чем кроме постгри на сервере? Сервер железный или вирт? Что показывает перфмон по загрузке? да этих вопросов вагон перед тем как перейти к самому постгри.

(0) 1. Для начала тупой вопрос:
Выгрузку в DT и загрузку делали? Сразу после тормозит?

(5)+ Естественно файлы сначала в тома внешние выкинуть
И какой размер DT остается?

(6) ну не настолько-же постоянно файлы дёргает, хотя...

а потом выяснится что это в пятом рейде диск вылетел

Какой версии постге стоит?

(9) Postgre 14.4

(2) Вчера

(3) Не, загрузки проца особо нет.

(4) У меня скорее вопрос, что можно сделать средствами 1С?

(13) Ничего, фреш не тормозит на postgre

(13) Проблема вряд ли в 1С.
50Гб - это небольшая база. Во всяком случае это не тот размер, на котором что-то может тормозить.

(13) средствами 1с только РБ попинать
https://its.1c.ru/db/metod81/content/5654/hdoc

(0) "Позовите специалиста" (С)

(17) Так я и обратился к специалистам. Или тут нет?

(0) Причин может быть много, от загибающегося диска, кривых запросов в 1С, и даже до кривой настройки PG.

Посмотри в отладчике что тормозит конкретно.

Я видел как включение пары полей в запрос вешало систему намертво, особенно в условиях "ИЛИ / В()"

Посмотрите ещё на RLS может при обновлении влиять.

(22) RLS отключен.

(21) База типовая. Тормозит всё. Конкретно посмотрел в отладчике заполнение акта сверки. Тупит непосредственно сам запрос. Выполняется 10 минут. В энергосбережении поставил (сисадмины, превед) минимальное состояние проца 100% - стало 5 мин. Неплохое ускорение, но всё равно это слишком долго. Там в итоге записей пара десятков получается. Скорость сильно падает, если увеличивать период выборки. Видимо сам регистр бухгалтерии работает не эффективно.

Ещё странная деталь. При размере базы в 40 Гб Postgre показывает Size of temporary files 140 Gb. Ещё два дня назад было 90 Гб. Пытался гуглить, везде пишут, во-первых, не трожь, оно само. Во-вторых, что это не текущий размер временных файлов, а накопленным итогом.
Возможно из-за каких-то проблем с памятью Postgre начинает всё скидывать на диск. Настройки были нормальные, ничего не менял. Может сисадмины что-то натворили.

(4) Монитор показывает дисковый ввод-вывод 30 Мбит/с. Хз, это много или мало? И сетевой обмен 1 Мбит/сек. Всё это postgre генерирует.

(0) а в твоей вселенной "последней версии платформы" что значит?

(27) 8.3.22.1709

а ещё есть такой незакрытый баг

https://bugboard.v8.1c.ru/error/000128674
Производительность выполнения запросов

Код ошибки: 60001790
Статус: Принята к исправлению Зарегистрирована: 01.08.2022
Продукт: "Технологическая платформа"

Описание:
При использовании СУБД PostgreSQL для некоторых запросов при обращении к регистру бухгалтерии наблюдается низкая производительность выполнения.

(29) Не пойму, это к какой версии относится?

(30) ко всем актуальным на дату 01.08.2022 и после

8ка ещё сырая. попробуй в файловой )

(32) Сейчас конвертну в 7.7. Пусть работают. Так надёжнее. :)

Если тест Гилева показывает 10-15 баллов на этой инсталляции, то ничего удивительного.

(0)[Начала сильно тормозить] - Установить, примерно с какого момента это началось, можно? Или по-нарастающей?

Вырубил всех пользователей. Фоновых заданий нет. А дисковая нагрузка в 33 Мбит/с так и осталась. Постоянно что-то пишет в/из pg_stst_tmp

+(35)А так вполне может и аппаратное что то быть. Диск, память, мать, Бп..вариантов масса.

(35) Удалил все логи из каталога сервера и переключил на последовательный формат. После этого стали жаловаться. Но не думаю, что это мешает выполнению простых запросов.

(36) Ну вот. особенности поведения PostgreSQL под Windows,старая известная проблема.
Переходить на Linux - кардинальное решение.Там этого нет в принципе.

(39) Дык раньше работало нормально.

(40) в шестом посте ссылка на объяснение почему так происходит - Начались проблемы с производительностью сервера 1С

(38)[Удалил все логи из каталога сервера] - ну в 1-е время вполне возможный эффект, пока кэши заполнятся заново.
[переключил на последовательный формат] - попробуйте вернуть как было.

(41) Так вроде постгреспро решили эту проблему для винды. Хотя непонятно, в сборке от 1С есть этот патч или нет.

(36) В журнале постгри что то аномальное есть?

(41) Ещё не посмотрел, но перенёс pg_stat_tmp на RAM disk. Не помогло.

(45) если в этом проблема, но не очень то и поможет.

(5) Всё гениальное просто. Выгрузил в dt, на всякий случай дропнул базу, загрузил обратно. Запрос выполнялся 255 секунд, теперь 0.5. :)
Беспокоит только, что для вновь созданной 40-ка гиговой базы postgre показывает 20 гигов временных файлов. Продолжу наблюдение.
Ну и хотелось бы понять, что всё таки это было? Где тут задумчивый смайлик.

(26) диски какие? Рейд если есть какой? Длина очереди записи/чтения какая? На сколько % нагружен серевой интерфейс (надеюсь ни кто такую фигню как буферизация сетевого обмена не вкл?)

(48) >буферизация сетевого обмена

Это где такое?

(43) Тестировать надо. Потом окажется, что решили только в платных редакциях Postgres Pro.
Так что, лучше Linux )