В продолжение v8: После обновления Платформы и SQL база стала работать в 3 раза медленнее!?!
Проблема в разнице скорости перепроведения документов за месяц так и осталась. В файловом варианте в пять раз быстрее, чем в серверном на любом железе. Попытки использования 8.2.13 и ms sql 2000, ТиИ ни к чему не привели. Переключение блокировок на Автоматические незначительно, но ухудшило ситуацию. Замер производительности показал в десятке самых затратных операций в основном запросы. Вот один из "самых".

ВЫБРАТЬ
   Остатки.Счет КАК Счет,
   Остатки.Субконто1 КАК Контрагент,
   Остатки.Субконто2 КАК ДоговорКонтрагента,
   Остатки.Субконто3 КАК ДокументРасчетов,
   ЕСТЬNULL(Остатки.Подразделение, ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка)) КАК Подразделение,
   ВЫБОР
       КОГДА Остатки.Счет.Валютный
           ТОГДА Остатки.ВалютнаяСуммаОстаток * &ЗнакОстатков
       ИНАЧЕ Остатки.СуммаОстаток * &ЗнакОстатков
   КОНЕЦ КАК СуммаВзаиморасчетов,
   Остатки.СуммаОстаток * &ЗнакОстатков КАК СуммаБУ,
   ЕСТЬNULL(Остатки.СуммаНУОстаток, 0) * &ЗнакОстатков КАК СуммаНУ
ИЗ
   РегистрБухгалтерии.Хозрасчетный.Остатки(
           &ГраницаОстатков,
           Счет В (&МассивСчетовРасчетов),
           &ВидыСубконтоРасчетов,
           Организация = &Организация
               И Субконто1 В (&МассивКонтрагентов)
               И Субконто2 В (&МассивДоговоров)) КАК Остатки
ГДЕ
   ВЫБОР
           КОГДА Остатки.Счет.Валютный
               ТОГДА Остатки.ВалютнаяСуммаОстаток * &ЗнакОстатков
           ИНАЧЕ Остатки.СуммаОстаток * &ЗнакОстатков
       КОНЕЦ > 0

ДЛЯ ИЗМЕНЕНИЯ
   РегистрБухгалтерии.Хозрасчетный.Остатки

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
   Остатки.Счет,
   Остатки.Субконто1,
   Остатки.Субконто2,
   НЕОПРЕДЕЛЕНО,
   ЕСТЬNULL(Остатки.Подразделение, ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка)),
   ВЫБОР
       КОГДА Остатки.Счет.Валютный
           ТОГДА Остатки.ВалютнаяСуммаОстаток * &ЗнакОстатков
       ИНАЧЕ Остатки.СуммаОстаток * &ЗнакОстатков
   КОНЕЦ,
   Остатки.СуммаОстаток * &ЗнакОстатков,
   ЕСТЬNULL(Остатки.СуммаНУОстаток, 0) * &ЗнакОстатков
ИЗ
   РегистрБухгалтерии.Хозрасчетный.Остатки(
           &ГраницаОстатков,
           Счет В (&МассивСчетовКонтрагентыДоговоры),
           &ВидыСубконтоКонтрагентыДоговоры,
           Организация = &Организация
               И Субконто1 В (&МассивКонтрагентов)
               И Субконто2 В (&МассивДоговоров)) КАК Остатки
ГДЕ
   ВЫБОР
           КОГДА Остатки.Счет.Валютный
               ТОГДА Остатки.ВалютнаяСуммаОстаток * &ЗнакОстатков
           ИНАЧЕ Остатки.СуммаОстаток * &ЗнакОстатков
       КОНЕЦ > 0

ДЛЯ ИЗМЕНЕНИЯ
   РегистрБухгалтерии.Хозрасчетный.Остатки

Прошу совета у уважаемых коллег, где в запросе узкие места по скорости  и как его можно ускорить?

(0) Это нормально . Скульные базы примерно в три-четыре раза медленнее файловой.

(1) + И вообще с чего вы взяли что скульная база должна работать быстрее или хотя бы так же как файловая?

(1) Пруф или пестабол?

(1) + 1.

Отличные рабочие станции (8 ОЗУ, i5, SSD) дают втрое более быстрый РСВ в УПП, чем отличный сервер в монопольном режиме на SQL.
Перепроведение не замерял, но по ощущениям похоже.

(2) Для рассматриваемого примера, а именно тестирование перепроведения на одном и том же железе в монопольном режиме, я ожидал, что sql будет в 1,2 максимум в 2 раза медленнее. Более выглядит для меня странным. Собственно, в файловом варианте 1С сама реализует что-то вроде sql движка к 1CD. За счет задела под высоко нагруженную работу отдельный sql буде несколько медленнее. Как то так...
(4) Зачем для 1С 8Мб на станции не ясно. Если только RamDisk. Тогда SSD не нужен... А вот если на sql сервере собрать 10 raid на SSD SATA III, то различия в разы на правильных запросах быть не должно!!!

(3) Пруф на личный опыт?

поубивал бы за такие запросы

Друзья,подскажите что можно сделать в базе упп чтобы загрузить 1с по полной программе? Ну перепровести там что-то например. Делать буду на копии. База файловая 2 Гб.

(6) А кто он такой, что бы его личный опыт кого то интересовал? Если у кого то радиус кривизны рук такой, что скуль база теряет в производительности сразу 300-400%, то не стоит обобщать этот опыт на все скуль базы.

(8) Что бы они издохла и уж не поднялась? Ну попробуй добавить штук 10-15 группировок в какой нибудь отчет.

(8)расчет себестоимости?

(7) Типовая Бухгалтерия 2.0.25.5 ОбщийМодуль.УправлениеВзаиморасчетами строка 1659. И там таких много...
(8) Попробуй Поиск ссылок на объекты или Удаление помеченных, хотя это только чтение...

(9) А мы на научной конференции? Или есть мое мнение и неправильное?

(13) Сам то понял что сказал? Это именно NcSteel делает безапелляционные заявления и даже не потрудился никак их доказать. Вот у меня при переходе на скуль не было никакого "в три-четыре раза медленнее файловой" иначе пользователи бы просто отказались работать в такой базе, а, я получил бы неилюзорных звиздюлей. Так, что насчет всех баз и степени нормальности поаккуратнее в следующий раз.

(14) Т.е. твои ярлыки - это так? невинная шалость? Мы же не в секции политика, чтобы ссылками кидаться

Все относительно. Когда у меня народ переходил с файловых размером 300-400 метров - они замечали тормоза. А есть которые переходили с файловых по 5-6 гиг - они говорили кое что стало немного быстрее. Так что если чей-то опыт не совпадает с твоим не спеши обвинять его "пестаболом". Может это просто ты мало видел

(16) +100500
(14) не вижу аргументов
в свою очередь подтвержу что перепроведение документов в разы быстрее на файловой версии

(0) В чем проблема? Кто тебе что обещал? Может, к ним и вопросы?
Кто тебе что должен???

+(17) так что товарищ из (1) совершенно прав в контексте топика

(1) какие базы сравнивал? на 100 пользователей или на 1?

(14) ты вообще не в теме, здесь имеется в виду режим когда в базе один пользователь. Тогда файловая заметно быстрее. А ты вообще про другое говоришь.

(1) КГ/АМ

по заявлению самих 1с - файловая как бы вообще не предназначена для работы. максимум для локальной разработки

(23) пруф?
а то бредовое заявление.
Пользователей 10-15 относительно конфортно на файловой работают. При грамотном администрировании сети.

(24) хз. слова Гончарова

(25) ну если пруфа нет...
согласен, серверный вариант предпочтительнее, но и на файловом вполне можно работать

(21) Скуль база 1С на 100 мегабайт и на 1 пользователя? Иди проспись, алкаш. На скуль базы переводят обычно, когда файловая просто не в состоянии уже работать из за блокировок и тормозов. Потому, что ради двух тёток операторов, заводящих в день полторы накладные никто на скуль версию разорятся не будет. Так, что ещё замедление в пять раз это бугагашеньки просто.
Читайте, что вам умный человек в (22) написал и руки ровняйте

(18) До последнего момента при переходе с файловой на серверные не ощущалось такого замедления. Замедление в 5 раз пока выглядит странным... Интересуюсь мнением коллег. Может кто подскажет с запросом...
(23) Давеча был в одной фирме. Там более 75Гб баз. Все файловые!!! Практически все по сети. Самая большая 10Гб! И люди только отдаленно слышали, что дескать есть такая штука sql...

(28) админ значит грамотный.
Тут у кого-то база была файловая около 40 чтоли гиг. 12 у меня самого в одной конторе крутится

(29) Да никаких чудес. Маленькая сетка и файловый сервер. Работа с базами медленная. Я им для ТиИ предложил перенести временно базу на локальный комп, так они удивлены были, как она быстро может работать...

Ахиллес, первое и последнее предупреждение.

(30) ты сравнил, по сети или локально... вот копия базы, в которой работают 10 человек, по сети - жопа, по терминалу - ничего. в такой же конфе, база даже больше, но в другом узле - ка клиент-сервере (db2 и линукс) - работает раза в 2 быстрее http://wstaw.org/m/2012/03/29/plasma-desktoplq3537.jpg

(27) У меня так. А смысл ставить файловую при наличии скуля?

(33) ну, у меня 60 узлов в РИБ. везде ставить скуль нецелесообразно

(34) Я ухожу от этого. Объемы такие, что криворукая поделка именуемая типовая 1С БП не справляться. Т.е. они за день могут так нагенерировать изменений, что потом приходится 3-4 дня грузит (и это от одно почки). Ибо на каждые 10 зарегистрированных изменений документов 1С регистрирует 150 изменений регистров накопления (причем тупо пустые записи). И соответственно при типовой загрузки каждая запись регистра - это пересчет итога

(30) Файловый вариант + терминал сервер всегда был быстрее. Однако этим решением к сожалению убивается куча другого, в т.ч. надежность и масштабируемость.

P.S. А попробовать линус и постгри? (или дб2). Мы лично на нем остановились.

(0) //где в запросе узкие места по скорости

Профайлер для этого есть, да и вроде встроенный в 1С замер производительности тоже может чего-то выдать. Избегайте в запросах вложение запросов, типа
[code]
ГДЕ
   ВЫБОР
           КОГДА Остатки.Счет.Валютный
               ТОГДА Остатки.ВалютнаяСуммаОстаток * &ЗнакОстатков
           ИНАЧЕ Остатки.СуммаОстаток * &ЗнакОстатков
       КОНЕЦ > 0
[/code]
Через временную таблицы по идее это должно быстрее работать.

(32) Если про (0), то все тестировалось на сервере. Если (28),(30), то там все по сети и пользователи попробовали один раз локально... А вот то, что 25Гб в файловом варианте поворачивается - это любопытно. А сколько, интересно, размер самой большой таблицы?
(36) Про терминалку я думал. Но сейчас в самой большой базе одна таблица уже 2,5Гб. К концу года будет больше 4Гб. Не ляжет ли файловый вариант? Думаю, что всё же серверный. Железо + 1С сервер где-то 127т.р. Лицензионный ms mql на 5 бухгалтеров - 30т.р. (первичка грузится из внешних баз). При таком раскладе 30 могут и найти. Если нет, то постгре. Ну, можно и на db2 посмотреть. Согласен.
(37) Замер производительности 1С на этот запрос и указал... Вложенного запроса в приведенном примере нет. Можно сделать выбор, а на следующем шаге пакета отобрать ненулевые. Попробую... Профайлер для меня пока вновь, но, похоже, без него никуда...

(38) У файлового варианта есть ограничение на размер таблицы, не более 4Гб.
Смотри профайлером, возможно достаточно будет в 1С-ине выстроить дополнительный индекс по какому-либо реквизиту.

Может на самом деле попробовать выбор из условия убрать, заменить его на вал сумма+руб сумма ? Вообще интересно на запрос в профилере посмотреть, что же там тормозит

на sql все регламентные операции выполняются? реиндекс статистика?

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

(39) Спасибо!
(40) Если будет положительный результат, опубликую...
(41) Да, регламентные есть. Я об этом писал в первом посте по ссылке в начале страницы.
(42) В обоих случаях запросы. Просто один переваривается встроенным движком 1С, а второй внешним. Получается, что движок 1С не плох на малых объёмах. Но в нагрузочной среде и на больших таблицах он затыкается. В свою очередь решения, устойчивые к нагрузкам, с малыми объемами не столь скоры оказываются... Странно, что в разы...

(43) на малых объемах существенную роль уже занимает клиент-серверное взаимодействие

(44) Я бы так не сказал. Я тестировал все на одной машине. Замер производительности показал, что время ушло на выполнение (!) запросов. По запросу видно, что на выходе минимум данных и передача между серверами минимальна. То есть затраты, когда работал именно движок. А уж на клиент вообще приходит только результат...

(39) ну сколько можно повторять... Я уже раз- 5 на этом форуме писал:
У файлового варианта НЕТ ОГРАНИЧЕНИЯ на размер ТАБЛИЦЫ, не более 4Гб

(46) Т.е. совсем совсем нет ограничений?

Использование файлового варианта работы 1С:Предприятия 8.0 накладывает ограничения на объем данных, хранимых в информационной базе.

Все данные информационной базы 1С:Предприятия 8.0 хранятся в наборе таблиц. Подробно состав таблиц информационной базы описан в разделе «Размещение данных 1С:Предприятия 8.0».

При использовании файлового варианта работы, данные информационной базы хранятся в одном файле - 1Cv8.1CD. Этот файл имеет специальный формат, поддерживаемый системой 1С:Предприятие 8.0. В частности, все данные, относящиеся к каждой таблице, физически хранятся в трех внутренних файлах:

   файл записей, в котором находятся все записи таблицы, за исключением полей неограниченной длины;
   файл индексов;
   файл значений неограниченной длины (в этом же файле хранятся значения полей, имеющих тип ХранилищеЗначения).

Технологическое ограничение заключается в том, что размер каждого из этих внутренних файлов не может превышать 4 Гб.

(48) ну вот сам себе и ответил)

(49) + все-таки ограничение в 4 Гб и ограничение в возможные 12 Гб - какбы немного разные вещи...

(49) ну вот я надеялся в 8,2 что-то поменяли