Антонов Игорь | Руководитель отдела разработки | АО "ДальЖАСО"

«Борьба за интерфейс: HTTP-сервисы + node.js + React.js. Как разработать современный интерфейс»

1С:Предприятие - основная платформа в нашей компании. Мы успешно разработали несколько конфигураций и столкнулись с проблемой: партнерам не нравится 1С-интерфейс из коробки. Решения, адаптированные на работу через веб-клиент тормозят и не могут конкурировать с современными веб-приложениями. Остро проблема проявляется у мобильных пользователей. Стандартным веб-клиентом невозможно пользоваться с мобильного устройства. Стоковые решения в виде мобильного клиента или мобильной платформы от 1С создают дополнительные сложности в дистрибуции приложений. Выход из замкнутого круга мы нашли в современных веб-технологиях и HTTP-сервисах платформы 1С:Предприятие. * Кратко. Что такое и зачем нужны HTTP-сервисы; * Производительность и модель лицензирования; * Особенности разработки API; * HTTP-сервисы vs Веб-сервисов; * Фронтенд. Как не потеряться в технологиях; * React. Как мы выбирали фреймворк для разработки пользовательского интерфейса; * Почему не подошел Angular; * Как заставить технологии работать вместе; * Наши кейсы и проблемы; * Оптимизация HTTP-сервисов; * Что изменилось после двух лет разработки.

Postgre медленная запись в базу

1. pahmutov 14.11.17 13:58 Сейчас в теме
Конфигурация:
УПП 1.3.95.1 (с непринципиальными изменениями относительно типовой), платформа 8.3.9.2233, Postgre 9.6.1-4.1C для Windows, диски SSD, 24gb оперативной памяти, размер базы 36Gb.

В двух словах ситуация:
Расчет себестоимости выполняется 50 минут (плюс-минус 5 мин), та же база в файловом варианте на SSD, тот же расчет себестоимости - меньше 4 мин.
Аналогично проведение других документов, например, Поступление доп.расходов, postgre – 15 сек, файловая – 4 сек. Причина у Постгре везде в очень медленной записи данных в базу (различные таблицы) даже при наличии только 1 пользователя в базе.

Сравнительный анализ производительности по строчкам кода при проведении документа поступления доп.расходов прилагаю.

Текущий конфиг postgresql.conf так же прилагаю.

Только не говорите, что для УПП (поскольку не управляемые блокировки) в принципе нельзя добиться адекватной производительности записи на Постгре.
Прикрепленные файлы:
postgre vs файловая.xlsx
postgresql.conf
Вознаграждение за ответ
Показать полностью
Найденные решения
22. Dream_kz 75 10.12.17 21:58 Сейчас в теме +2 $m
(21) А режим совместимости платформы в конфигурации какой стоит? 1С-ники оптимизировали запись в postgre в режиме совместимости 8.3.7 и выше.

(21)
Понять бы, чего он ждет.

Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда: http://wiki.etersoft.ru/PostgreSQL/Optimum

(21)
линуксовым постгре подружить УПП.

На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
user658743_shevado; pahmutov; +2 Ответить
Остальные ответы
Сортировка: Древо
3. Dream_kz 75 14.11.17 14:08 Сейчас в теме
(1) Попробуйте отрубить fsync
7. pahmutov 14.11.17 15:33 Сейчас в теме
(3) пробовали, разницы нет
2. DenisCh 14.11.17 14:04 Сейчас в теме
Ради эксперимента пробовал поднять MSSQL?
8. pahmutov 14.11.17 15:34 Сейчас в теме
(2) (4) сегодня в ночь поставлю, завтра отпишусь, спасибо
12. pahmutov 16.11.17 20:06 Сейчас в теме
(2) поставил, по расчету с/с 17 мин с первого прохода, 7 минут со второго (это вполне приемлемый результат). По построчному анализу небольшого документа файл ниже в каментах.
4. herfis 256 14.11.17 14:09 Сейчас в теме
Файловая будет заведомо быстрее писать. Насколько - второй вопрос. Ускорить запись в постгри скорее всего можно путем оптимизации ее настроек. Но нужно понимать рамки. Идеально - в самом деле поднять рядом MSSQL и сравнить скорость записи. Если в MSSQL будет заметно лучше, то скорее всего и постгрес можно подкрутить примерно до того же уровня. Тогда уже можно вплотную заняться его настройкой.
ЗЫ. Почему в качестве теста MSSQL? Потому что у него неплохая автоконфигурация из коробки. А postgesql настраивается полностью вручную и получить неоптимальную производительность из-за неправильных настроек проще простого.
11. pahmutov 16.11.17 20:03 Сейчас в теме
(4) Извиняюсь, что не сразу отписался, в первую ночь не успел поднять MS SQL.
В итоге, MS SQL 2008 R2 с первого прохода расчета себестоимости дал 17 минут, со второго 7 минут.
По документу поступление доп.расходов прилагаю файл сравнения postgre и ms sql.

