Вход | Регистрация
    1  2
1С:Предприятие :: 1С:Предприятие 8 общая

КА2, Postgresql и дикие тормоза при проведении регламентных документов

КА2, Postgresql и дикие тормоза при проведении регламентных документов
Я
   vheathen
 
15.08.19 - 12:25
Приветствую!

Коллеги, есть у моего заказчика проблема, которую подрядчики, занимающиеся 1С, пытаются решить "в лоб". Но, возможно, есть какие-то ещё варианты?

Дано:
Терминальный сервер на винде с толстыми клиентами
Linux c сервером 1С 8.3.13.1644 и postgresql 10.7.1 от postgres pro
Конфигурация КА2 2.4.8.84

В целом всё работает нормально, но у бухгалтера какие-то безумные проблемы. Проведение одного регламентного документа может занимать несколько минут (от 3 до 8!!!). Я не 1сник, я занимаюсь основной инфраструктурой, но так как спецы ничего сказать не могут, приходится пытаться решить проблему самостоятельно. Все возможные оптимизации уже сделаны, конфиг постгреса я изнасиловал уже всеми знакомыми и незнакомыми способами. Памяти навалом - раз в 5 больше, чем размер базы. В момент зависаний видно, что одно ядро полностью загружено процессом postgres, pg_top тоже показывает, что висит на UPDATE'ах и INSERT'ах (в основном на UPDATE).

Я грешил на скорость работы дисковой подсистемы, но на машине с точно такими же характеристиками (даже слабее - меньше памяти) на MS SQL всё работает вполне себе нормально. То, что характеристики одинаковы - 100%, это виртуальные машины, одна останавливается, другая запускается, хранилище образов дисков одно. Но MS SQL - это куча денег, которые клиент платить не хочет, а я не готов участвовать в использовании нелегального ПО. Да и вообще, что это за решение проблемы - потратьте кучу денег?

С заказчиком расставаться не хочется. Поэтому хочется решить проблему адекватным способом. Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.

В какую стороную мне копать, подскажите, пожалуйста?
 
 
   vheathen
 
101 - 16.08.19 - 08:01
(99) параметры какие или чего?
   piter3
 
102 - 16.08.19 - 08:01
(96) в режиме 1С:Предприятия. «Администрирование — Поддержка и обслуживание —  Регламентные операции — Управление итогами и агрегатами» или «Все функции — Стандартные — Управление итогами», в обоих случаях можно установить период рассчитанных итогов;
   piter3
 
103 - 16.08.19 - 08:01
(101) даты,аналитика и т.д
   arsik
 
104 - 16.08.19 - 08:01
(56) > Вакуум аналайз делается еженедельно.
Аналайз нужно делать намного чаще. Например пару раз в день. Для баз с бухгалтерией еще чаще.
(92) Замер производительности на сервере сделали?
>более 99% времени (407 секунд) - это строка Результат = Форма.Записать(ПараметрыЗаписи);
Это замер только на клиенте.
   vheathen
 
105 - 16.08.19 - 08:02
(102) установить можно, но я хотел сначала проверить текущие, но не нашёл, где.
   ildary
 
106 - 16.08.19 - 08:02
(92) у меня был такой случай - база (УТ11, небольшая, на postgree) сильно тормозила при проведении РТиУ, анализ показал, что один из регистров необычно распух, а распух он оттого, что кто-то ввёл документ датой 16.08.0015. Перенос документа и пересчёт регистра привёл к тому, что на том же оборудовании проведение РТиУ стало выполняться не минуту, а секунд 10. Ещё проверьте, нет ли документов в будущем (тоже влияет на скорость).
   piter3
 
107 - 16.08.19 - 08:02
(105) Блин да скажи даты итогов у регистров
   vheathen
 
108 - 16.08.19 - 08:03
(107) нажал кнопку "Установить итоги...". 15 секунд, итоги на 31.07 и 31.08 (для бухгалтерии)
   piter3
 
109 - 16.08.19 - 08:04
(108) Теперь попробуй провести,даже если будет тупить хотя бы это проверили
   piter3
 
110 - 16.08.19 - 08:05
(108) Потом на тестовой базе по слоном в конфигураторе,пересчитать итоги
   vheathen
 
