v8.1:Сравнение производительности на Postgree и MSSQL #244650

Добрый день, коллеги. Кто-нибудь уже сравнивал производительность 1С 8.1 на одном и том же железе например при работе с УПП? Кто быстрее?

Добрый день, коллеги. Кто-нибудь уже сравнивал производительность 1С 8.1 на одном и том же железе например при работе с УПП? Кто быстрее?

Лошадке больше не наливать :)

тут где-то на форуне раз ДЦать эта тема проходила... попробуй воспользоваться поиском

Есть кто адекватный по теме? :)

Для БД понятие "быстрее" это производительность и пропускная способность. Пока для Постгреса не сделали блокировки на уровне записей, МС вне конкуренции.

спасибо, все понял.

Таблица работы блокировок в различных движках

Таким образом, имея правильные руки и гору терпения, можно узкие места конфигурации так заточить с помощью управляемых блокировок, чтобы и на PostgreSQL пропускная способность была нормальной.

будет намного лучше... чем автоматическая... только это новый уровень ошибок.... и так ли надо использовать управляемые блокировки вообще?

Намного лучше? Ну-ну. Я по молодости тоже пытался блокировками рулить и хинты расставлять исходя из своего понимания плана выполнения запроса. Когда еще с 1С не связался. Результат чаще всего оказывался противоположным :))

Возможности управления блокировками в 1С более структурированы.

С другой стороны, типовую конфигурацию просто так не перелопатишь, а когда разработчики сделают блокировки управляемыми - неизвестно.

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

тут блокировки не уровня SQL а уровня объектов методанных...

В конце концов происходят блокировки на уровне записей в таблицах SQL

но не на все прочитанные данные....

Наивность птицев просто безмерна....

Короче с PostgreSQL есть проблемы, когда перепроводиш документы пачкой то через небольшое время начинают сыпаться "Конфликт блокировок при выполнении транзакции: ERROR:  canceling statement due to statement timeout" причина в сборщике мусора "autovacuum" в Postgre который отвечает за оптимизацию и чистку завершенных транзакций он начинает блокировать таблицы для обработки а в 1с в запросах почемуто режим  timeout стоит 1 сек....

Подскажите а 8.1 на MS SQl тоже может работать?

Да !

местами...

Дык автовакуум можно отключить

Отрубал, скорость работы со Postgre начинало падать

Дык его тюнить надо, доки читать там и прочее. Насколько я понимаю, в сравнении еще пока никто не тестил.

Тестил один товарищ 8.1 vs 8.0  MS SQL " Провел небольшой синтетический сравнительный тест производительности 1С 8.0 и 8.1. Тестовая конфигурация: Hardware --------- Intel Celeron D 2.8 Ghz RAM 1GB DDR2 533 HDD WD 80 GB SATA1 (ну это мой рабочий комп, сервера мощного в наличии не было) Software --------- 1С 8.0.16.2 + Сервер 1С 8.0.16.2 1С 8.1.5.113 + Сервер 1С 8.1.5.113 СУБД: MS SQL 2005 (все установлено и работает на одном компе) Предварительные данные ------------------------- Для каждой версии 1С был создан справочник виртуальных "Товаров" ("Код" 10, "Наименование" 150 и больше ничего). В каждой базе нагенерирован 1 000 000 элементов (жалко блин генерится долго) обычным Random-ом из (" а-я,А-Я,a-z,A-Z,Ё,ё,'символ пробела' ") для каждого символа "Наименование". К тому же внутрь поля "Наименование" каждого элемента также в Random-ные позиции вставлены выбирающиеся по Random-у предопределенные слова: ("снег","лед","соль","моль","мель","медь","град"," вода"). Т.е. получались примерно такие опусы: ----------------- где стрШаблон - это строка поля ввода, например: "%вода%" "%лед%, т.д. (напомню % - это маска любого количества любых символов, то же, что и * в любой консольной команде виндыдоса) Результаты ----------- Замер времени проводился с помощью самого конфигуратора. Среднее время выполнения самого запроса 1С 8.0 - 68-72 сек 1С 8.1 - 47-51 сек (120-124 тыс. записей в результате запроса) " Взято из инета.  ;)

Пытался я его шаманить но блин если бы 1с не ж....сь и дала патчи нормальны тогда можно было откомпилять его с более приемлимыми настройками для системы. То что 8.1 быстрее 8.0 и так было на бетах видно, щас интересуют тесты MS SQl vs PostgreSQL

На счет тестирования я уже писал, могу повторить: имеем - Novell SLES 10 x64, v8.1.5.123 x64 + PostgreSQL x64 1. Заявка покупателя (период 2 мес.): Linux - 13, Windows - 14. 2. Переоценка НТТ (7 мес): Linux - 2, Windows - 4. 3. ПКО (2 мес): Linux - 13, Windows - 15. 4. Перемещение(2 мес): Linux - 10, Windows - 14. 5. Реализация (2 мес): Linux - 55, Windows - 54. 6. Плат поруч вход.(2 мес): Linux - 1, Windows - 2. 7. Опроходование (за весь период 11 мес) -  Linux - 5, Windows - 3. Однозначно большие документы оприходования прододятся существенно дольше: 4175 позиций в док  Win - 1 мин, Lin -1:40 (бывает до 3-4 мин - не постоянно) Анализ большей части документов показывает что проведение документов в большенстве случаев по скорости превосходит, но в особых случаях: документы с большим кол-вом позиций(оприходование начальное) уступает по производительности MsSQL, хотя мои предположения ето может быть связано именно с ошибками в реализации сервера 1с предприятия под linux и выше приведенными ошибками. PS: Вышеприведенные тесты не являются обсалютными и равноправными, т.к. на windows фукционирую действующий базы. хотя загрузка системы во время проведения тестов не превыщала 50%. Средняя 25-35%(общая на процессоры). Загрузка Linux сервера: ~15-25% использование памяти рабочим процессом posgres 3200M (VIRT - ето и есть shared_buffers)  - до 2.6G (RES - пик). Тем "паче" разное "железо": Windows - Opteron 265 x2шт + по 2Gb DDR400 на процессор(итог 4Г) + ENT SATA2 RAID Intel SRCS28X + 4 SATA2 250GB (buf 16M) в RAID 0; Linux - XEON 5110 x2шт + 4Gb DDR2 + INT RAID +  4 SATA2 250GB (buf 16M) в RAID 0;

Вроде где-то на сайте 1С выложила патчи, которые она написала для постгреса

Ну вот и началосььььььь :) Теперь и 1С к постгри патчи пачками начнет клепать.  Хорошо хоть MS SQL закрыт.

Очень хорошо, теперь есть что крутить посте...

почитал про тест "сравнения" 8.0 и 8.1 и решил убить два часа времени и провести тот же синтетический тест на платформе Firebird / IBX / Delphi  :) Железяка у меня следующая: Pentium 4 2,66 (cache 1024) операционка: Windows 2000 rus SP4 сервер БД: FireBird 1.5.2.4731 клиент: написанная за полчаса программка на Delphi 7, которая работает с FB через имеющуюся в D7 библиотеку IBX. Программа и генерит данные и делает запросы на выборку... структура тестовой таблицы: CREATE TABLE TEST (    CODE VARCHAR CHARACTER SET WIN1251 COLLATE WIN1251,    NAME VARCHAR CHARACTER SET WIN1251 COLLATE WIN1251); Эта табличка "забивается" данными сгенерированными по Random('А-я')+ вставка случайным образом в случайную позицию поля Name слов: 'снег','лед','соль','моль','мель','медь','град','вода' Генерация 1 000 000 (милииона записей) - 7 минут ! Запрос: select * from test where name like '%снег%' ВЫПОЛНЯЕТСЯ ! ВНИМАНИЕ !!!  *** 4 (ЧЕТЫРЕ !) *** СЕКУНДЫ !!!

