Еще один тест 1C: Postgres SQL 11 Pro Enterpise против MSSQL 14 под Windows 2012 Server R2

В качестве теста решил использовать:

1. Тест 1 - знаменитый всем тест Гилева
2. Тест 2 - загрузка базы данных из dt файла. база - 1C Бухгалтерия предприятия 3.0 (3.0.72.70).  Критерий оценки время на удаление
3. Тест 3  - Обработка по поиску и удалению данных по одной организации в 1C Бухгалтерия предприятия 3.0 (3.0.72.70) (база данных плюс минус на 15 гигабайт). Критерий оценки время на удаление
4. тест 4. Перепроведение всех Документов базы с начала. 1C Бухгалтерия предприятия 3.0 (3.0.72.70). Критерий оценки Время на проведение
5. тест 5 - тест fragster.ru 

По моим наблюдениям, несомненным плюсом Postgres является тот факт, что Postgres более оптимально использует ресурсы (Память, CPU, накопитель)

Поэтому я умышленно установил лишь 8Gb памяти для того чтобы дать фору Postgres

В Качестве подопытного ПК Будем использовать машину, о которой я писал в статье //infostart.ru/public/992238

Характеристики подопытного ПК: 

1.  Intel Xeon E3 1270 3,4 ГГц LGA1155 8 MB 4 ядра Процессор процессор E3-1270 SR00N (полный серверный аналог i7 2600K без встройки gpu) В разгоне 3,8Ghz 
2.  8G RAM 1333Mhz,
3.  SSD samsung 860 pro 250gb, 
4.  Видеокарта -  6970 2 gb GPU с выходом mini DP
5. Добротный блок питания 850Ватт Corsair HX850i
6. 1C Сервер предприятия x64 v8.3.12.1790
7. 1C клиент x64 v8.3.12.1790
8. ОСь Windows 2012 Server R2

Итак, начнем тесты:

1. Первый тест - тест Гилева:

Результаты по Postgres 11

Результаты по MSSQL 14

Результаты теста Гилева:

1. в пользу MSSQL 14 в одно-поточном режиме 29 попугаев MSSQL  против 23 Postgres. 
2. 188Mb/сек в пользу Postgres против 140Mb/сек MSSQL в много-поточном режиме без опции SNAPSHOT_ISOLATION ON

Важное замечание. Если MSSQL перевести в режим SNAPSHOT_ISOLATION ON (Изоляция снимков, версионирование) - то MSSQL начинает хранить снимки баз до транзакции в памяти и дико выедает всю доступную оперативную память, отказываясь использовать файл подкачки.

Для этого снимаем конфигурацию Гилева с поддержки и снимаем режим совместимости, так как изоляция снимков работает только начиная с 11-12 платформы. После чего выполняем скрипт на базе.

В результате тест Гилева в много-поточном режиме вываливается с ошибкой из за нехватки памяти ОЗУ(RAM) 

Если увеличить память машины до 16-32GB в режиме SNAPSHOT_ISOLATION ON Postgres  так же обходит MSSQL .

Так что первый тест за Postgres

Тест 2: загрузка базы данных из dt файла.

Время на загрузку базы из *.dt файла

• MSSQL  1 минута 49 секунд  
• Postgres - 2 минуты 20 секунд

Второй тест в копилку MSSQL  Server 

Тест 3: Обработка по поиску и удалению данных по одной организации в 1С Бухгалтерия 3.0 (база данных плюс минус на 15 гигабайт).

Обработка находится тут //infostart.ru/public/1013709

Результаты отладки по MSSQL:

Результат MSSQL - 6422 секунды или почти 2 часа.

Результат Postgres - 61756 секунды или 17 с лишним часов 

Итого MSSQL отрабатывает результат почти в 10 раз быстрее. Почему? Возможно в том, что Функция НайтиСсылкиНаСервере отправляет кучу мелких запросов, а MSSQL работает в режим Shared Memory, а Postgres в протоколе TCP/IP, из за чего возникает задержка между сервером предприятия 1С и СУБД. В связи с чем получаем дикую просадку по скорости. 

Для Posgres Shared Memory так же настраивал, но увы скорости не прибавилось, так как этот параметр отвечает за совсем другую функциональность и не влияет на протокол обмена. Возможно руки кривые или лыжи не едут, так что критика тут уместна.

# PostgreSQL configuration file

shared_buffers = 3GB 

Вывод - если вы используете Сервер предприятия на одной машине с MSSQL сервер - используйте протокол  Shared Memory и еще один попугай в пользу Майкрософт.

Тест 4. Перепроведение всех Документов базы. Ссылка на обработку //infostart.ru/public/1117962/

Результаты MSSQL - 58 минут 47 секунд

Результаты Postgres- 8 часов 39 минут 47 секунд

Почему так долго не знаю. Параметры двигал туда сюда, не помогает, все равно долго.

Любопытные могут скачать настройки Postgres за 1 инфо-шейкель в описании.

Еще один жирный попугай в пользу Майкрософт

Update  Важное дополнение: В режиме TCP MSSQL проводил документы 1 час 17 минут. Почему так тормозит Postgres SQL 11 PRO - не знаю.

Тест 5 - тест fragster.ru 

Результаты тестов:

По таблице видно что Postgres незначительно выигрывает в работе со справочниками, но примерно в 10 раз медленнее работает с временными таблицами. Так как в MSSQL поздних версий временные таблицы кешуруются в ОЗУ(RAM). Результаты по регистрам примерно одинаковы в обеих СУБД, с небольшим преимуществом MSSQL. Этот тест так же в копилку Мйкрософт

Счет 1-5 в пользу Майкрософт.

Так что 11-ый слон по прежнему медленный, но в случае возникновения блокировок - слон как всегда более проходимый чем Лошадь от Microsoft.

От себя: Исходя из личного опыта сделал вывод:

1. Если железо мощное нет узких мест в ресурсах = то Лучше MSSQL
2. Так же с переходом на  Postgres, gjxnb забыл о злощасных  мертвых блокировках от которых в MSSQL невозможно Избавиться(SNAPSHOT_ISOLATION ON отчасти решают проблему но не всегда, особенно в типовых релизах). 
3. Так же при переходе на Postgres необходимо переписывать запросы суммирования ISNULL(значение1)+ISNULL(значение2), не то получим отчет с NULL. Соответствующей настройки "объединение со значением  NULL дает NULL off" -  в Postgres не нашел.
4. Если ваш сервер трещит по швам, не хватает памяти или прочих ресурсов, денег на новый сервер нет - держитесь за Postgres SQL на Linux 

Update 08.09.2019 

Установил версию Postgres SQL 10.8-18.1C с сайта 1c.ru. Настройки postgres выставил те что во вложении.

Итого получил результат по тесту перепроведения документов: 

• Время начала: 08.09.2019 20:24:04
• Время окончания: 08.09.2019 21:49:28
• Итого время 1 час 25 минут, что всего на пол часа больше чем MSSQL и на 7 часаов быстрее чем Postgres 11 версии (со стандартными настройками с сайта www.postgresql.org)

Чуть позже применил эти же на стройки на Postgres Pro 11 и получил результат  по тесту перепроведения документов: 

• Время начала:      08.09.2019 22:16:55
• Время окончания: 08.09.2019 23:38:29

1 час 22 минуты при настройках во вложении.