Короче говоря, как я и ожидал, MS SQL дает приличный результат. А вот в чем затык у постгре при записи - непонятно.
Прикрепленные файлы:
postgre vs mssql.xlsx
5. herfis 256 14.11.17 14:29 Сейчас в теме
Как минимум расскоменть temp_buffers и поставь его 128Мб, скажем
И вообще какие-то жлобские настройки для 24 Гиг ОЗУ. Или тут еще и сервер 1С?
Все равно можно бы побольше дать.
6. pahmutov 14.11.17 15:33 Сейчас в теме
(5) Там еще и сервер 1с. Вообще, постгре памяти вообще не ест (прямо сейчас суммарно не больше 250 Мб где-то), как его не пробовали заставлять это делать.
temp_buffers попробую сегодня в ночь
Жлобские настройки в плане work_mem = 750MB ?
Спасибо за наводки.
9. herfis 256 14.11.17 17:40 Сейчас в теме
(6) Не, если из расчета половину на постгри, тогда нормально.
10. herfis 256 16.11.17 16:08 Сейчас в теме
Есть какие результаты? Интересно же...
13. pahmutov 16.11.17 20:07 Сейчас в теме
15. pahmutov 21.11.17 19:22 Сейчас в теме
(10) Будут какие-нибудь идеи на тему настройки постгре? Учитывая, что MS SQL шустр на этой базе на том же сервере.
У меня у самого осталась только одна идея: поставить самый последний постгре и самую последнюю платформу 1с, уповая, что 1с-ники что-то там намутили в плане построения запросов к постгре.
16. herfis 256 22.11.17 18:36 Сейчас в теме
(15) Это имеет смысл. И 1С и сама постгря сейчас активно пилятся в сторону "более лучшей" дружбы. Только бери с postgrespro.ru
Проблема в том, что версия для винды пилится по остаточному принципу, так что там могут быть свои косяки.
Но оптимизатор запросов MSSQL все равно лучше (реже косячит) и еще MSSQL хорошо параллелит запросы, а постгря только начала делать шаги в этом направлении.
По твоей ситуации.
Расчет себестоимости - это все-таки интегральный тест, сравнивать им можно, а принимать решения - нет.
Может, там на одном конкретном запросе затуп и конфигурация постгри вообще не причем.
Сравнивай на чем-нить попроще для начала, типа теста Гилева (на запись) и простеньких запросах (но больших объемах). Тогда можно и план запроса посмотреть и проверить влияние конкретных настроек.
ЗЫ. temp_buffers никак не повлияли?
17. pahmutov 22.11.17 22:55 Сейчас в теме
(16) Ну проведение небольшого документа, например "Поступление доп.расходов" так же проигрывает весьма ощутимо в сравнении с MS SQL. Касательно проведения себестоимости, то прилагаю скриншот замера производительности, из него видно, что тупят различные записи в базу.
Если поставить postgre линуксовую то есть шанс, что она не станет тупить при записи? по сравнению с виндовой версией.
temp_buffers не повлияло никак
Прикрепленные файлы:
18. Dream_kz 75 08.12.17 07:23 Сейчас в теме
(17) Проблема еще актуальна? Столкнулся с похожей, Авансовый отчет из 2-х строк в базу записывался около 15 сек, выкрутил
commit_delay = 0
default_statistics_target = 100
вроде стало быстрее
19. pahmutov 08.12.17 12:58 Сейчас в теме
(18) Да, к сожалению, актуально. Поставил последний постгрепро и платформу последнюю из 10х - результата нет. Полагаю, результат был бы, если бы конфигурация была ERP или что-то из новых, на управляемых блокировках. А у меня УПП 1.3, малореально ожидать, что 1с будет оптимизировать план построения запросов для этой конфигурации при условии, что весной она снимается с развития.
Встретил информацию, что проблема с расчетом себестоимости решается вот как: Использовать PostgreSQL 9.1.2.-1.1C в котором реализован независимый от Autovacuum сбор статистики.
Постгрес старый, но в выхи попробую.