А сколько записей вернуло?

+1 да и тип поля наименования надо бы юникодный сделать

Якой объем тестовой таблицы получилось?

проверка на права была в delphi? :)

2 PowerBoy: Возвращается, по каждому из слов что-то около 50000 записей.. 2 DmitrO: А что в 1С - юникод ? (я просто не в курсе) 2 zaki: Объем таблицы - 1000000 записей.. А объём базы, которая содержит только эту таблицу - где-то 220 МБайт. 2 ERWINS: Каким образом Вы предлагаете выполнять такую проверку ? Подскажите алгоритм (или что-то), что бы было похоже на 1С.

+ Даешь приямые запросы в 8-ке :)

приямые = прямые

они там нафиг не нужны?

см

имхо, не показатель

скорость генерации записей - не показатель скорость выборки - показатель

Кстати, при тестировании, когда сервер предприятия и SQL на одной машине, заметил, что время (по топу) работы сервера предприятия существенно (раз эдак в 5-6) больше работы сервера SQL. Так что, видимо, в кластеризации именно сервера предприятия есть смысл :)

не понятно, обоснуй

таки, открою завесу страшной тайны - MSSQL давно можно было в кластер закидывать..

Все что есть пока, удобно когда надо данные из других баз тащить, например из 77. Имхо большего и не надо.

И предприятие 8.0 будет с этим кластером работать? А тогда где почитать? :)

в догон - в картинках:

Надо было не полениться, а написать быстренько аналог хотя бы УТ и "провести тот же синтетический тест на платформе Firebird / IBX / Delphi"

+1

сравнивать версионник с блокировщиком - это сравнивать теплое с мягким

Если у тебя получится "быстренько" накатать УТ, тогда 1С нафиг никому не нужна.

не думаю что это уж очень сложно.... там сколько кода? так вот из ходи из 100 строк в час...

Откуда такая производительность в 100 строк? А подумать

Т.е. нужно время "на подумать"

а тот же самый тест запусти при нагрузке к базе юзеров 50. боюсь файерберд загнется , в отличии от скл сервера.  учи матчасть !!!

Насчет "загибаемости" Firebird-а с 50-ю пользователями сильно сомневаюсь :)

Прикольно - возьму на заметку, но с 8-кой пока завязал ? Если скорость выборки платформы 1С на порядок медленнее T-SQL выборки, то это, имхо, показатель.

Я не про сравнение 1C и T-SQL, а про: скорость генерации записей - не показатель скорость выборки - показатель >>

И что не понятно? Что обосновывать-то?

Почему скорость выборки должна превалировать над скоростью генерации записей. Для какого случая? Построение отчетов?

Это всего лишь моё мнение :) В ПриЗаписи в 8-ке много чего отрабатывает. Поэтому скорость записи тут сравнивать некорректно. Да и процент времени заполнения данными обычно на порядок меньше времени получения данных, т.е. чаще строятся отчеты, а данные заполняются реже.

Мысль ясна. Дык и сравнение с тоже может оказаться некорректным.

Угу, вот и хотелось бы сравнить не с тестовой база на FireBird, а с прямым TSQL запросом к реальной базе на 8-ке.

Могу сразу сказать - будет быстрее :) Только это ничего не даст. Прямой TSQL запрос вернет "сырые" данные, а 1С запрос предоставляет дополнительные сервисы, отсюда и дополнительные расходы. А еще RLS, и т.д. и т.п.

Допустим RLS пустой - нет фильтров. Ну вот и хотелось бы оценить насколько целесообразно использование прямых запросов в 8-ке. Собственно навеяно веткой, где хотели сравнить 1С 7.7 + ToySQL и просто 8-ку.

я лично работал с fb при 60 интенсивно работающий юзверях. Есть люди, у которых по 400 пользователей в среднем.

