Конфигурация:
УПП 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 так же прилагаю.
Только не говорите, что для УПП (поскольку не управляемые блокировки) в принципе нельзя добиться адекватной производительности записи на Постгре.
УПП 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
По теме из базы знаний
Найденные решения
(21) А режим совместимости платформы в конфигурации какой стоит? 1С-ники оптимизировали запись в postgre в режиме совместимости 8.3.7 и выше.
(21)
Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда:
(21)
На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
(21)
Понять бы, чего он ждет.
Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда:
(21)
линуксовым постгре подружить УПП.
На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Файловая будет заведомо быстрее писать. Насколько - второй вопрос. Ускорить запись в постгри скорее всего можно путем оптимизации ее настроек. Но нужно понимать рамки. Идеально - в самом деле поднять рядом MSSQL и сравнить скорость записи. Если в MSSQL будет заметно лучше, то скорее всего и постгрес можно подкрутить примерно до того же уровня. Тогда уже можно вплотную заняться его настройкой.
ЗЫ. Почему в качестве теста MSSQL? Потому что у него неплохая автоконфигурация из коробки. А postgesql настраивается полностью вручную и получить неоптимальную производительность из-за неправильных настроек проще простого.
ЗЫ. Почему в качестве теста MSSQL? Потому что у него неплохая автоконфигурация из коробки. А postgesql настраивается полностью вручную и получить неоптимальную производительность из-за неправильных настроек проще простого.
(4) Извиняюсь, что не сразу отписался, в первую ночь не успел поднять MS SQL.
В итоге, MS SQL 2008 R2 с первого прохода расчета себестоимости дал 17 минут, со второго 7 минут.
По документу поступление доп.расходов прилагаю файл сравнения postgre и ms sql.
Короче говоря, как я и ожидал, MS SQL дает приличный результат. А вот в чем затык у постгре при записи - непонятно.
В итоге, MS SQL 2008 R2 с первого прохода расчета себестоимости дал 17 минут, со второго 7 минут.
По документу поступление доп.расходов прилагаю файл сравнения postgre и ms sql.
Короче говоря, как я и ожидал, MS SQL дает приличный результат. А вот в чем затык у постгре при записи - непонятно.
Прикрепленные файлы:
postgre vs mssql.xlsx
Как минимум расскоменть temp_buffers и поставь его 128Мб, скажем
И вообще какие-то жлобские настройки для 24 Гиг ОЗУ. Или тут еще и сервер 1С?
Все равно можно бы побольше дать.
И вообще какие-то жлобские настройки для 24 Гиг ОЗУ. Или тут еще и сервер 1С?
Все равно можно бы побольше дать.
(5) Там еще и сервер 1с. Вообще, постгре памяти вообще не ест (прямо сейчас суммарно не больше 250 Мб где-то), как его не пробовали заставлять это делать.
temp_buffers попробую сегодня в ночь
Жлобские настройки в плане work_mem = 750MB ?
Спасибо за наводки.
temp_buffers попробую сегодня в ночь
Жлобские настройки в плане work_mem = 750MB ?
Спасибо за наводки.
(10) Будут какие-нибудь идеи на тему настройки постгре? Учитывая, что MS SQL шустр на этой базе на том же сервере.
У меня у самого осталась только одна идея: поставить самый последний постгре и самую последнюю платформу 1с, уповая, что 1с-ники что-то там намутили в плане построения запросов к постгре.
У меня у самого осталась только одна идея: поставить самый последний постгре и самую последнюю платформу 1с, уповая, что 1с-ники что-то там намутили в плане построения запросов к постгре.
(15) Это имеет смысл. И 1С и сама постгря сейчас активно пилятся в сторону "более лучшей" дружбы. Только бери с postgrespro.ru
Проблема в том, что версия для винды пилится по остаточному принципу, так что там могут быть свои косяки.
Но оптимизатор запросов MSSQL все равно лучше (реже косячит) и еще MSSQL хорошо параллелит запросы, а постгря только начала делать шаги в этом направлении.
По твоей ситуации.
Расчет себестоимости - это все-таки интегральный тест, сравнивать им можно, а принимать решения - нет.
Может, там на одном конкретном запросе затуп и конфигурация постгри вообще не причем.
Сравнивай на чем-нить попроще для начала, типа теста Гилева (на запись) и простеньких запросах (но больших объемах). Тогда можно и план запроса посмотреть и проверить влияние конкретных настроек.
ЗЫ. temp_buffers никак не повлияли?
Проблема в том, что версия для винды пилится по остаточному принципу, так что там могут быть свои косяки.
Но оптимизатор запросов MSSQL все равно лучше (реже косячит) и еще MSSQL хорошо параллелит запросы, а постгря только начала делать шаги в этом направлении.
По твоей ситуации.
Расчет себестоимости - это все-таки интегральный тест, сравнивать им можно, а принимать решения - нет.
Может, там на одном конкретном запросе затуп и конфигурация постгри вообще не причем.
Сравнивай на чем-нить попроще для начала, типа теста Гилева (на запись) и простеньких запросах (но больших объемах). Тогда можно и план запроса посмотреть и проверить влияние конкретных настроек.
ЗЫ. temp_buffers никак не повлияли?
(16) Ну проведение небольшого документа, например "Поступление доп.расходов" так же проигрывает весьма ощутимо в сравнении с MS SQL. Касательно проведения себестоимости, то прилагаю скриншот замера производительности, из него видно, что тупят различные записи в базу.
Если поставить postgre линуксовую то есть шанс, что она не станет тупить при записи? по сравнению с виндовой версией.
temp_buffers не повлияло никак
Если поставить postgre линуксовую то есть шанс, что она не станет тупить при записи? по сравнению с виндовой версией.
temp_buffers не повлияло никак
Прикрепленные файлы:
(18) Да, к сожалению, актуально. Поставил последний постгрепро и платформу последнюю из 10х - результата нет. Полагаю, результат был бы, если бы конфигурация была ERP или что-то из новых, на управляемых блокировках. А у меня УПП 1.3, малореально ожидать, что 1с будет оптимизировать план построения запросов для этой конфигурации при условии, что весной она снимается с развития.
Встретил информацию, что проблема с расчетом себестоимости решается вот как: Использовать PostgreSQL 9.1.2.-1.1C в котором реализован независимый от Autovacuum сбор статистики.
Постгрес старый, но в выхи попробую.
commit_delay = 0
default_statistics_target = 100
тоже попробую, спасибо.
Встретил информацию, что проблема с расчетом себестоимости решается вот как: Использовать PostgreSQL 9.1.2.-1.1C в котором реализован независимый от Autovacuum сбор статистики.
Постгрес старый, но в выхи попробую.
commit_delay = 0
default_statistics_target = 100
тоже попробую, спасибо.
(19)
Это с этой версии он реализован, если не ошибаюсь, то это online_analyze, и он у вас включен.
Можно включить сбор статистики по всем таблицам, не только временным:
online_analyze.table_type = 'all'
Расчет себестоимости действительно тяжелая операция, если там используются соединения со срезом последних и подзапросы то в Postgre будет долго работать, это особенность планировщика. А если сравнивать с реализацией ТМЗ строк в 10-50?
Еще как вариант поменять параметры
wal_sync_method = open_datasync
full_page_writes = off
И вынести лог транзакций на другой диск
Рекомендации отсюда:
Использовать 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
И вынести лог транзакций на другой диск
Рекомендации отсюда:
(20) Я вообще тестирую на документе Перемещение товаров в 50 строк. MSSQL дает 9 сек, постгре минимум 30. Крутил всяко разно, собственно попробовал все вышеприведенное и немного еще другого. Из результатов - было немного хуже, до 35-38 секунд, но меньше 30 не было.
Прогнал и расчет себестоимости на одном из вариантов - 54 минуты.
Единственное, что не делал - не выносил лог транзакций на отдельный диск. Но прикол в том, что нагрузки на диск не наблюдается в момент затупа посгтре (скриншот нагрузки на диск на сервере прилагаю).
Текущий конфиг тоже прилагаю.
У меня какое-то ощущение что при записи и удалении записей в определенных таблицах постгре просто чего-то ждет. Понять бы, чего он ждет.
Похоже, буду поднимать сервер на линухе и пробовать с линуксовым постгре подружить УПП.
Прогнал и расчет себестоимости на одном из вариантов - 54 минуты.
Единственное, что не делал - не выносил лог транзакций на отдельный диск. Но прикол в том, что нагрузки на диск не наблюдается в момент затупа посгтре (скриншот нагрузки на диск на сервере прилагаю).
Текущий конфиг тоже прилагаю.
У меня какое-то ощущение что при записи и удалении записей в определенных таблицах постгре просто чего-то ждет. Понять бы, чего он ждет.
Похоже, буду поднимать сервер на линухе и пробовать с линуксовым постгре подружить УПП.
Прикрепленные файлы:
(21) А режим совместимости платформы в конфигурации какой стоит? 1С-ники оптимизировали запись в postgre в режиме совместимости 8.3.7 и выше.
(21)
Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда:
(21)
На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
(21)
Понять бы, чего он ждет.
Скорее всего планировщик выбирает неоптимальный план, не уверен что поможет, но можно подправить оценки планировщику:
* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;
* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;
Отсюда:
(21)
линуксовым постгре подружить УПП.
На линуксе из-за файловой системы работать будет быстрее, но насколько, сказать сложно
(24) ДА. Спасибище за наводку. Поставил режим совместимости 8.3.8 на копии. Помогло. Перемещение товаров по времени упало с 30 сек до 12 (MS SQL дает 8 сек, но меня устроит и 12). Расчет себестоимости с 54 минут до 22 минут (MS SQL дает от 7 до 18 минут).
Правда, нельзя так просто взять и поставить режим совместимости повыше. Конфига начинает ругаться на дубли имен картинок и функций в глобальных и общих модулях (которые стали функциями платформы в более поздних версиях), ну и достаточно долго реструктуризирует базу.
Правда, нельзя так просто взять и поставить режим совместимости повыше. Конфига начинает ругаться на дубли имен картинок и функций в глобальных и общих модулях (которые стали функциями платформы в более поздних версиях), ну и достаточно долго реструктуризирует базу.
Сегодня столкнулся с проблемой. Другая самописная конфигурация с RLS-ами стала дичайше тормозить, по 8 минут на открытие списка документов. Под пользователем с полными правами (без RLS) - мгновенно. Оказалось, дело в параметре join_collapse_limit=1. Отключил - все почти мгновенно.
Почитал описание релиза "1C:Управление производственным предприятием, редакция 1.3. Релиз 1.3.97.5 от 05.12.17"
Пишут, что
Насколько допустимо не соблюдать режим совместимости(особенно для старых) конфигураций?
Не будет ли потом, со временем, тяжелых последствий для данных?
Пишут, что
Текущий релиз конфигурации «Управление производственным
предприятием» предназначен для использования с версией системы
1С:Предприятие 8 не ниже 8.2.19.130, а также может использоваться
с версией 8.3.3.687(и выше)в режиме совместимости «Версия 8.2.13».
предприятием» предназначен для использования с версией системы
1С:Предприятие 8 не ниже 8.2.19.130, а также может использоваться
с версией 8.3.3.687(и выше)в режиме совместимости «Версия 8.2.13».
Насколько допустимо не соблюдать режим совместимости(особенно для старых) конфигураций?
Не будет ли потом, со временем, тяжелых последствий для данных?
(27) Работаем полторы недели на новом режиме. Навскидку при изменении вылезла необходимость 1) изменить имена штук 10 общих картинок 2) изменить имена (ну или удалить) двух функций в трех общих модулях 3) изменить код блокировки справочника во внешней обработке (но это к типовой конфиге не относится). В остальном полет нормальный.
Я полагаю, что режим совместимости на целостность данных не должен влиять, а проблемы появляются только в именах функций и объектов, которые в новой версии недопустимы.
Зато зацените разность в скорости записи данных в базу в прилагаемом скриншоте (сверху режим 8.2, снизу 8.3.8) (это проведение документа Поступление доп.расходов с 56 строками в ТЧ).
Я полагаю, что режим совместимости на целостность данных не должен влиять, а проблемы появляются только в именах функций и объектов, которые в новой версии недопустимы.
Зато зацените разность в скорости записи данных в базу в прилагаемом скриншоте (сверху режим 8.2, снизу 8.3.8) (это проведение документа Поступление доп.расходов с 56 строками в ТЧ).
Прикрепленные файлы:
synchronous_commit = off - это правильно.
#wal_sync_method = fsync
в комплекте с сервером идет утилита тестирования методов. Быстрее всего у меня работал под виндой метод open_datasync. На сколько быстрее - не вспомню. Под линуксом все методы работают очень быстро.
fsync = on - документирована возможность отключения параметра. Если вы не в теме что это - то не выключайте ни в коем случае!! НО на тестовом сервере можно попробовать отключить и оценить влияние.
Было бы неплохо протестировать чистую запись данных через COPY, запись через INSERT, оценить влияние записи в WAL.
Из опыта: отключение NestLoop увеличивало время записи хозрасчетного до 10 сек на наборы хозрасчетного с 1-2 строками. Менять/отключать методы соединений не рекомендую.
join_collapse_limit=1 - не читайте такие советы. Есть прекрасно работающий дефолт = 8. Положите базу.
С учетом тестов выше стоило бы уделить внимание методикам записи в системе, т.к. PG не умеет напрямую писать на диски, а только через ОС.
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
#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
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот