Postgree, тормоза при проведении документов

1. user2126823 11.02.25 07:30 Сейчас в теме
Приветствую!

Конфигурация: виртуальная машина , 8 ядер Ryzen 9 7900X , 16GB, SSD Samsung 990PRO , Win 10 PRO, PostgreSQL_1C_16.6_64bit , Платформа 1С 8_3_25_1520, база 1С Бухгалтерия, нетиповая, размер 15 Гб.

С бухгалтерской базой работает 10 человек.

В тесте Гилева : в однопоточном - 45 баллов, в многопоточном - после прохождения теста рекомендованное количество пользователей - 160.

Через dt выгрузил базу из MS SQL и загрузил в PostgreSQL. Часть документов стала зависать при проведении. Зависает на 5-10 минут.
Например: обычное требование-перемещение проводится 5 минут.
Поступление из переработки - проводится 15 минут.
В момент зависания что на сервере PostgreSQL , что на сервере приложений 1С активность нулевая, диск и процессор в пределах 0-1% загрузки.
При этом зависают при проведении не все типы документов, например документы реализации , кассовые - это все работает ок.

Перезаливал базу повторно из dt, выполнял на базе vacuumdb и reindexdb, пробовал enable_nestloop = off , обновился на версию платформы 8_3_25_1520, выполнял тестирование и исправление с реструктуризацией таблиц.
Все отлично отрабатывает , ошибок нет, но при этом документы по прежнему проводятся по 10 минут.

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

Или дело не в PostgreSQL, а в коде 1С. Тут да, база не типовая, но требование - накладная то типовая, почему проводится так долго...
Прикрепленные файлы:
postgresql.conf
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. paulwist 11.02.25 08:50 Сейчас в теме
Настройте тех.журнал/либо через Замер производительности, посмотрите в каком месте тормозит. (пальцем в небо, скорее всего индексов не хватает)
3. user2126823 11.02.25 19:07 Сейчас в теме
(2) сделал замер производительности , получил вот такой результат (во вложении)
получается 98% времени тратится на операцию МенеджерЗаписи.Прочитать();
как теперь это оптимизировать?
Прикрепленные файлы:
4. starik-2005 3163 11.02.25 23:32 Сейчас в теме
(3) ТиИ, реструктуризация.

выполнял тестирование и исправление с реструктуризацией таблиц
Куда нажимал, что крутил?
Конфигурация: виртуальная машина , 8 ядер
Что там с включением в биосах аппаратной виртуализации? Что за виртуальная машина?

ЗЫ: эта тема раз в полгода поднимается, до сих пор 1С не может написать об этом большими буквами на своем желтом заборе.
5. user2126823 12.02.25 06:58 Сейчас в теме
(4)
Куда нажимал, что крутил?

Тестирование и исправление с опциями : проверка логической целостности, реиндексация, пересчет итогов, реструктуризация.
НЕ помогло.

(4)
ТиИ, реструктуризация.

Ок, еще раз запустил только реструктуризацию. Эффекта нет, такие же тормоза при проведении.

(4)
Что там с включением в биосах аппаратной виртуализации? Что за виртуальная машина?

Все что надо - включено, виртуальная машина Hyper-V , второго поколения.
6. starik-2005 3163 12.02.25 07:38 Сейчас в теме
(5) Ну тогда собирай планы выполнения запросов. Долгое чтение прямо говорит о том, что нет индексов, или они по какой-то причине не используются. Сколько записей в таблице аналитик? Какие индексы у нее есть? Какой запрос генерит 1С?

Я бы пошел таким путем:
0. Посмотрел бы запрос и план. Для начала можно просто сохранить куда-нить.
1. Грохнул бы индексы вообще все у таблицы аналитик.
2. Добавил бы индексы по ключам из where запроса, который генерит 1С при чтении менеджером записи.
3. Запустил бы запрос в консоли постгреса с explain, посмотрел бы, что поменялось.
4. Если время выполнения стало нормальным, то оставил бы все как есть, записав, что и как, ну и продолжил бы ждать ответа каких-нить людей, которые в этом чтло-то понимают.

Предположу, что в последних релизах, если сохроанять совместимость уровня 8.3.17, а может даже если вообще ее сохранять любую, все работает так себе. Я заметил, что на 26-й версии гилев в файловой аж в 2 раза медленнее работает, если стоит совместимость базы теста по умолчанию. Если убрать совестимость, то все становится нормально. В серверной базе тоже при убирании совместимости растет производительность, но не в два раза, а на 5-10%. Но после изменения совместимости тоже нужна реструктуризация. Т.е. сначала поднимается совместимость, потом запускается реструктуризация, потом уже тестится.
VyacheslavShilov; user1619761; +2 Ответить
7. user2126823 13.02.25 12:43 Сейчас в теме
(6) в 1С я не силен , тут надо уметь в отладку 1С