111 - 16.08.19 - 08:09
(104) я не знаю, как включить логгирование на сервере. Конфигурацию добавил, в (58) публиковал содержимое, файлы логов появились, но они пустые.

(109) лучше не стало, разве что ещё хуже на пару сотен милисекунд.
   piter3
 
112 - 16.08.19 - 08:11
(111) Попробуй через конфигуратор пересчитать,в (106) по делу написали
   vheathen
 
113 - 16.08.19 - 08:13
(112) да, сейчас попробую, жду, пока перепроведение завершится. Это ж 7 минут.
   arsik
 
114 - 16.08.19 - 08:32
(111) Нужно включить отладку на сервере https://programmist1s.ru/vklyuchenie-otladki-na-servere-1s/
   vheathen
 
115 - 16.08.19 - 08:49
(114) понял. у меня не винда, но как сделать - понял, сейчас дождусь окончания Тестирования и исправления... и проверю, что скажет.
   piter3
 
116 - 16.08.19 - 09:14
(115)Ну как
   ildary
 
117 - 16.08.19 - 09:19
(115) Вы моё предположение проверили? Берёте любой пузомер и смотрите на размеры регистров - если есть заметно большой - делаете запрос к максимальной и минимальной дате к нему.
   Фрэнки
 
118 - 16.08.19 - 09:29
(117) т.е. предположение в том, что конкретная СУБД содержит данные, которые в нее "залили" каким-то образом за относительно большой период. И теперь расчет себестоимости происходит плохо на любой СУБД, но при этом на постгри это выглядит заметно хуже. Как так?
   vheathen
 
119 - 16.08.19 - 10:39
(116) прошу прощения за паузу, хочу перепроверить. После Тестирования и исправления время выполнения каждого UPDATE уменьшилось до 1.2 секунды. Это тоже много, как по мне, но всё-таки в пять раз ниже, чем было. Ради интереса нужно попробовать тот же документ перепровести на рабочей базе в ms sql с замером времени выполнения.

Сейчас я поставил 11 пострес, залил в него базу, убедился, что документ проводится 400+ секунд и запустил Тестирование и исправление. Как закончится - ещё раз проверю время выполнения проведения того же документа.

Кстати, судя по цифрам, 9.6 работает чуть медленнее, чем 10-11. Довольно незначительно, но тем не менее.

(114) отладку я включил, флаг debug есть у служб, но где должны появиться логи - не понимаю. В месте, куда ссылается xml - пустые файлы логов.

(117) подскажите, пожалуйста, что есть "любой пузомер". Пока я не смотрел размеры регистров, не знаю, чем это можно сделать. Размер таблицы _accrgat261025 - 54MB + 54MB index = 110MB всего. После пересчёта итогов из конфигуратора размер данных уменьшился до 14МБ.
   dezss
 
120 - 16.08.19 - 10:41
(119) Теперь смотри минимальную и максимальную даты в регистрах (уже писали об этом).
debug - это для отладки на сервере. Теперь можешь запускать замер производительности еще раз и смотреть, какая строка дольше всего выполняется.
   vheathen
 
121 - 16.08.19 - 10:44
(120) Не знаю, как сделать это из 1С, но из командной строки так:

test_ka2=# select max(_period) from _accrgat261025;
         max
---------------------
 3999-11-01 00:00:00
(1 строка)

test_ka2=# select min(_period) from _accrgat261025;
         min
---------------------
 2018-12-01 00:00:00
(1 строка)

3999-11-01 00:00:00 - это пять. Как выяснить, откуда этот период, не подскажете?
   piter3
 
122 - 16.08.19 - 10:47
Так там смещение же в 2000 лет идет,то есть вбили 1999 год что ли
   vheathen
 
123 - 16.08.19 - 10:47
По поводу серверной отладки: после включения дебага на сервере вывод принципиально не поменялся: https://habrastorage.org/webt/pd/dw/wa/pddwwad2blmqu9ilfbq0ahnzuze.png

Но это уже после перепроведения итогов, до было около 417 секунд на сохранение формы (первая строка).
   dezss
 
124 - 16.08.19 - 10:47
(121) Смотри на эту запись/записи.
Лучше сделай запрос из 1с-ки,там понятней будет, откуда она.
   edwin
 