Я просто хотел показать, насколько 1С всё-таки не эффективно работает с сервером БД... не важно с каким. Уж слишком много "прослоек" всяких, слишком толстое и неповоротливое ядро у 1С. Я думал, что когда-нибудь 1С-ссеры таки сделают нормальный клиент-сервер из своей "платформы"..  ан нет  :(  А тут они в "трех-звенку" рванули !  Час от часу не легче..  Я вообще считаю, что 1С-су повезло, в том что мощность "железа"  возросла в десятки раз ! Иначе бы не было никакой 8-ки :) :)

Само сравнение является некорректным, т.к. тесты работают на разных уровнях. К примеру можно написать тест (на том-же Delphi) который бы записывал миллион записей в файл и потом считывал их в соответствии с шаблоном. Уверяю вас, что время работы отличалось бы на те-же порядки по сравнению с тестом FireBird, при грамотной реализации.

забыл сказать. Тем самым мы покажем, насколько неэффективно работает FireBird с диском и памятью, для данного теста разумеется :)

> Я вообще считаю, что 1С-су повезло, в том что мощность "железа"  возросла в десятки раз Наоборот, они на это и рассчитывали. Когда еще в IBM девиз был: "Компьютер должен работать, а человек думать". Если думать о железе, то когда думать о задаче? Все развитие айти идет как раз - тупое но толстое пусть работает. И чем меньше приходится тратить время на оптимизацию скорости выполнения, тем больше человеку времени для подумать над самой задачей. > А тут они в "трех-звенку" рванули ! Так не клиенту же обрабатывать такие высокоуровневые прикладные объекты.

на порядок, а не на порядки...

В случае записи записей можно добиться максимальной скорости работы винта. SATA винт думаю сможет выдать 40MB/сек при последовательной записи. Итак, 1000000 записей по 160 байт будет где-то 160Mb. Делим на 40Mb/сек - получаем 4 сек на всю запись. А на тесте FireBird это заняло 7 мин или 460 сек. Вывод - увеличение скорости на два порядка :)

2 vogenut: Не понятна ваша фраза: "...тесты работают на разных уровнях..." Как раз на одном и том же уровне - уровне клиента. И при чем тут файл ??? 1С ведь не с файлом работает, мы ведь сравниваем SQL-ные 1С-ки. А что бы добиться тех 4-х секун записи на винт, придется использовать скорее всего Assembler и писать программу прямого доступа к винту, минуя операционку... Вы где нибудь видели систему учета, вроде 1С, написанную на ассемблере ?

Под фразой "...тесты работают на разных уровнях..." хотел сказать что функциональность тестов различается - в случае 1С это объект РезультЗапроса, который явно (и важно, неявно) предоставляет гораздо большую функциональность для дальнейшей работы с этими результатами нежели объект аля DataSet в тесте на Delphi. В Delphi тесте возвращаются сырые данные, которые потом надо будет ручками еще обрабатывать. Именно поэтому сравнение этих двух тестов не совсем корректно. По поводу клиента - тесты тоже различаются, т.к. в случае 1С скорее всего тест выполнялся на клиенте (т.е. в клиентском приложении 1С), а в тесте на Delphi имелся прямой доступ к СУБД. Что-бы их уравнять в этом плане, надо как минимум перенести выполнение теста на сервер 1С. Да забыл, структура базы тоже различается, я не заметил в тесте на Delphi не индексов, не дополнительных служебных полей, которые есть в 1С. Отсюда это сравнение теплого с мягким, и можно с тем же успехом наваять тест который будет работать непосредственно с файлом собственного формата - мы же тестируем select с фильтром, не так ли? Что-бы было все честно, см :) По поводу записи на винт. На ассемблере писать ничего не надо, все равно Windows сделает это гораздо лучше вас. И прямая запись на винт (минуя кэш Windows) есть в WinAPI и ассинхронная запись, что-бы еще время осталось на генерацию новых записей.

