Сравнение производительность ЗУП2.5 postgres и mssql #340046

Скачал postgresql-8.2.6-2.1C с сайта 1с, установил, загрузил в него базу. Попробовал наиболее "тяжелые" отчеты, которые в mssql 2000 дико тормозили. В постгресе они стали просто летать. Однако. Когда-то разбирался с причинами торможения mssql, трассировал, смотрел планы выполнения. Пришел к выводу что mssql часто не может построить оптимальный план выполнения для генерируемых 1с запросов - получаются сплошные nested loops. Похоже, оптимизатор в постгресе получше микрософтовского в sql2000.. Правда, sql2005 не пробовал.

С MS SQL не сравнивали, но Postgres на чтение реально гуд. Вот только на запись, похоже, тупит. Еще по этому параметру интересно было бы посмотреть.

Кстати, как я заметил, если в postgresql.conf задать enable_nestloop = off, то скорость работы pgsql еще сильнее возрастает. Очевидно, запросы формируемые 1с провоцируют использование nested loops, в postgre в меньшей степени, в mssql - в большей. Интересно, в mssql можно вот так отключить использование nested loops?

Ручные блокировки не помогают?

а чо ж должен сервер возвращать, если нестед лупс ему запретить, а по другому запрос он исполнить не сможет? :) Зы. 1С под сиквелем намного быстрее чем под чем-либо еще. Естественно, под 2005 сиквелем. Не очень же умно в самом деле юзать программу семилетней давности и жаловаться на то, что она тормозит. Хотя, у постгреса огромный потенциал, ибо версионник. Вот только осилят ли нуралиевцы его?

Попробовал все planner metod поставить в OFF - сервер работает, запросы выполняет, только оооочень медленно. Очевидно, у сервера есть какой-то "базовый" метод выполнения запросов, возможно жутко неоптимальный. А все остальные - опционально, для ускорения. Только вот nested loop в применении к 1с чаще замедляет, чем ускоряет. Короче, я убедился - самые лучшие результаты postgre + v8 выдает, когда все методы планировщика включены (по умолчанию), кроме enable_nestloop. "Не очень же умно в самом деле юзать программу семилетней давности и жаловаться на то, что она тормозит" - а что делать? Если параллельно ведется учет в v7.7, то тут переход на sql2005 с патченьем бинарников тоже не совсем прямое решение.

Полный расчет документа начисления зарплаты 950 человек на постгре с отключенными nested loops выполнился за 45 секунд, причем заполнение табличных частей заняло всего 9 секунд. На mssql только заполнение табличных частей заняло 3.5 минуты, а рассчитывался он 4 минуты. На одном и том же сервере. Отличие практически на порядок. По-моему, разработчикам платформы 1с следовало бы учесть этот факт, и посылать запросы на mssql с соответствующими параметрами оптимизации (хотя бы тупо отключая nested loops). А может они это в запасе держат? Как тот чукча из анекдота который бревно с собой нес, чтобы когда медведя встретит - бревно бы бросил и быстро-быстро побежал :) Вот наступят для 1с черные дни, а они раз - и быстродействие на порядок поднимут.. :)

Думаю, это не совсем корректный показатель. Многое зависит еще и от того, насколько сложным является расчет на конкретном предприятии. Вполне может оказаться, что простой тупой пересчет на postgres может оказаться быстрее. Однако, хотелось бы знать как обстоят дела с различными настройками и сложными документами расчета. И еще. Не совсем понятно на какой операционной системе установлен postgres.

угу..представляю как сотня юзеров сидит на постгре.. простите моё незнание,а 2005 мс скл разве не версионник?

А что, сотня юзеров не может сидеть на постгре?

тут уже мелькал чувак с 50 юзеров на УПП в постгре

сидят, но туго. Ждем стабильной ветки-потомков 15-го (управляемые блокировки)

, из за плохо управляемых блокировок(на уровне постгре) большое количество юзеров , одлновременно работающих в постгре, очень мало. во всяком случае точно менее чем максимально может потянуть мс скл . Но эт фигня. У меня только один раз был случай использования постгре. И мне очень бы хотелось посмотреть как работает там оптимизатор. Потому что есть сомнения что его там вообще нет как такового. Работу того жэ кеша запросов я так и не увидел. В общем много всего

База ЗУП относительно небольшая - около 1000 сотрудников, порядка полусотни подразделений. Начата в 2008 году. Количество пользователей - не больше десятка. Сервер - win2003Standart(2 ксеона 2.2ГГц, 4Гб озу), на нем установлены sql2000 Standart и postgresql-8.2.6-2.1C. На таких исходных данных у меня самым быстрым решением оказался postgre с отключенным nested loop.

Ты не понял. Под "сложностью" я понимаю сложность учета в самой ЗУП. Уровень детализации аналитики. Сколько, например, у вас записей в документе "Отражение зарплаты в регл.учете"?

В документе "Отражение зарплаты в регл.учете" около 5 тысяч записей (проводок).

У нас более 35 тысяч записей. Интересно, как долго будет все это расчитываться на postgres. Да еще сравнить postgres под Linux и под Windows 2003

А сколько записей в этом документе?

Надо будет попробовать, у меня практически то же самое.

В контексте вопрос: во время тестов оба sql-сервера ничем загружены не были? По одной базе в каждом и тесты неодновременные?

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

В табличной части Начисления около тысячи строк - как правило у сотра по одному плановому начислению(оклад/тариф/сделка), редко у кого есть надбавки. Порядка 1000 строк НДФЛ. Около 300 строчек плановых удержаний(профком, алименты и т.п.). "во время тестов оба sql-сервера ничем загружены не были? По одной базе в каждом и тесты неодновременные?" Физически это один сервер. Тесты проводились в часы отсутствия нагрузки, разумеется на ms и pg не одновременно. Причем повторял несколько раз - результаты совпадают.

Ты в писал, что 950 человек у тебя считалось... Если все было в одном документе, то должно быть минимум 5000 строк в начислениях.

"950 человек у тебя считалось... Если все было в одном документе, то должно быть минимум 5000 строк в начислениях" Это почему еще?

Простая арифметика (Оклад,Премия,РК,СН, доплата за питание и пр.)*950 = более 5 тысяч и это только обыкновенные окладники... Уже не говоря про рабочих, где есть куча переработок, доплат за совмещение,вредность и пр., вахта и т.д.

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

А постгри новую где можно скачать?

Я качал на users.v8.1c.ru

Нет 2005 сиквель не версионник. Хотя, некоторые возможности версионника в нем появились.

8.2.5 качал? Сейчас зашел, что-то нету...