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) 27 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)
линуксовым постгре подружить УПП.

На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
pahmutov; +1 Ответить
Остальные ответы
3. Арман Б. (Dream_kz) 27 14.11.17 14:08 Сейчас в теме
(1) Попробуйте отрубить fsync
7. Иван Пахмутов (pahmutov) 14.11.17 15:33 Сейчас в теме
(3) пробовали, разницы нет
2. DenisCh Гейтс (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) 245 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) 245 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) 245 14.11.17 17:40 Сейчас в теме
(6) Не, если из расчета половину на постгри, тогда нормально.
10. Сан Саныч (herfis) 245 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) 245 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) 27 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) 27 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) 27 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)
линуксовым постгре подружить УПП.

На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
pahmutov; +1 Ответить
23. Иван Пахмутов (pahmutov) 11.12.17 09:54 Сейчас в теме
(22) О. А вот про режим совместимости не знал. Стоит самый древний 8.2. Сегодня в ночь попробую поставить в "не использовать".
p.s. cpu_tuple_cost не помогло
24. Арман Б. (Dream_kz) 27 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) 27 12.12.17 13:32 Сейчас в теме
(25) Ну долго думаю из-за объема, и новой структуры, а вот с кодом надо будет повозиться. Если честно, сам не ожидал такого роста производительности
14. Иван Пахмутов (pahmutov) 17.11.17 11:28 Сейчас в теме
Сегодня столкнулся с проблемой. Другая самописная конфигурация с RLS-ами стала дичайше тормозить, по 8 минут на открытие списка документов. Под пользователем с полными правами (без RLS) - мгновенно. Оказалось, дело в параметре join_collapse_limit=1. Отключил - все почти мгновенно.
27. Андрей Sh. (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. Uladzimir - (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
Оставьте свое сообщение