Здравствуйте.

Хотелось бы разобраться "почему так". Дано:
1. Сервер с ESXi 5
2. Две виртуалки
2.1. CentOS с PgSql 9
2.2. Windows 2008R2 c MSSQL 2008R2 и сервер 1С:Предприятие 8.2.17.143
3. Некий отчет, которые выбирает данные.
4. Сервер, ОС, SQL все 64 битное.
5. Одинаковые характеристики машин.

При формирование отчета при работе с Pg выдает результат за время, чуть менее секунды. Если запускаю MSSQL, тот же отчет работает 15 секунд. В это время процессор загружен на 100% сервисом MSSQL. Так же идет потребление памяти, а после отчета постепенно падает.

Как заставить MSSQL работать хотя бы сравнимо с PgSQL (вопрос "зачем" оставим за рамками этой темы)?

Все это тестируется на холодном запуске, т.е. вариант с кэшем отпадает.

(0) Это нормально, так и должно быть.

(0) можешь протестить v8: Многопоточный тест производительности 1с ? очень интересны результаты на одинаковом железе разных СУБД

(3) Сейчас сделаю

(2) Тогда вопрос такой: почему это нормально, чем обусловлена такая разница во времени?

какой сетевой  протокол обмена данными мс скл и сервера 1с ?

Вероятно MSSQL выбирает не оптимальный план выполнения запроса.
Статистика в порядке?

(5) Разницей в архитектуре.

(6) На данный момент TCP/IP. Предвижу вопрос: был оставлен ради честности сравнения, т.к. 1С с PG работает на том же уровне.

сравните замеры производительности.

(10)
возможно дело не в субд.

(3) Сейчас тестируется, а пока был запущен тест Гилева и он показывает следующее: PG ~ 13, MSSQL ~ 24.

(12) в настройке pgsql надо установить параметр max connections = 100 в бОльшее количество, так как тест использует > 100 потоков

(7) Сейчас идет тестирование, после посмотрю.

(13) я запускал ваш тест на своем железе, но после прохождения теста не понял, где смотреть результат

(15)
про тест Fragster
есть отдельная ветка. давайте не будем создавать её дубль.

проблема в п.2

SQL требует специальных шаманских действий для виртуалок. про ПГ - не знаю.

(17) А какие ритуалы вы порекомендуете для этих шаманских действий?

(18) без указания конфигурации и текста запроса под отчета можно только камлать

Насколько я помню - под виртуалки точили скуль 2012. 2008 может на виртуалке формировать неоптимальный план запроса

(13) Готово. Тест на PG только останавливается на 4 потоке.
В каком виде нужно дать данные?

На вскидку цифры бОльшие показывает MSSQL. Раза в 2 для временных таблиц, для остального в районе 10% разница в большую сторону для MSSQL.

(19) 1C:CRM 1.4, а сам запрос http://www.heypasteit.com/clip/0XQ5

(22) запрос плохой. во первых - .ссылка не нужна, во вторых - ИЛИ - лучше заменить на объединение или внутреннее соединение с ВТ вида (Выбрать &П1, &П2 Объединить все Выбрать &П3, &П4)

Бывает mssql выбирает неоптимальный план запроса, а бывает и постгрес... У каждого свои тараканы. Проблема в общем случае решается только одним способом - путем разделения сложного запроса на подзапросы с временными таблицами с индексированием ключевых полей. Тогда сервер будет вынужден прикрутить свою фантазию в смысле построения плана с nested loop по многомегабайтным таблицам..

(15)(21) перемещаемся в v8: Многопоточный тест производительности 1с

(22) если сиквелу не зарезали память + не сделали ТиИ с индексацией/регламент, то такой запрос может и минуты на сиквеле отрабатывать

(26) память отрезана, сделана реиндексация через ТиИ и регламент. Результат не поменялся.

запрос походу неправильный видимо должно быть
И ((КонтактнаяИнформация.Тип.Ссылка = &Тип
                И КонтактнаяИнформация.Вид.Ссылка = &Вид)
            ИЛИ (КонтактнаяИнформация.Тип.Ссылка = &Тип2
                И КонтактнаяИнформация.Вид.Ссылка = &Вид2))

(28) Какая разница? Эти скобки, что есть, что нету - результат  один. А вот ".Ссылка" там явственный тормоз.

(29) :) лучше медленно и правильно, чем быстро но фигню

Для справки.
A*B+Y*Z = (A*B)+(Y*Z)

(29) Убрал "ссылки" и запрос стал мгновенно исполняться. Спасибо большое за путь истинный.
Т.е. получается, что PG оптимизирует этот запрос и идет по индексам, а MS этого не делает. Верно?

Отдельное спасибо Fragster и Reaper_1c.

(32) Как PG обрабатывает такую ересь - не знаю. При работе с MS тупо строится соединение для каждого разыменования.

(32) Обращение через точку приводит к тому, что мс скуль сделает соединение с таблицей.
Особоенно грустно поулчается, когда тип реквизита Все документы (например) и ты получаешь Реквизит.Дата

(35) Спасибо большое за объяснение.

Разработчик отчета говорит, что иногда, если не указывать "ссылку", то MSSql c конфигурацией 1C:CRM уходит в бесконечный цикл. Это ересь или есть "подводные камни"?

Парни.. извините что пишу тут не по теме..
Подскажите пожалуйста ответ на вопрос...
Что отвечает за порядок движений в документе по регистрам?
Кто решает какой регистр проводится первым, а какой вторым?

Сегодня проводил тестирование разных вариантов работы 1С и в общем получается, что с PgSQL работает шустрее (на секунды, но быстрее): например при том же обновление конфигурации. Куда посоветуете копать: в сторону некорректной настройки MSSql или еще что-то?

(38) Внутренняя логика платформы.

(40)Блин.. я тут подредактировал немного один документ.. и логика изменилась у платформы.. стала наоборот сначала один регистр проводить, а потом второй.. а на этом оказалось завязана конфа.. замещаются там движения..

(41) попробуй в обработке проведения принудительно записывать движения.

(39) Не надо копать. Так и должно быть. Есть шанс, что MS SQL 2012 в связке с 8.3 продемонстрирует некий прирост, но это надо пробовать.

(43) Хорошо, а чем обусловлено, что на синтетических тестах от Гилева и Fragster все-таки результаты выше у MS, чем у PG?

(44) Наверное тем, что тестирование не учитывает всех факторов, из которых складывается производительность реальной системы.

(45) Ну т.е. их "синтетикой". Понятно, спасибо большое.

(46) Да не за что. Я тест Гилева воспринимаю только как инструмент для проверки того, как влияют изменения настроек/железа в рамках связки 1С+СУБД. Т.е. для сравнения результатов до и после. Сравнение разных систем этим тестом, как мне кажется, не является показательным, т.к. производительность реальной системы корректнее измерять временем исполнения пользовательских сценариев, а не временем исполнения каких-то конструкций языка. Тест Fragster'а не пробовал.

(39) >на секунды
>при том же обновление конфигурации

Забейте.