База в SQL работает медленнее файловой - как увеличить производительность?
Раньше работали в БП 8.2 через терминал 6 пользователей, работа шла часто с торможением, особенно при одновременном проведении большого количества документов и при формировании больших отчетов.
Купили лицензию серверную, делали базу в PostgreSQL, пользователи теперь работают не через терминал, т.е. платформа установлена на локальные машины (толстый клиент). На тонкий еще не перешли, т.к. интерфейс не доработан (БП дописанная, поэтому все то, что не было предусмотрено стандартной конфигурацией, нужно дорабатывать под тонкого клиента). Так вот, работа существенно замедлилась, даже обычные оборотки формируются значительно дольше! А ожидалось обратное. Что делать?

никто не говорил что SQL быстрей файловой. Он как цезарь, делает 2 дела, когда файловая только одно

а, тут ещё и постгри, тогда аминь

(2) почему?

(3) аминь фразе "А ожидалось обратное". Кто сказал что будет быстрее то? кто этот диверсант?

(3) потому что посгре - это под(д)елка для студентов, а не для серьёзной работы.

Делай замеры и правь узкие места. SQL не для скорости, а для надежности и ровной работе

есть конечно вариант что мы просто не умеем готовить постгри, но я не слышал даже что кто-то смог, чтоб он летал

(4) да постоянно  говорится, что если база большая и больше 5 пользователей - "переходите на сервер"

(6) как это делать?

(5) то есть, даже тонкий клиент не поможет?

(8) Правду говорят, но переходи не для скорости, а потому что файловая начинает "сыпаться" при больших объемах

В постгресе можно сделать один хак, который не даст ему беспредельно тупить, однако, в целом производительность может снизиться. Это установка enable_nestloop=false в postgresql.conf, попробуй - может понравится.

(5) Не соглашусь. Хотя можно раздуть стотыщ постов вокруг определения "серьезная работа".
(7) По опыту, производительность в 1С несколько хуже, чем в MSSQL на аналогичной конфигурации. Но со стабильностью и надежностью проблем не наблюдается.
(12) Чо-та мне этот хак нифига не помог на тяжелых отчетах. Ежели у кого статистика криво собирается, тому может и помогает.

(12) это как - тупить не позволит, но производительность снизится? зачем тогда?

(13) Мне на ЗУПе помог в своё время. Правда, всё равно потом перешли на MSSQL Express 2008 r2, его и рекомендую топик-стартеру..

(14) Некоторые запросы в 1с перестанут дико тупить, грузя процессор сервера на 100%. Это касается джойнов с подзапросами, в первую очередь.

(15) ИМХО, он может помочь только при явных косяках оптимизатора запроса. А оптимизатор чаще всего косячит из-за неактуальной/недостаточной статистики. А может, это предание передается со старых версий пострги, где была какая-то проблема с этим.

(17) Да нет, не на таких уж и старых версиях. Пару лет назад реально "кадровая статистика организаций" формировалась без этого хака минут 10, с ним - за секунды..

Заезженная тема

Парни вы реально в дебри ударились, статистика, оптимизатор запроса, если человек спрашивает, почему тупит, поставив постгри и не прочитав статьи про работу 1с и постгри. Гугл на работе отключили, сразу на мистофорум тему создавать.
Вот первая ссылка поиска: http://1c-remote.ru/nastroika_postgre_dlya_1c.html

(20) Весь этот тонкий тюнинг в большинстве случаев бесполезен для ситуации, описанной топик-стартером..

(18) Ну дык может, опять же, в статистике дело было? Там же и частота и "глубина" обсчета статистики регулируется. Для отчетов 1С лучше собирать чаще и глубже.
(21) Да ладно. Какой еще тонкий тюнинг? Настройки постгри из коробки вообще не рассчитаны на продакшн. Его коробочные настройки - это типа демо-версия для запуска на самой дохлой машине.

Де Факто
1. файловая быстрей, но нестабильна, не паралельна.
2. MS SQL - наше всё, ибо под него в первую очередь затачивается платформа 1с, более стабильно, паралельно
3. Постгри - более стаблильно, но не паралельно (емнип по описаниям на сайте 1с)

(23) насчет "более стабильно" не соглашусь. Два раза сталкивался с падением базы на постгри при внезапном отключении электричества (дада, знаю, на ИБП экономят).

(22) Пофиг. Статистику буквально прямо перед запросом делал. Там нюанс в том, что когда делается джойн с подзапросом - при этом неявно создаются временные таблицы, и вот их объем оптимизатор оценивает неверно, считая что они мелкие и их можно нестедлупить.

(23) Управляемые блокировки - параллельно.
В минусах:
- несколько хуже производительность
- необходимо курить маны
- хуже околоадминский инструментарий
- несколько хуже поддержка, в т.ч. от 1С (периодически всплывают проблемы, которые не всплывают в MSSQL и которые 1С потом фиксит)
Короче, имеет смысл, только если критична экономия на лицензиях. На MS, безусловно, жить проще.
(24) Скорее всего, fsync=off ставили для увеличения производительности на запись. А там черным по белому написано, что в этом случае велик риск краха при сбое питания.

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

да не кипятитесь, с отрывом от реальной ситуации - это просто набор рекомендаций, тестить реально надо на примере

(27) Разумеется, всё зависит от реальных данных. У меня ускорило значительно, и расчет зарплаты, и отчеты, и формирование ЕСН ускорились в разы.

(28) Ну да, про тот же сервер(физический) еще никто ничего не знает. Может там и MS SQL как мертвому припарка...