Поставил PostgreSQL Database Server 9.1.2-1.1C(x64) с настройками рекомендуемыми в данной теме:

v8: Производительность сервера 1с

а именно:
shared_buffers = 2048MB
temp_buffers = 8MB
work_mem = 8MB
maintenance_work_mem = 1024MB
fsync = off
synchronous_commit = off
full_page_writes = off
wal_buffers = -1
checkpoint_segments = 40
enable_nestloop = off
effective_cache_size = 4096MB
max_locks_per_transaction = 150
escape_string_warning = off
standard_conforming_strings = off

В результате теста Гилева получил 25 на постгресе против 36 на MSSQL. На какие настройки следует обратить внимание чтобы повысить производительность хотя бы до уровня MSSQL? Версия платформы 1С 8.2.16.

>На какие настройки следует обратить внимание чтобы повысить производительность хотя бы до уровня MSSQL

а это возможно в принципе?

"хотя бы до уровня MSSQL"
А MSSQL существенно медленнее чего-то при работе с базами 1С?

"Хотя бы до уровня MSSQL"
Ага. Всего лишь :)

даёшь до уровня Ораклины, не мелочись!

я написал "хотя бы", т. к. собственно и производительность MSSQL не ахти :)

(5) ну СКЛ тоже настраивать надо

(0) На какой ОС-и поставил?

(5) но ведь и ежу понятно, что постгресу до SQL еще ползти и ползти.

(8) угу, sourceforge работает postgresql и на MS переходить не собирается, интересно почему?

(8) откуда такая информация?

(7) на Win 7 x64

(9) потому что 1с с постгри работает на автоматических блокировках - зело криво, блокируя таблицы а не записи например

(8) Заявления, типа, "постгресу до SQL еще ползти и ползти", говорят о полнейшем непонимании вопроса. Хотел бы я глянуть, как MS SQL на любых других платформах будет работать.
(11) PostgreSQL  прекрасно работает на Linux. Что этому мешает?

Честно говоря, всё-таки непонятно, почему на тупой записи постгри на 30% медленнее получился...
(0) Колись. Пострги под винду поднимал? Или не поленился на одной и той же конфигурации линукс и винды поднять?

(14) да, постри под винду.. это так критично для него?)

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

(16) ну а ты как тестил? в автоматическом?

(15) Краем уха слышал, что MSSQL более тесно интегрирован с системой, чем позволяет документированный API. Могу ошибаться. Но чуйку имею, что под линухом постгри быстрее будет.

(18) + В смысле, быстрее чем он же под виндой.

Кстати с 17 релиза нэйтив клиент, так что связке 1с+постгрес действительно еще расти и расти

(17) Для теста Гилева режим блокировок не важен.
В тесте выполняется интенсивная запись 5000 документов. Глубокого смысла в бизнес-логике кода нет, оцениваться просто условно выбранная за эталон производительность документа Х.

(13) http://www.tpc.org/tpcc/results/tpcc_results.asp?orderby=dbms

Что-то на старость у меня со зрением - на какой строчке PostgreSQL?

(22)К старости надо бы не только на зрение уповать. Мозг, как и в молодости, должен тренироваться.

запустил замер производительности, в постри работает тормознее..
постри:
запись документов 132,73 сек. 41%
удаление 95,22 сек. 30%
мс скл:
запись 82,2 сек. 36%
удаление 78,6 сек. 35%

(24)Вообще, тебе для чего эти тесты?

(25) вот решил перевести базу на бесплатную СУБД, и делаю замеры производительности, чтобы понять насколько лучше/хуже будет работать база.

(26) так под линуксом и померяй постгри.

(13) учитывая что 1с не юзает возможности конкретной субд, скорее всего в отношении 1с ms sql будет быстрее чем postgres

ну может быть дело все же в каких-то настройках постри?...

+(28) у ms sql все таки получше дело обстоит со всякими автоматическими настройками и подстройками под работу. а postgres надо напильником дорабатывать что бы выжать из него максимум.

(26)Тоже тема. Только, вот, я думаю, тебе стоит поглубже покопаться в этом вопросе. Я понимаю, что тут есть своего рода "гуру" в области тестирования производительности, которые наваяли тесты. А ты попробуй сам тесты составить и проверить. Я, например, в "тесты от гилева" не очень. Залепух несколько нашел - мама дорогая.
(28) Действительно, соглашусь в изначальном "преимуществе" в связке "1с ms sql".
(26) А попробуй под Linux

(29) я лично под виндой его не ставлю.
А линуксовый- только патченый, например, от эзерсофта.
Ну и ручками иногда нужно пройтись, там от размера памяти машины, например, параметры..

А вопрос не у кого не возникает. Почему 1С работает со стандартным MSSQL, PostgreSQL надо брать какой-то особенный или патчить натуральный.

Отвечаю 1С взяла и сделала возможность запуска своего продукта на бесплатной SQL. Больше они ничем не занимались.
Они просто для галочки это сделали. Как сам сидящий на PostgreSQL говорю: Они не сделали хоть полшага в сторону совместной работы...
Какие вопросы производительности?

книжко, а ля методичка. может кому пригодится.

https://www.dropbox.com/s/ovo47ckdne29w76/postgresql.pdf

(9) postgre в автоматическом режиме блокирует таблицы, но работает на уровне изоляции транзакций read committed, в отличие от Repeatable Read/Serializale в MS SQL, так что при парралельной работе не всегда MS SQL будет быстрее, т.к. намного чаще будет ставить блокировки, пусть и на конкретные строки. Ну и postgre по умолчанию снапшотами обеспечивает read committed, что, опять же, значительно быстрее при параллельной работе, чем каждый раз блокировка на чтение при записи в таблицу.

(23) Я должен там силой мысли искать непревзойденный PostgreSQL, если уж глаза его не видят в "типовых" тестах TPC-C?

(35) 8.3 юзает версии строк.

(35) О! Вот Вы то точно мне скажете на какой там строчке PostgreSQL. Я так понимаю с такими наворотами на первой? Не то что убогий MS SQL?

(26) DB2 не смотрел?

(35) postgre в автоматическом режиме блокирует таблицы в 1С.
Это прикрутка 1С. К стандартному PostgreSQL это не имеет отношения..

(39) неа, пока не смотрел...

Где-то здесь же было, что PostgreSQL с 1С под виндой работает быстрее, нежели под линухом.

(39) бесплатный дб2 - ограничение 2Г на процесс или процесс на ядро...

тестил на самописной  базе дб2, постгри и мсскл, последний вышел с огромным отрывом (много где используется СрезПоследних() на РС).

(34) Ага, спасибо. Давно хотел по свободе что-то подобное полистать.

(38) Ты эта, покажи мне в том списке MySql, умник, на котором facebook работает. Ну и уровни изоляций, используемые в связке с 1с - это, конечно же, исключительно фича СУБД!!! Подобные заявления как бы раскрывают глубину знания вопроса.

(43) ну для "потестить" 2Гб хватит, а в продакшн можно и купить.

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

(36) Я нигде не писал про "непревзойденный PostgreSQL". Предлагаю думать откуда и почему и на каких ресурсах все эти тесты выполняются. И, главное, для чего. Я работал с IBM и знаю как продавливаются и публикуются подобного рода тесты.

(45) Не сомневался в том, что одноэсники даже не поинтересуются что есть TPC-C :)) Иначе они были бы хреновыми одноэсниками.

(48) в тесте обычная запись документа в БД...

(49) Это стандартный тест на операции по складу, который, тем не менее, имеет мало общего с тем, как 1с работает с СУБД.

(49) ну да, если ставят против MS SQL MySQL и постгрес, то можно далее не вести диалог)) кстати, в свое время и владелец оракла так и не отдал 1 миллион баксов Гейтсу, когда MS SQL показал производительность, кажись, в более миллион операций (или транзакций, не помню) в секунду))

(50)Честно говоря, 1-эсники, как правило, слабо представляют работу СУБД. Ничего в этом плохого не вижу, кроме того, что, вот так, они(как правило) пришли в автоматизацию через 1С. Поэтому, если ты решил заняться этим вопросом всерьез, не на форуме 1С ответы надо искать

(49) Давнее мнение Sun о TPC http://www.c0t0d0s0.org/archives/5383-Forrester-about-TPC-Benchmarks.html

(35) "так что при парралельной работе не всегда MS SQL будет быстрее, т.к. намного чаще будет ставить блокировки, пусть и на конкретные строки"
Типа накладные расходы на блокировки могут настолько повлиять  на общую производительность, что с табличными блокировками будет быстрее? Данунах.

(48) Тем не менее есть объективная реальность - открытый и повторяемый тест. Относительно ресурсов - никакая религия не мешает запустить PostgreSQL на тех же ресурсах. Более того, его производители явно не против так же продавить такой тест. Но увы...

Я не говорю что PostgreSQL плохая машинка. Но он классом пониже MS SQL и искать при его применении роста производительности по сравнению с MS SQL на обработке транзакций несколько самоуверенно.

Даже если рассматривать соотношение цена/транзакция, то и тут ловить особо нечего http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp

(52) Порой бывает сложно понять, что для разных задач нужны разные системы.

(52)MS SQL, кроме, как на виндах, имеет еще реализацию?

(56)Продолу, недосказанное
"Но увы... ", у них нет столько бабла.

(57) почему же, понимание у меня например, есть.. и это понимание говорит, что не нужно сравнивать системы разных классов..
(58) наличие или отсутствие реализации на других платформах о чем-нибудь говорит??..

(0)зачем поставил?
если не влезает в 12 экспресс и это не гимнобаза то точно бабосы есть на скуль мс

(60) Ну, универсализация "о чем-нибудь говорит??.."

(48) Я не знаю как у вас, а у нас реалиная и объективная реальность - скорость, которую система показывает на серверах заказчика, а не пролоббированные корпорациями синтетические тесты. Ну и как бы (сюрприз!) параллельность работы на некоторых инсталляциях с postgre иногда бывает выше даже на глаз.

это было не в (48), а в (56)

(57) Чтобы Вы не позорились, продолжая дискуссию в этом же ключе - тест TPC-C моделирует прикладную задачу обработки заказов. Он моделирует сложную систему OLTP, которая должна управлять приемом заказов, управлением учетом товаров и распространением товаров и услуг. То есть именно ту задачу, которая "крутится" на 1С. Именно поэтому я привел результаты этого теста, а не TPC-А, -В, -D, -R...

(63) Ну если параллельность работы на глаз, то это конечно круто... Против этого никакой тест не попрет.

(62) в чем "универсализация" в случае MS SQL не совсем понимаю...
(66) анекдот про "на глаз" знаете?)))

(65) Это очень общее описание, данную задачу решают УТ11 и УТ10, и все - совершенно по-разному и с разной производительностью. Разные регистры, разные индексы, разные запросы. Ну и 1с как бы и другие задачи решает - себестоимость считает, зарплату, и т.д. Всё это на объектах 1с - регистрах. С тестом TCP-C ничего общего.

(67) Действительно. Чего тут непонятного? MS SQL - только на виндах. Причем на своих "родных". Вот и вся "универсальность"

(67) На глаз - это когда у пользователя всё висит и документ проводится по 20 секунд в одном случае, и 3 секунды в другом случае. Анализ блокировок в такой ситуации ожидаемо показывает зависание на блокировках изменяющихся таблиц в первом случае (даже блокировка 1 строки при запросе в другом документе не по индексу будет вызывать ожидание на блокировке у второго документа) и свободное проведение во втором случае. Ну и неплохо бы знать, что разница - в особенностях использования уровня изоляций.

(66) Это уже несерьезно. Я могу написать тест под "PostgreSQL " и размахивать им.

(71) Несерьёзно ориентироваться на подобные бенчмарки, когда у тебя есть система и производительность можно замерить на ней.

(68) Какая разница для SQL-сервера, считать зарплату или считать себестоимость? Он обрабатывает транзакции. Или согласованные операции записи-чтения, если угодно.

(70) Это уже не технический вопрос, а вопрос религии. Мне сложно обсуждать что-то в терминах "все висит" и т.п.

(71) Можете. Если его пример tpc.org. Но я хочу заметить, что в списке не какой-то один сервер, под который что-то специально заточено. Или они все сговорились и написали тест под себя?

(73) В чем разница между программами? Это всё выполнение инструкций процессором.

(72) Коллега, даже утверждая, что длина 22 добавляют "см". Для того, чтобы получить универсальное, проверяемое и сопоставимое значение. А то один будет мерить в попугаях, другой в удавах... Хотя нет, пример не удачный - в попугаях всегда длиннее.