Доп. сведения:
берем документ, который проводится 5 минут.
Это Склад - Расход материалов (требования-накладные)
В документе 14 позиций номенклатур разного количества.
ОК, делаем копированием из этого документа два документа : в первом оставляем первые 7 позиций, остальные удаляем, во втором - вторые 7. Т.е. просто делаем то же самое, только двумя документами , вместо одного.
Так первый проводится за 10 сек.
Второй - за 3 минуты.
Это как?
Причем результаты воспроизводимы.

Т.е. у нас получается один и тот же запрос выполняется с разной скоростью в зависимости от того, с какой номенклатурой мы работаем.
Есть ли смысл тогда копать в сторону планов запросов? Т.е. я так понимаю что наша цель - получить sql запрос, который выполняется на СУБД , чтобы посмотреть с какими таблицами он работает и посмотреть индексы этих таблиц. А сейчас получается что один и тот же запрос по разному отрабатывает для разной номенклатуры...

Просмотрел карточки номенклатуры из второго документа - они ничем не отличаются с точки зрения заполненности от карточек номенклатуры из первого. Но это я смотрел просто визуально в 1С. Может можно посмотреть как то еще?

Причем все это сугубо особенности работы с PostgreSQL, в файловой все ок, проводится за секунду.
9. paulwist 13.02.25 13:04 Сейчас в теме
(7)
Есть ли смысл тогда копать в сторону планов запросов? Т.е. я так понимаю что наша цель - получить sql запрос, который выполняется на СУБД , чтобы посмотреть с какими таблицами он работает и посмотреть индексы этих таблиц. А сейчас получается что один и тот же запрос по разному отрабатывает для разной номенклатуры...


Создайте файлик logcfg.xml с таким содержанием.

Положите а-ля, C:\Program Files\1cv8\conf

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="Сюда написать путь для лога, типа C:\Temp\MyLog" history="12">
<event>
<eq property="name" value="DBPOSTGRS"/>
<ge property="duration" value="50000"/>
</event>
<property name="all"/>
<property name="all">
<event>
<eq property="name" value="DBPOSTGRS"/>
</event>
</property>
</log>
</config>
Показать


в результате получите запросы выполняющиеся > 50 сек

Сохраните документ, результат в студию.
10. user2126823 13.02.25 20:04 Сейчас в теме
(9)
Сделал. Во вложении.
Запрос в файле я видел и в консоли PostgreeSQL через запрос показывающий выполняющиеся запросы
SEL ECT pid, age(clock_timestamp(), query_start), usename, query, state
FR OM pg_stat_activity
WHERE state != 'idle' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;

Но дальше я не знаю что с этим делать.
В запросе работа с таблицей _InfoRg18250
Если посмотреть индексы в PostgreeSQL через запрос
SEL ECT * FR OM pg_indexes;
то по таблице _InfoRg18250 видно 3 индекса (файл прилагаю).

Посмотрел коэффициент использования индексов через запрос
SELECT relname,
100 * idx_scan / (seq_scan + idx_scan) percent_of_times_index_used,
n_live_tup rows_in_table
FR OM pg_stat_user_tables
WH ERE seq_scan + idx_scan > 0
ORDER BY n_live_tup DESC;

по таблице _InfoRg18250 это 96

тогда почему тормоза то?
Прикрепленные файлы:
25021323.log
data-1739465529866.csv
data-1739466033744.csv
11. starik-2005 3163 13.02.25 22:34 Сейчас в теме
(10)
log

Execution Time: 0.030 ms

Все запросы выполняются за ноль целых хрен десятых миллисекунд. Так что проблема где-то еще походу. По всей видимости надо собрать полный лог, а не только базу данных. Что-то там еще происходит. Может ждет авторизации товарища майора, который вручную каждый раз кнопку жмет в кармане )))

ЗЫ: если запрос в консоли постгреса запустить, то сколько времени это занимает?
14. user2126823 14.02.25 04:52 Сейчас в теме
(11)
если запрос в консоли постгреса запустить, то сколько времени это занимает?

в консоли - быстро
19. starik-2005 3163 14.02.25 10:52 Сейчас в теме
(14) Ну и о чем это говорит? О том, что дело не в запросе. Т.е. не в СУБД. Дело в 1С. Нужно смотреть ВСЕ события техжурнала. Искать среди них те, которые выполняются дольше всего.
16. user2126823 14.02.25 07:42 Сейчас в теме
(11)
если запрос в консоли постгреса запустить, то сколько времени это занимает?

дополню:
если просто выполнить этот запрос в консоли - выполнится быстро
но если я нажимаю кнопку "провести документ" в 1С , и после этого начинаю смотреть активные запросы в консоли постгреса , то я вижу этот запрос, он появляется и далее он и выполняется, и выполняется, и выполняется ... pid не меняется , только age растет
Прикрепленные файлы:
17. Salimbek 13 14.02.25 08:33 Сейчас в теме
(10) Закинул лог в deepseek, оно ответило:
Рекомендации от ИИ
13. muskul 14.02.25 01:47 Сейчас в теме
(9)
(7)
в 1С я не силен , тут надо уметь в отладку 1С

тут надо убрать не нужную виртуалку для начала. зачем она вообще вам нужна?
8. Asgard90 13.02.25 12:56 Сейчас в теме
На виртуалке тех данные проца можно выкидывать, данные диспетчера задач туда же, очередность записи на диск так же. + я так понимаю вы все равно бухгалтерию типовую оптимизировать под свои задачи не будете. Почему не поставить платформу без виртуальной машины?
Вариант решения можно сделать следующий
12. _pl 13.02.25 22:51 Сейчас в теме
vacuumdb с какими флагами выполнялась? Статистика индексов обновлялась?
15. user2126823 14.02.25 04:56 Сейчас в теме
(12)
vacuumdb с какими флагами выполнялась? Статистика индексов обновлялась?


раз в сутки на все базы выполняется
vacuumdb.exe -a -z -F -v -j 4
reindexdb.exe -a -v -j 4
18. user2126823 14.02.25 09:40 Сейчас в теме
По ходу это виртуалка.

Попробовал Hyper-V - новая виртуалка - с нуля Win 10 PRO + Постгре 17 версии (думал, вдруг новая версия поможет) - новая база - импорт из dt - проблема в силе.

Обычный офисный комп - с нуля Win 10 PRO + Постгре 16 , аналогичный текущему - новая база - импорт из dt - провелось сразу же.

Гарантировано могу сказать только после переноса текущей машины на реальное железо.

Но почему?

Кроме проблемной базы на этой же виртуалке крутятся другие базы 1С - нареканий нет.
Мало того, даже в этой базе кассовые документы, платежки и др. проводятся нормально.
Да даже конкретно расход материалов из примера выше : с одними позициями проводится ок , с другими - виснет.
20. starik-2005 3163 14.02.25 11:23 Сейчас в теме
(18)
с одними позициями проводится ок , с другими - виснет
Чудес не бывает, но профилировать виртуалку я вам вряд ли предложу, ибо и сам с логами профилировщика вряд ли что пойму. Поставьте виртуалбокс, поглядите там. Может дело в каком-то механизме обмена данными между 1С и постгресом, который как-то через какое-то место фильтруется.
21. user2126823 20.02.25 07:32 Сейчас в теме
По итогу оказалось, что это была проблема даже не виртуальных машин как таковых , а конкретного хоста Hyper-V.

Сервер приложений 1С тоже работает как виртуальная машина.
И если виртуальные машины сервера приложений 1С и Постгреса работали на одном хосте - начинались вышеописанные косяки.
Попробовал вынести Постгрес на железо без виртуализации - работает нормально.
Но после попробовал мигрировать виртуалку Постгрес на другой хост Hyper-V - работает нормально .
После мигрировал виртуалку сервера приложений на тот же хост ,куда перевел Постгрес - работает нормально.

То есть как виртуальные машины сервер приложений и Постгрес работают нормально даже в рамках одного хоста.

Получается дело в конкретном хосте Hyper-V, где они были размещены изначально.
Переустановил там Hyper-V , после чего мигрировал обратно на него сервер приложений и Постгрес - работает нормально.
22. muskul 20.02.25 08:40 Сейчас в теме
(21) а можно все таки вопрос зачем виртуалка?
23. user2126823 20.02.25 10:19 Сейчас в теме
(22) отказоустойчивость, снижение времени восстановления

Если "упал" железный сервер: мне надо восстановится из резервной копии на другое железо - это время. Дальше, встает вопрос "что с базой". Не обязательно Постгрес , у меня есть ПО которое работает на СУБД Sybase. А до Постгрес работал MS SQL.
Если бэкап базы делается раз в сутки - то все, потеряли информацию за сутки. Если делается бэкап логов БД - докатываем базу из логов, это опять же время. Опять же как часто делаем бэкапы логов.