commit_delay = 0
default_statistics_target = 100
тоже попробую, спасибо.
20. Dream_kz 75 08.12.17 13:48 Сейчас в теме
(19)
Использовать PostgreSQL 9.1.2.-1.1C в котором реализован независимый от Autovacuum сбор статистики

Это с этой версии он реализован, если не ошибаюсь, то это online_analyze, и он у вас включен.
Можно включить сбор статистики по всем таблицам, не только временным:
online_analyze.table_type = 'all'

Расчет себестоимости действительно тяжелая операция, если там используются соединения со срезом последних и подзапросы то в Postgre будет долго работать, это особенность планировщика. А если сравнивать с реализацией ТМЗ строк в 10-50?

Еще как вариант поменять параметры
wal_sync_method = open_datasync
full_page_writes = off

И вынести лог транзакций на другой диск

Рекомендации отсюда: https://its.1c.ru/db/metod8dev#content:4650:hdoc
21. pahmutov 10.12.17 20:31 Сейчас в теме
(20) Я вообще тестирую на документе Перемещение товаров в 50 строк. MSSQL дает 9 сек, постгре минимум 30. Крутил всяко разно, собственно попробовал все вышеприведенное и немного еще другого. Из результатов - было немного хуже, до 35-38 секунд, но меньше 30 не было.
Прогнал и расчет себестоимости на одном из вариантов - 54 минуты.
Единственное, что не делал - не выносил лог транзакций на отдельный диск. Но прикол в том, что нагрузки на диск не наблюдается в момент затупа посгтре (скриншот нагрузки на диск на сервере прилагаю).
Текущий конфиг тоже прилагаю.

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

Похоже, буду поднимать сервер на линухе и пробовать с линуксовым постгре подружить УПП.
Прикрепленные файлы:
postgresql.conf
22. Dream_kz 75 10.12.17 21:58 Сейчас в теме +2 $m
(21) А режим совместимости платформы в конфигурации какой стоит? 1С-ники оптимизировали запись в postgre в режиме совместимости 8.3.7 и выше.

(21)
Понять бы, чего он ждет.

Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда: http://wiki.etersoft.ru/PostgreSQL/Optimum

(21)
линуксовым постгре подружить УПП.

На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
user658743_shevado; pahmutov; +2 Ответить
23. pahmutov 11.12.17 09:54 Сейчас в теме
(22) О. А вот про режим совместимости не знал. Стоит самый древний 8.2. Сегодня в ночь попробую поставить в "не использовать".
p.s. cpu_tuple_cost не помогло
24. Dream_kz 75 11.12.17 10:43 Сейчас в теме
(23)
Сегодня в ночь попробую поставить в "не использовать".

на копии надеюсь? что-нибудь может поломаться, я б в 8.3.8 сначала выкрутил
25. pahmutov 12.12.17 13:13 Сейчас в теме
(24) ДА. Спасибище за наводку. Поставил режим совместимости 8.3.8 на копии. Помогло. Перемещение товаров по времени упало с 30 сек до 12 (MS SQL дает 8 сек, но меня устроит и 12). Расчет себестоимости с 54 минут до 22 минут (MS SQL дает от 7 до 18 минут).
Правда, нельзя так просто взять и поставить режим совместимости повыше. Конфига начинает ругаться на дубли имен картинок и функций в глобальных и общих модулях (которые стали функциями платформы в более поздних версиях), ну и достаточно долго реструктуризирует базу.
26. Dream_kz 75 12.12.17 13:32 Сейчас в теме
(25) Ну долго думаю из-за объема, и новой структуры, а вот с кодом надо будет повозиться. Если честно, сам не ожидал такого роста производительности
14. pahmutov 17.11.17 11:28 Сейчас в теме
Сегодня столкнулся с проблемой. Другая самописная конфигурация с RLS-ами стала дичайше тормозить, по 8 минут на открытие списка документов. Под пользователем с полными правами (без RLS) - мгновенно. Оказалось, дело в параметре join_collapse_limit=1. Отключил - все почти мгновенно.
27. ansh15 13.12.17 03:43 Сейчас в теме
Почитал описание релиза "1C:Управление производственным предприятием, редакция 1.3. Релиз 1.3.97.5 от 05.12.17"
Пишут, что
Текущий релиз конфигурации «Управление производственным
предприятием» предназначен для использования с версией системы
1С:Предприятие 8 не ниже 8.2.19.130, а также может использоваться
с версией 8.3.3.687(и выше)в режиме совместимости «Версия 8.2.13».