125 - 16.08.19 - 10:49
(121) это нормально, слушай если я правильно тебя понимаю то один и тот же запрос, выполняемый 1с и выполняемый из командной строки отличается в 1000 раз? если так то логично подумать что проблема в плане запроса, план запроса 1с и план запроса из командной строки отличаются.
   dezss
 
126 - 16.08.19 - 10:51
(123) А службу рестартовал после дебага?
Чета не видно ничего серверного в скрине.
(125) Точно нормально, что максимальная 3999-11-01 00:00:00, при минимальной 2018-12-01 00:00:00?
Если че, про смещение знаю, но тогда и минимальная должна была бы сместиться (или в минимальной и есть проблема?).
   vheathen
 
127 - 16.08.19 - 10:53
(126) конечно рестартовал. флаг у исполняемого файла присутствует.

Там такая запись не одна, кстати:

test_ka2=# select count(_period) from _accrgat261025 where _period = '3999-11-01 00:00:00';
count
-------
  7239
(1 строка)

А следующая запись уже нормальная:

test_ka2=# select _period from _accrgat261025 where _period <> '3999-11-01 00:00:00' order by _period desc limit 1;
       _period
---------------------
2019-07-01 00:00:00
(1 строка)
   vheathen
 
128 - 16.08.19 - 10:54
(124) я из 1ски не умею, к сожалению.
   ildary
 
129 - 16.08.19 - 10:59
(128) открыть в режиме предприятия подозрительный регистр, отсортировать по дате (кликом по заголовку) и смотреть на максимальную/минимальную дату.
   edwin
 
130 - 16.08.19 - 10:59
(126) 3999-11-01 00:00:00 это хранение текущих итогов, соответственно смещения дат нет.
 
 Рекламное место пустует
   edwin
 
131 - 16.08.19 - 11:01
(130) но это не должно влиять на производительность
   vheathen
 
132 - 16.08.19 - 11:01
(125) после перепроведения итогов - нет. Из командной строки дольше.
   ansh15
 
133 - 16.08.19 - 11:04
(119) Попробуй http://catalog.mista.ru/public/978816/
Работает с сервером приложений 1С и PostgreSQL на Linux. Клиент 1С должен быть на Windows.
   Arbuz
 
134 - 16.08.19 - 11:17
Вот это, я понимаю, триллер! Извините за оффтоп. Сами планируем переход с упп на ка. Сейчас более-менее сносно (я бы сказал, чуть менее, чем терпимо) работает на постгре 300+ юзверей.
   vheathen
 
135 - 16.08.19 - 11:21
(129) я не знаю, что это за регистр, к сожалению. у меня есть только название таблицы. Я понимаю, что это какой-то аналитический счёт, но и только. Как понять, к чему и где его найти в 1С - не знаю, извините.
   ildary
 
136 - 16.08.19 - 11:57
(135) Вам либо сюда - (133), либо в 1С в консоли запросов написать запрос с выбором даты, как в (121).
   edwin
 
137 - 16.08.19 - 13:46
Автор как успехи?
   rphosts
 
138 - 16.08.19 - 14:50
(122) у него постгри и там никаких сдвигов нет! Сдается мне там с границей пипец!
   rphosts
 
139 - 16.08.19 - 14:51
+ (138) а, не, это-ж актуальные итоги!
   Фрэнки
 
140 - 16.08.19 - 15:11
(139) да, сама именно эта строчка с датой - это актуальные итоги так вводятся
   vvp91
 
141 - 16.08.19 - 15:16
(127) Дай вывод строки
select _period, count(*) from _accrgat261025 group by _period
   edwin
 
142 - 16.08.19 - 15:55
Автор вот кстати интересная статья: http://catalog.mista.ru/public/177171/ и не менее интересные комментарии 58 и 128
   vheathen
 
143 - 17.08.19 - 10:50
Коллеги, прошу прощения, вчера пришлось срочно переключиться на другие задачи.

(141)
test_ka2=# select _period, count(*) from _accrgat261025 group by _period;
       _period       | count