Все таки, насколько отсутствие блокировок на уровне записей нивелирует все остальные преимущества PostreSQL перед MS SQL?

а можно весь вписок всех "остальных преимуществ" PostreSQL перед MS SQL?

... С пользовательского сайта 1С: Вариант работы 1С:Предприятия 8.1 с СУБД IBM DB2 в версии 8.1.5 реализован для целей бета-тестирования и поставляется в виде отдельного комплекта. Использование этого варианта работы для автоматизации реальных задач предприятия может выполняться только в отдельных случаях по решению пользователя, совместно с партнером, поддерживающим внедрение, и с учетом информации о статусе бета версии данного варианта.

Ну хотя бы "Open Source" и возможность работать на Linux :D Вообще почитать можно тут:

Кто-то реально перевел рабочую базу данных с MS SQL на PostgreSQL? Я думаю, что их ощущения представленные в виде топика на этом форуме, дадут гораздо большую пользу, чем куча досужих размышлений...

Open Source - это преимущество? У тебя хватит здоровья разобраться в исходниках, поправить там что-то и перекомпилировать? И в чем преимущество "работы на Linux"? Типа "а шоб було"? Поищите на PostgreSQL. Можно с картой и фонариком.

Open Source становится серьезным преимуществом при ограниченном бюджете, то же касается и Линукса. Как бы то ни было, но отличительная черта отечественного менталитета, безудержная любовь к "халяве", оказывает определенное влияние на наш выбор. Если внимательно прочитать вышеприведенную статью, то можно обнаружить и другие преимущества PostgreSQL, причем без карты и фонарика.

так где халява то?.. в опер сурсе, или нет?..

Не нужно путать теплое с мягким, а именно Open Source не нужно путать с бесплатностью.

И кроме того любой менеджер по продажам тебе таких диаграмм порисует, что очередь эскимосов выстроится покупать холодильники. Увы, PostreSQL очень средненький сервер. Гораздо слабее MS SQL. Не говоря уже о "больших" - DB2, ORacle.

Хорошо, а как же многоверсионность? В MS SQL такого нет, он использует стандартные блокировки. Правда непонятно насколько 1С использует эту самую многоверсионность...

Версионность не панацея. MSSQL2000 не был "версионником", что в свое время не мешало ему в TOP10 того же tpc.org брать 8 мест из десяти (на некластерных решениях чуть похуже). И только потом Oracle и DB2 его подвинули. MS SQL 2005 уже "версионник". PostgreSQL же я ни разу не видел в топах за последние лет семь.

На MS SQL постоянно жалуются в плане стабильности, если его периодически не перегружать, то заметно падает производительность.

Завтра докачаю финал 1св8 сделаю годовую выгрузку, думаю, гигов 50 буит, и начну проверять.

Так это failover. А кластер восьмерок -- load-balancing

Или нет?

Цена решения.

Чушь. Нормально он работает без всяких перезагрузок. Есть даже экзотический пример древнего MSSQL6.5 на NT3.51, работающего семь лет практически непрерывно - пару раз в год только пылесосом пыль с него выдували :) Слухи о том, что MSSQL мастдай сильно преувеличены. Конечно звезд с неба он не хватает, но это нормальная рабочая лошадка. А по отношению цена/производительность подвинет практически всех.

Имхо, тут надо мерить не только производительность SQL сервера, а связку сервер предприятия -- SQL сервер. Короче, никому не верю, завтра-послезавтра буду сам проверять :)))

Читайте тут -

Так Оракл поддерджим! 100!

Офигеть... Есть ли реальные результаты? Что получилось в итоге? Firebird например очень слабенькая база по сравнению с MSSQL (5 лет работала(Firebird) в офисе, полгода назад заменили на MSSQL), но связка 1С+MSSQL тем не менее на порядок более тормознутая, чем Firebird+Delphi (и почему? :))