А что в случае, если это виртуальные машины Hyper-V.
У Hyper-V есть встроенный механизм репликаций. Настраивается в пару кликов мышкой, ничего сложного.
Есть основной сервер - где крутятся все критичные для бизнеса виртуалки. Есть резервный, куда постоянно реплицируются изменения с основного. Частоту репликации можно выставить 30 сек, 5 минут, 15 минут.

Если падает хост с виртуалками - просто стартуем виртуалки на резервном сервере.
Нет простоя по времени восстановления на другое железо , максимальные потери данных в БД = выставленной частоте репликации. В моем случае приемлемо 5 минут - с учетом интенсивности работы операторов с БД нет проблем повторно ввести документы за последние 5 минут.

Плюс у Hyper-V есть расширенная репликация. То есть с основного реплицируем на резервный, а потом с этого резервного можно реплицировать еще на один, дополнительный сервер. Доп. страховка.

Или вопрос обслуживания: надо обслужить сервер по железу. С виртуалками - переключаемся на другой сервер по сути без простоя по работе: либо через "живую" миграцию, либо через ту же "плановую" репликацию, далее спокойно занимаемся обслуживанием.
24. starik-2005 3163 20.02.25 10:48 Сейчас в теме
(23)
Если "упал" железный сервер
Если "упал" железный сервер с виртуалкой? У вас там второй есть?

В постгресе есть потоковая репликация. Фактически все основано на сохранении журнала, файлы которого можно выгружать в любое место - достаточно путь в конфигах прописать. Периодически делать бэкап кластера. И если у вас два сервера, то куда лучше репликацией это сделать, чем переносом на "вторую виртуалку", т.к. второй сервер может быть в режиме "всегда готов".

Ну и есть проблема постгреса при работе с сетевыми хранилищами - он слишком много файликов пишет и держит открытыми, на любой байт для каждого файлика поедет полный пакет по сетке. Так что идея с переключением СХД тоже сильно снижает производительность. Хотя... Тут же 7900Х - о каких СХД я говорю )))
25. user2126823 20.02.25 11:12 Сейчас в теме
(24) да, не у всех есть возможность строить кластера на СХД и вот это вот все
я вам даже больше скажу : под сервер может использоваться обычный мощный десктоп ), даже без ECC памяти
26. starik-2005 3163 20.02.25 11:59 Сейчас в теме
(25)
обычный мощный десктоп
Основная проблема - это параллельность работы с памятью. В серверах от 4х каналов памяти, в десктопах обычно всего 2, за которые конкурируют все те юзеры, которые хотят что-то &НаСервере выполнить.
27. muskul 21.02.25 02:24 Сейчас в теме
(23)
Если "упал" железный сервер: мне надо восстановится из резервной копии на другое железо

А что падает? диски, так если на виртуалке диски то будет тоже самое. а если не дай бог шифратора поймают, то он точно так же через пять минут себя же и скопирует.
Если есть рядом еще одна железка, то опять же зачем виртуалка, в части 1с конечно геморой с лицензиями и переносом.
Спасибо за подробный ответ, раньше хотя бы так развернуто не пытались ответить.
28. user2126823 21.02.25 05:26 Сейчас в теме
(27) если дублировать каждый сервис в отдельности - железа не напасешься.
Есть сервисы, которые критичны для бизнеса, но у них невысокие системным требования.
Они могут не уметь в кластер , но надо выполнить требование RTO = не более 15 минут и не потерять данные.
Как этого добиться без виртуализации?

Выше совершенно справедливо заметили, что Постгре умеет в кластер актив-актив, и если есть два сервера то лучше сделать так.
Ок, но мы решим задачу только для Посгре, заняв под него два железных сервера.
А как насчет специализированного ПО , например довольно древнего СКУД , для которого слова "кластер" вообще в словаре нет ), там судя по интерфейсу корни растут из времен Windows XP.
Но для этого ПО так же нужно выполнить условия по времени восстановления и не потерять данные.

Виртуализация позволяет более эффективно использовать железо , на одном сервере работают несколько виртуалок без ущерба в производительности для каждой в отдельности.
Репликация позволяет дублировать актуальное состояние машин на резервную площадку, вне зависимости от того какое ПО используется и умеет оно в кластер или нет.
Да, это не актив-актив , если что - надо будет врукопашную переключится, но это займет минуты и это лучше, чем восстанавливать с нуля.

Для бэкапа виртуалок использую Veeam , через него же можно восстановится на любую дату в рамках заданной глубины резервного копирования в том числе в режиме мгновенного восстановления.
29. mpeg1989 131 22.02.25 21:17 Сейчас в теме
Postgres надо ставить на Linux. Зависает файловая система Windows, она просто не предназначена для работы с таким количеством файлом.
VyacheslavShilov; +1 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот