Поставил 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.

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

+(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) Эта редакция значительно полнее, спасибо. Главное, что про бэкапы расписано :)