В общем так. Простой аргумент. И больше ни спорить ни писать смысла не вижу.
Пример. Приложение на 1С. База на PostgreSQL. Одна операция просто задолбала. Проходила 3-4 минуты. Хотя, по моему разумению, там ничего такого дикого не должно было быть. После того, как проползал по коду и исправил его, эта самая операция стала проходить за 1-2 секунды.

(76) Всем известно, что 90% проблем производительности - в коде, да.

(73) В чём сложность осознать, что в одном случае есть ожидания на блокировках, а в другом - нету? Есть показания ЦУПа, которые явно это показывают. И это всё на одной конфигурации. А на другой - заметный выигрышь другой СУБД. Не надо тут на субъективность восприятия пинать, это реальная решаемая однажды проблема.

MrStomak, так и не понял: ты за нас, или против Советского союза?

(77) Как правило, именно, так. Я, когда кодил в базе на ORACLE(к 1С это никаого отношения не имеет), исправлял код открытия документа(38 тыс. записей. Москвичи такой документ сваяли) с 30 минут до секунды. Они, оказывается, не тестят больше 3-4 записей. В 1С, похоже, такой подход.

Блин, у вас тут страсти сильнее чем в секции политика)))

(79) Моё мнение - MS SQL не панацея, но с ним работать удобнее. Заявление, что postgre по производительности до него как известно в какой позе до китая - наглая ложь, значительной разницы в производительности в задачах 1с нет. Несмотря на "объективный" TPC-C

(81) Ага. Тут предлагают меряться.
(82) Согласен. То же самое -  MS Windows не панацея, но с ним работать удобнее. Заявление, что круть несусветная - тоже наглая ложь

(82) "но с ним работать удобнее ". В общем да. Хотя бы 1С   не вылетит при реструктуризации . А вот под Оракл или Постгри  шансы вылета могут увеличиться в разы.  Но это не говорит о том , что последние хуже/лучше.

(82)-(83) в том и суть. Если в общем жигули и бмв принципиально не отличаются - колеса, корпус двигатель. Но если дойти до удобнее то тут вскрываются разницы)))

(85) Банальное и неудачное сравнение

(84) пострги однозначно будет хуже на больших объемах..

(87) добавить надо .... при управлении сервером приложений 1С. Так точнее.

(85) для особо рьяных фанатов бмв повторю еще раз - facebook работает на жигулях. Попытка работать на мерседесе увенчалась тем, что тот еле-еле затошнил на первой передаче.

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

Интересно, а кто нибудь из спорящих работал хоть с одной из обсуждаемых СУБД не в контексте 1с?

(91) Конечно. Однако, обсуждение идёт в контексте 1с.

(89)да я собственно не фанат. Не надо горячится. Более того я не спец в скулях. но как неопытному пользователю, со старта поставившему мс скуль и постгри с коробки чувствую разницу. Естественно, если допилить постгри то и из него можно сделать бмв, а при неумелом обращении с мс скуль оно превращается в копейку. Это из собственной печальной практики(((

(91) просьба не задавать неудобные вопросы)))
зы.. с мс скл трудился.. в том числе, в свое время готовил тесты для оценки производительности 1С на мсскл..

(91) Периодически.. когда отчет надо быстро написать а "объем данных  большой и долго" ТOAD рулит.  Т.е. как быы в контексте 1С , а с другой и нет.

http://wiki.postgresql.org/wiki/TPC-H
Про другие TPC, наверное, никто и не заморачивался особо.

(96) Да как же так можно!! "for reasons that aren't necessarily relevant in the real world". Махровых спецов таким не проведешь - производительность СУБД в 1с надо мерить из сторонних бенчмарков и никак иначе!!!

(96) TPC-H оценивает производительность систем принятия решений. Вы же не оцениваете такси по грузоподъемности, а карьерный самосвал по скорости разгона до 100 км/ч.

(97) А какой бенчмарк для измерения производительности СУБД под управлением 1С можно считать идеальным? Или мы говорим о сферическом бенчмарке в вакууме?

(96) Так все же с чем может быть связана разница почти в 50% при записи данных в БД между PostgreSQL и MS SQL?

+ почему параметр fsync никак не влияет на скорость записи? по идее при его отключении скорость должна повышаться?

На больших базах в торговле 10.3 MSSQL однозначно проигрывает PostgreSQL при запросах к большим справочникам номенклатуры при большом количестве пользователей. База PostgreSQL работает под CentOS с оптимальными настройками. В бухгалтерии 1.6 PostgreSQL проигрывает MSSQL. Бухгалтерия 2.0 ведет себя значительно лучше. Одна из странностей - обслуживание базы PostgreSQL (полный вакуум с реиндексацией) позволяют производить нормальное перепроведение по партиям, в случае реиндексации баз встроенными средствами MSSQL такого не наблюдается и приходится производить реиндексацию средствами 1С Предприятия. Обслуживание баз PostgreSQL достаточно простое. Ребутнуть сервер 1с под Linux в терминале очень просто.
Кстати - никто не проводил тесты с PostgreSQL 9.2 в которой значительно повысили производительность?

(101) Лучше не баловаться этим параметром.

(0)Вопрос, как настроен сервер.., разнесен ли SQL и 1С сервер по разным машинам?

(104) нет, не разнесен, все на одной машине.

(105) Выходит что по shared-memory обмен идет, а если поставить без свопа, что бы в оперативе крутилось все

(106) как это поставить без свопа? вроде и так должно все в оперативке крутиться, по крайней мере память занята менее чем на 50%...

(0) Что значит не ахти? У кого тогда производительность лучше чем у MSSQL? И почему не поставил этот сервер БД?

(108) не ахти в том смысле что 36 баллов по шкале оценки это примерно средний показатель. но тут дело наверно уже в железе а не в ПО.

(108) Потому что бесплатный
(108) Ща тож проблема с настройкой, железо: Xeon - 2670(2 проца) 64гб Оперативы, файлы базы лежат на внешнем хранилище
показывает по тестам около 40, база MS SQL, и это не разнесено, когда разносишь до 20-ки не доходит

(110) забыл win2008 b SQL 2005

На Win 2008 (Xeon 2 проца Raid10 6Гб ОЗУ, помяти конечно маловато) получилось работать с такими настройками
max_connections = 50
max_fsm_pages = 204800
deadlock_timeout = 2s

shared_buffers = 32MB
#temp_buffers = 8MB
#work_mem = 1MB
#maintenance_work_mem = 16MB
#fsync = on
#synchronous_commit = on
#full_page_writes = on
#wal_buffers = 64kB    
#checkpoint_segments = 3
#enable_nestloop = on
effective_cache_size = 4136MB
max_locks_per_transaction = 350
escape_string_warning = off
#standard_conforming_strings = off

А так могу еще скинуть линуксовые настройки.

(112) Сколько по тестам Гилева?

(100)(101) Параметры autovacuum в PostgreSQL - проясните, пожалуйста, ситуацию

(112) Win2008 без виртуалок?

(106) shared-memory, если речь о протоколе, начиная с 2005 сиквела только через native client поддерживается. Но локально быстрее ессно. TCP/IP умеет определять локальные обращения.

(113) Не тестировал, но база реальная работает 26гб

(115) без виртуалок, но вариант под Windows сильно проигрывает линуксовому

(118) а пользователей много?

(119) 12-15

(119) на Linux крутилось 30-35

(0)Если б это можно было сделать, никто бы не покупал MS SQL server

(122) Сервер MSSQL покупается из-за нерадивых разработчиков и внедренцев. Например - Рарус.

(123) А еще нужны специалисты обслуживать его.

(102) Ну, если 1С напишет трансляцию своего кода в запросы для PostgreSQL с учетом декларируемых улучшений его работы, то наверное будет и повышение производительности. А так, без разницы.
Кстати, насчет enable_nestloop. С последней версией платформы и последней типовой БГУ можно уже держать включенным, ведомости ОС и амортизации формируются уже каких-нибудь 8-12 мин против бесконечности на более ранних версиях.С отключенным все также секунд 10-15 :) Так что, что-то все же делается.

(125) При переходе с PostgreSQL 8.3 на 8.4 разница была очень существенна в плане реиндексации и полного вакуума (с 4-5 часов до 30-40мин). Думаю что в 9.2 время выполнения транзакции может также существенно уменьшиться раз в 5 даже на автоматической блокировке. По крайне мере очень бы этого хотелось, но к сожалению в ближайшее время не могу проверить.

вот еще нашел сегодня

http://postgresql.leopard.in.ua/

(127) Эта редакция значительно полнее, спасибо. Главное, что про бэкапы расписано :)