---------------------+-------
2019-07-01 00:00:00 |  7766
2019-04-01 00:00:00 |  7782
3999-11-01 00:00:00 |  7239
2018-12-01 00:00:00 |  5629
2019-03-01 00:00:00 |  7488
2019-05-01 00:00:00 |  7875
2019-06-01 00:00:00 |  7936
2019-02-01 00:00:00 |  7316
2019-01-01 00:00:00 |  7124
(9 строк)
   vheathen
 
144 - 17.08.19 - 10:58
Меня сильно смущает, что операция по обновлению записи в таблице с 66 тысячами строк выполняется больше секунды. И таких операций масса.

Мне пришлось сделать ещё одну копию базы, потому что я экспериментировал с документом в уже закрытом периоде, поэтому сейчас восстановлю её и замерю производительность в MS SQL и в PostgreSQL на то же базе на одном документе.
   vheathen
 
145 - 17.08.19 - 11:40
На новой базе сразу после восстановления и vacuum full analyze и reindex документ проводится 9,5 секунды. На той же самой базе в MS SQL - 0,956 секунды. Разница в 10 раз.
Сейчас доеду до другого места - продолжу.
   Фрэнки
 
146 - 17.08.19 - 11:48
(145) Это сейчас сами сервера 1С одинаковые? Эти две СУБД подцеплены к одному и тому же серверу или это разные сервера 1С в разных ОС ?
   edwin
 
147 - 17.08.19 - 12:55
(145) Как я вижу ситуацию:
1.В таблице accrgat261025 накопились записи с нулевыми значениями, чем это черевато можно прочитать в этой статье: http://catalog.mista.ru/public/177171/ что делать озвучено в комментарии 128 к этой статье.
2.Посе того как записи с нулевыми значениями были удалены (Тестирование и исправление - Пересчет итогов) и обновления статистики vacuum full analyze стало лучше но
3.Запросы из 1с postgres выполняет по неоптимальному плану, при наличии записей с нулевыми значениями разница запроса из 1с и запроса из консоли доходила до 1000 раз(миллисекунды и секунды)
4.Возможные решения: переписать код запроса, обновить конфигурацию(возможно в обновлении код запроса исправлен)
или играться с параметрами postgresa отвечающие за план запроса

Поправьте меня если я не прав.
   Фрэнки
 
148 - 17.08.19 - 13:34
как бы есть мысль, что было бы неплохо проверить еще влияние параметра "Количество ИБ на процесс"
У меня такое подозрение складывается, что производительность именно в постгри очень сильно от него зависит.
В этой ветке эту особенность настройки еще не проверяли
   vheathen
 
149 - 17.08.19 - 13:37
(146) до этого были разные сервера 1С. Сейчас подцепил пострес на linux к тому же серверу 1С, через который подключен ms sql - абсолютно такой же результат, как и с линукса, 9.5 секунд.

Сейчас запущу перепроведение итогов на вновь загруженной базе. Посмотрю результат после этого.
   H A D G E H O G s
 
150 - 17.08.19 - 13:38
Щас почитал про Postgree.
В нем нет профайлера в понимании SQL
Ты должен, как последний раб на галерах, собрать лог файл, найти в нем запрос и запустить его через EXPLAIN.
Выкиньте эту херню.
   vheathen
 
151 - 17.08.19 - 13:42
(148) количество информационных баз на процесс по-умолчанию - 8. Соединений - 128. Но я сейчас вообще один на этом сервере 1с.
   Фрэнки
 
152 - 17.08.19 - 13:44
(151) это ты один, а базы крутятся в регламентных заданиях и их там у тебя уже не одна.
Переключи ради интереса. Это же не долго. Даже перезагрузка не потребуется, чтоб увидеть будет ли эффект.
   vheathen
 
153 - 17.08.19 - 13:48
(152) переключить на сколько? одна база - один процесс?

База сейчас на сервере одна, по сути, одна. Вернее, в постгресе одна, на сервере больше.
   vheathen
 
154 - 17.08.19 - 13:56
Меня сильно смущает то, что такая производительность при работе с базой, которая находится на диске в памяти. В новой базе в указанном справочнике 270 тысяч строк. Посмотрим, сколько останется после пересчёта итогов.
   vheathen
 
155 - 17.08.19 - 13:58
(147) Да, сейчас пересчитаю итоги и попробую разобраться с нулевыми значениями. Но неужели настолько неэффективнее postgres получается? Ведь на той же самой базе, прямо один в один, скорость в ms sql выше в десять раз на конкретной операции проведения одного и того же документа. При этом в ms sql база на хранилище, а не в памяти.
   Фрэнки
 
156 - 17.08.19 - 14:00
(153) тебя принципиально ломает установить хотя бы для тестирования 1 база на процесс?
   Фрэнки
 
157 - 17.08.19 - 14:04
(155) сам постгресс эффективен в той же степени, как и сиквел.

// Я знаю, что 1С:Fresh использует postgres, что Кнопка использует postgres, давно и успешно.
Это же твои слова :-)

В данном конкретном случае у тебя в базу вкачали переносами или чем-то подобным всякую бяку. Ну и запросы вероятно попадаются кривоватые, т.к. 1С-конфигурация в базе программистами изменена.
   Фрэнки
 
158 - 17.08.19 - 14:09
Кстати, если сейчас сработает эффект от Количества ИБ на процесс, то этот баг будет уже не в СУБД (у нас же в этом примере сейчас всего одна ИБ в наличии), а в платформе по сути.
   vheathen
 
159 - 17.08.19 - 14:13
(156) не-не, я поставил. Я уже хватаюсь за любые предположения. Только это не изменило ничего.

(157) Так одинаковые данные в ms sql и в постгрес.

Занимательная статистика: до пересчёта в таблице была 227451 строка, стало 65785 строк. Сейчас закончится вакуум и реиндексация после пересчёта (для чистоты эксперимента) - запущу ещё раз оценку производительности.
   vheathen
 
160 - 17.08.19 - 14:40
Перепроведение итогов уменьшило время проведения документа до 4.38 секунды, вдвое.

Сейчас буду разбираться с нулевыми значениями.
   edwin
 
161 - 17.08.19 - 14:45
Автор, попробуй еще это:

plantuner
plantuner.fix_empty_table = 'on'
Исправляет чрезмерную пессимистичность оптимизатора посгтреса на пустых, недавно созданных таблицах.

online_analyze
online_analyze.table_type = 'temporary'
Автоматически анализировать временные таблицы при их изменении. Фоновый analyze может заметно отставать, и, как результат, планер ошибается.
online_analyze.verbose = 'off'
Отключение излишней болтливости автоматического analyze.
   edwin
 
162 - 17.08.19 - 14:46
   vheathen
 
163 - 17.08.19 - 14:47
(161) это всё сделано, разве что стоит online_analyze.table_type = 'all', а не только на временные.
   vheathen
 
164 - 17.08.19 - 15:03
(161) любопытно. переключение онлайн-анализатора _только_ на временные таблицы уменьшило время проведения документа до 1 - 1.4 секунд (несколько раз проверил, даже не завершая сессию менял значение и перезапускал постргес). Причём вариант анализировать все таблицы я не сам придумал, а где-то вычитал, типа, у Гилёва, если мне память не изменяет.

Вот как бы теперь сделать, чтобы время было 1 секунда, а не 1.4 - и будет практически ms sql. Правда, неизвестно, что там будет со скоростью, если и на нём итоги пересчитать. И неизвестно, как через какое-то время после пересчёта итогов будет развиваться ситуация.
   edwin
 
165 - 17.08.19 - 15:32
(164) Скинь конфиг я посмотрю.
   Фрэнки
 
166 - 17.08.19 - 15:35
(164) вообще это спорный рецепт к использованию онлайн-анализа на абсолютно все таблицы, как минимум
Например :

- делаем один запрос (а ведь до него были уже изменения в данных - стартует анализ - а ведь это ест время и подвешивает старт основного запроса)

- по итогам обработки результатов запроса вносим измененные данные

- делаем еще один запрос и снова данные для запроса были изменены, но теперь уже непосредственно перед его запуском.

В стратегии работы с СУБД получается, что в online_analyze.table_type = 'all' может натолкнуться на спорное прикладное решение, которое использует итерации или циклы или рекурсивные обращения данным с их перезаписью.

Было бы забавно выяснить, откуда ноги растут у этого тестового примера, кто писал процедуру проведения документа.
 
 Рекламное место пустует
   rphosts
 
167 - 17.08.19 - 15:40
(165) в (18) есть ьтло что он называет конфигом... я хз, там за 600 строк и многие параметры встречаются многократно с разными значениями, например max_connections=50 и max_connections=100
   edwin
 
168 - 17.08.19 - 15:41
(167) но с тех пор многое поменялось
   ansh15
 
169 - 17.08.19 - 19:28
(164) Отключи online-analyze совсем, заодно и fsync и full_page_writes. Посмотри, что изменится. Возгласы о том, что "целостность базы данных в опасности!" к твоему(тестовому) случаю не имеют отношения. Ничего там не сломается.
Также(об этом уже здесь писали) обновиться до всего самого последнего, может, оптимизировали  или сам запрос или его трансляцию. Вчера еще одно обновление вышло PostgreSQl, версия 10.8-18.1С, там все свои патчи правят.
   Провинциальный 1сник
 
170 - 18.08.19 - 08:04
В очередной раз убеждаюсь, что выбор постгреса как субд для 1с был неудачным, ввиду плохой детерминированности поведения при разборе сложных запросов с подзапросами и временными таблицами, которые так характерны для 1с. Лучше бы они поддержку ib/fb сделали.
   ДенисЧ
 
171 - 18.08.19 - 08:17
(170) А что, иб/фб лучше?
   Фрэнки
 
172 - 18.08.19 - 08:35
(170)// Лучше бы они поддержку ib/fb сделали.


Чтоб нырнули с головой?

Ты хоть на концептуальные отличия в этих СУБД обращал внимание?
Подсказываю: почему ни одна из известных СУБД не может охватить весь рынок целиком?

з.ы. Я вижу, что постепенно подходят к полному обособлению или поднятию уровня собственного решения до полноценной СУБД в виде сейчас пока еще "файловой версии".
   Фрэнки
 
173 - 18.08.19 - 08:43
(170) зацени вот эту хрень

Один нумератр для документов и справочников

Что с этим будет делать СУБД, с какой скорость обрабатывать?
   rphosts
 
174 - 18.08.19 - 09:36
(169) ээээ, как обновить трансляцию если у постгри кэш запроса существует только иногда и только в пределах одного сеанса, разве не так? Если так - каждый раз план запроса пилится заново.
   ansh15
 
175 - 18.08.19 - 10:16
(174) Да, так. Но в плане оптимизации трансляции кое-что делается - https://dl03.1c.ru/content/Platform/8_3_15_1565/1cv8upd_8_3_15_1565.htm#83bf2cb5-14ce-11e9-a3f7-0050569f678a
Так и пишут(например):
"Оптимизировано исполнение запроса, содержащего константные значения в списке выборки. Константные значения, находящиеся в теле запроса, реализуются параметрами запроса. Это приводит к уменьшению количества перекомпиляций планов в СУБД, и как следствие, увеличению производительности таких же запросов, если они отличались только значением константы."
Или "Оптимизировано использование регистра бухгалтерии при работе с использованием СУБД PostgreSQL"
Хотя, для теста(Гилева) в режиме совместимости пока все наоборот, "оптимизация" приводит к видимому уменьшению результата, процентов на 15. Может в самом тесте уже что-то надо подправить, а то он с момента выхода 8.3 и не менялся совсем. Так сказать, реалий времени уже не учитывает.
А использования в 1С кэша запросов PostgreSQL, конечно, не хватает.
   ansh15
 
176 - 18.08.19 - 10:18
(175) В режиме осутствия совместимости с более ранними версиями.
   vheathen
 
177 - 18.08.19 - 10:39
(167) это конфиг после экспериментов. так как меня в конце концов задолбало править в тексте, я их вынес в конец. Используются, естественно, только последние значения.

(165) спасибо, сейчас приведу к более читаемому виду и выложу.
   vheathen
 
178 - 18.08.19 - 11:20
(165) Полный конфиг: https://pastebin.com/YaZ6msEd
Только раскоментированные\изменённые значения: https://pastebin.com/Y4DUcBZ5

(169) Базу я размещал и на диске в памяти, и на хранилище, разницы в скорости нет ни малейшей. Т.е. это явно не ввод\вывод оказывает влияние. А софт я уже обновил: 1c 8.3.15.1565 и PG PRO 1C 11.5
  1  2

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.