Насколько допустимо не соблюдать режим совместимости(особенно для старых) конфигураций?
Не будет ли потом, со временем, тяжелых последствий для данных?
28. pahmutov 21.12.17 12:39 Сейчас в теме
(27) Работаем полторы недели на новом режиме. Навскидку при изменении вылезла необходимость 1) изменить имена штук 10 общих картинок 2) изменить имена (ну или удалить) двух функций в трех общих модулях 3) изменить код блокировки справочника во внешней обработке (но это к типовой конфиге не относится). В остальном полет нормальный.
Я полагаю, что режим совместимости на целостность данных не должен влиять, а проблемы появляются только в именах функций и объектов, которые в новой версии недопустимы.
Зато зацените разность в скорости записи данных в базу в прилагаемом скриншоте (сверху режим 8.2, снизу 8.3.8) (это проведение документа Поступление доп.расходов с 56 строками в ТЧ).
Прикрепленные файлы:
29. nvv1970 07.01.18 02:58 Сейчас в теме
synchronous_commit = off - это правильно.
#wal_sync_method = fsync
в комплекте с сервером идет утилита тестирования методов. Быстрее всего у меня работал под виндой метод open_datasync. На сколько быстрее - не вспомню. Под линуксом все методы работают очень быстро.
fsync = on - документирована возможность отключения параметра. Если вы не в теме что это - то не выключайте ни в коем случае!! НО на тестовом сервере можно попробовать отключить и оценить влияние.

Было бы неплохо протестировать чистую запись данных через COPY, запись через INSERT, оценить влияние записи в WAL.
Из опыта: отключение NestLoop увеличивало время записи хозрасчетного до 10 сек на наборы хозрасчетного с 1-2 строками. Менять/отключать методы соединений не рекомендую.

join_collapse_limit=1 - не читайте такие советы. Есть прекрасно работающий дефолт = 8. Положите базу.

С учетом тестов выше стоило бы уделить внимание методикам записи в системе, т.к. PG не умеет напрямую писать на диски, а только через ОС.

1С-ники оптимизировали запись в postgre в режиме совместимости 8.3.7 и выше.
Откуда инфа???? Дайте ссылку. Такие вещи если меняются в платформе, то вне зависимости от совместимости. Если это действительно так, то очень странно.

PS: описание читали?
Поддержка этой версии (9.6.1) в 1С:Предприятии 8.3 реализована в версии 8.3.10 и старше.
Нагрузочное тестирование проводилось на версиях 1С:Предприятия 8.3.10.
Для использования PostgreSQL 9.6.1-4.1C с версиями 1С:Предприятия ниже 8.3.10 необходимо его собрать с установленным значением параметра integer_datetimes=off
30. user658743_shevado 2 16.07.18 16:30 Сейчас в теме
Вставлю свои 5 копеек. Та же проблема. Медленная запись в регистр бухгалтерии при расчете себестоимости. В тестовой базе изменил версию режима совместимости на 8.3.7. Скорость возросла в несколько раз.
Сейчас думаю оценить риски нарваться на не работающий код и применять изменения для рабочей базы
Оставьте свое сообщение
Все разделы

Вакансии


Удаленный ИТ-журналист
Санкт-Петербург
По совместительству

Программист 1С
Санкт-Петербург
зарплата от 80 000 руб. до 150 000 руб.
Полный день

Программист 1С
Москва
зарплата от 120 000 руб. до 160 000 руб.
Полный день

Консультант-аналитик 1С
Москва
зарплата до 160 000 руб.
Полный день