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
Ответы
3. Арман Б. (Dream_kz) 26 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) 212 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) 212 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) 212 14.11.17 17:40 Сейчас в теме
(6) Не, если из расчета половину на постгри, тогда нормально.
10. Сан Саныч (herfis) 212 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) 212 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 не повлияло никак
Прикрепленные файлы:
14. Иван Пахмутов (pahmutov) 17.11.17 11:28 Сейчас в теме
Сегодня столкнулся с проблемой. Другая самописная конфигурация с RLS-ами стала дичайше тормозить, по 8 минут на открытие списка документов. Под пользователем с полными правами (без RLS) - мгновенно. Оказалось, дело в параметре join_collapse_limit=1. Отключил - все почти мгновенно.
Оставьте свое сообщение