Доброго времени суток!
Поставил новую машину под отдельный SQL сервер для 1С77. Сервер не промышленный, а обычная машина Phenom X4 3.4Ghz/8Gb/500 WD Raptor + 1Tb/Windows 2008 R2/SQL Server 2008 R2. Сетка между клиентом и сервером 1Гбит, реально заливал файл - около 70Мб/с. Собственно говоря, для наших задач - 5 человек работает - больше и не надо.
Тестовую базу на 300Мб залил. И проверяю.
Отчеты регламентированные тормозят при обработке заполнения. Тот же отчет ЕСВ. В смысле намного медленнее, чем терминальный DBF вариант. Хотя те же расчеты итогов по датам в ЕСВ просто пролетают в отличие от файлового варианта. Но висит выполняется обработка очень долго, а на файловом очень быстро.
Загрузка в момент выполнения обработок - минимальна - 5-8% проца, памяти отъедает 200Мб sqlserver, винт и не жужжит - молчит вообще.
В чем может быть дело и как решить вопрос?

никто в скуле кормить не обещал, в смысле быстрее

клюшки не умеют работать с SQL, только если через 1с++

(1) Хоть также чтоб было. Чего так тормозят обработки?

1С так работает. Смириться.

(2) через 1с++, который и подключен - обработки переписывать в прямые запросы? :(

Ну есть же хоть какие-то способы? Ведь многие ставили в свое время или даже сейчас стоит SQL Server для 1С77. И явно бухи после тормозных отчетов были недовольны. Должны же быть решения.

(6) на бухов с.ать, поскольку база весом в 40 гиг в файле просто не существует(в основном)

Я просто не пойму во что оно упирается - на серваке все спокойно еле-еле загрузка. В сетку??? Дык что 70Мб/с не хватает? У меня на старом еле-еле вытягивает сейчас в файловом варианте 20-40Мб/сек. Сервак очень старый.

(8) см (4)

(7) не понял. у меня база 300Мб - очень маленькая.

(8) в 7.7 есть отладчик, а в нем - замер производительности

Бухня конечно в этом плане сильно уступает Тису на регистрах, но ускорять тоже можно.

максимум для запросов поставить Запрос.ВключитьSQL(0) но в остальном скуль работает не быстрее, а работает !!! сравнительно дбф - только при больших объемах данных и большом количестве пользователей (впрочем когда дбф вообще перестает работать)

Может тогда терминал поставить на сервер с SQL? Очень не хотелось правда.

(12) У меня ПУБ... забыл сказать ;)

(0) Зачем вам скуль при базе в 300 метров ?

(15) Так один фиг, там где бух итоги, план счетов, тормоза сильнее чем в регистрах.

Выполнял просмотр карточки счета в оборотно-сальдовой ведомости. Даты пролетели быстро. Ну думаю, класс - ДБФ фуфло. А потом выполняется обработка - и висела минуты 3-5. :( :( :(
А в ДБФ - пока эти даты пройдут - тормоза. А обработка - сек 10 и все.
Что за маразм?

Мне вот тоже надо бухню на скуль переводить, дфб уже утомил, то индекс слетает, то кто-то все блокирует не пойми кто. Но с другой стороны скорость работы выше..

(16) задолбали бухи своими индексированиями по 15 мин. и звонками.

(20) Ты с сеткой разберись или терминал поставь. Скуль тебе тут при 5 человеках и 300 метров базы нафиг не надо.

(17) Нормально шустро работают бухитоги в sql. Работали в 30-гиговой базе - проблем не было.

(21) сетка летает.

На sql-сервере категорически не советую использовать стандартные "черные" запросы 1с. Даже выборка лучше, чем черный запрос. А еще лучше конечно прямой запрос 1c++.

(22) бухитоги. Я не знаю - просчет по итогам у меня летает, а в отчетах "выполняется обработка" висит существенно дольше, чем в дбф. Заметил в регламентированных при заполнении и Оборотно-Сальдовой ведомости, когда нужно открыть карточку счета.

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

(25) Если 1с запускать локально на сервере - те же тормоза?

(27) не стоит там 1С-ы. Можно попробовать.

(28) Нужно.. И кстати "черные запросы" как раз могут быть причиной провала в быстродействии, ибо они огромный объем данных могут тупо копировать на клиента через сеть в каталог временных файлов в виде dbf, а уж после их обрабатывать.

(29) а что такое "черные запросы" не врубаюсь?

(26) прислушайся к (13). каждый раз эту доработку не очень сложно сделать

(30) СоздатьОбъект("Запрос")

(31) Запрос.ВключитьSQL(0)
А точно так?
Я же выключаю запрос SQL. Вроде в теме одной здесь наоборот писали: Запрос.ВключитьSQL(1).

(33) по умолчанию, он и так включен

(33)Именно (0)

+34 для неоптимально написанных чОрных запросов, это единственное решение проблемы, хоть и запрос в разы будет медленнее, но он хотя бы выполнится, в некоторых случаях..

(36) дык выполняются запросы. Просто очень долго висит обработка.

(37) дык переписывай..

(22) Что-то вериться с трудом.

ну я не понимаю... что сложно проверить что ли?..
3 минуты надо потратить, давно бы уже сделал и отчитался

(40) к (37)

сам замерял, даже в SQL версии, если 1cv7s.exe запускать на том же сервере, где SQL (ну т.е. например терминал), ускорение 2-3 раза

про файловую всем известно, что в 10+++ раз

Поставил
Запрос.ВключитьSQL(0)
Запрос ясно, что имя переменной, которая используется в СоздатьОбъект("Запрос").

Все также осталось. Может дело не в этих запросах? Дело в том, что в той же оборотно-сальдовой ведомости нет никаких СоздатьОбъект("Запрос"). Там только БИ и запросы по ним. И висит в самом конце на последней дате, а потом сразу за ней обработка висит очень долго.

Может дело в БИ? Просто быстро пробегает
Расчет итогов(обороты) дата1-дата2
Вот я и подумал, что БИ летает.

(43) "Может дело в БИ? Просто быстро пробегает"

Чего гадать, посмотри отладчиком замер производительности.

(44) никогда не пользовался. нашел его.
а что дальше делать? включить и все или еще точки останова надо ставить?

(45) Просто включи.. запусти что тебе надо, а после выключи. Увидишь статистику.

(45) поставить точку останова в при открытии, запустить отчет, при остановке,нажать на часы (включить замер производительности) нажать на продолжить.. потом отжать часы - смотреть на замер .. много думать

(47) Точка останова не обязательна. Замер и без неё работает.

Перепиши запросы на 1С++

ага понял вроде
ну выдал список - только что с ним делать?
например,
ЭтоСовмещение = ?(Сотр.ТипСотрудника.Получить(ДатаНач) = 0, 1, 0);
выполняется 10664 раза (ОГО!!!) занимает 30.7% времени. Ээээ... и как это поменять?
Или
спРасшифровка.Установить(стрКоманда,ССЧ(стрКоманда, ДатаЗначения, Фирма, ЗаМесяц, спРасшифровка));
выполняется 1 раз, но занимает 61.46% времени. И что дальше?

Это все НЕ ЗАПРОСЫ. И как я ЭТО перепишу?

(50) Оёёёй... Это в типовой такой код? Чего в ОСВ делает такое условие.. какое дело бухгалтеру до совместителей?

Обращение к периодическим реквизитам - ТЯЖЕЛАЯ операция. Поменять легко - кэшировать в какой-то таблице уже полученные значения..

А по поводу расшифровки.. смотри, что за функция ССЧ.

(51) кэшировать в таблице полученные значения
с этого места поподробней, пожалуйста :)

ССЧ

Функция ССЧ()      
    //Определяем кол-во постоянных сотрудников
    спКоманда.УдалитьВсе();
    спКоманда.Установить("Фирма",ВыбраннаяФирма);
    спКоманда.Установить("Дата",ДатаВМесяце);
    спКоманда.Установить("ССЧШтатРаботников",1);        
        спКоманда.Установить("КвоИнвалидов",0);
    спКоманда.Установить("Штатных",0);
        ОткрытьФормуМодально("Отчет",спКоманда,КаталогОтчета+"rpGlob.ert");
    ID_1012 = спКоманда.Получить("ССЧШтатРаботников");    
    ID_1121 = спКоманда.Получить("КвоИнвалидов");  
    ID_1130 = спКоманда.Получить("Штатных");    
    Возврат 0;
КонецФункции

спКоманда - это просто список значений

(54) тихий ужас..
Заремь вообще установку расшифровки - один хрен, не пользуются :)))

А константы в скуле (да и не только) - вообще зло.
Можешь, закешировать их в ТЗ..

и потом искать в этой тз..

(57) Да вот только обычные ТЗ - неиндексированные, и поиск в них осуществляется последовательным перебором. Как и в списках значений. Лучше всего подключить 1с++ и использовать объект ИндексированнаяТаблица.

(56) ТЗ - это че? :)

(59) ТаблицаЗначений

И все же странно, что на одном компе - работает быстрее файловой :)
Где узкое место?

вообщем примерно понял
но смущает (61)

(61) Релизы платформы везде одинаковые?

(0) тему всю не читал
ты хочешь сказать, что SQL у тебя работает медленней чем немонопольно больше 1 юзера по сети в DBF ??

(61) Ээээ... где везде? Я пока один тестирую. Бухи отдыхают на старье. :)
(64) опять же за одного юзера и за отчеты говорил и за оборотно-сальдовую

локально на сервере запусти 1с

(65) зачем ты одного юзера сравниваешь если в рабочем режиме у тебя 5юзеров ? на 1м юзере конечно будет летать в дбф

У Автора отчет не ОСВ, а ЕСВ (отчет по единому социальносу взносу).

Возможно написано так, что порождается множество мелких запросов (характерно для ЗиКов и прочей ереси). Могу оптимизировать, почта в личке :)
Пример из жизни - служебный справочник остатков стал заполняться вместо 62.4 сек. за 2.7 сек.

Давно не касался 7.7, но когда сталкивался с отчетом по (тогда еще) ЕСН: именно он в SQL работал в десятки раз медленнее DBF.

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

(69) Именно. Там в цикле запрашиваются значение периодического реквизита на дату. Соптимизировать достаточно легко - сделать кэширование.

С SQL нужно аккуратно кодить. И смотреть по SQL-профайлеру, сколько запросов порождает твой код. Одна из проблем в том, что 1С по любому чиху дёргает хранимую процедуру в SQL и количество обращений к базе может быть просто огромным. Был у меня когда-то, например, один журнал, с дополнительными колонками, показывающими всякие пиктограммы в зависимости от реквизитов документов. Так он, при открытии, делал порядка восьми тысяч вызовов хранимых процедур на сервере. Притом совершенно зря делал, 1Ска обновляла содержимое реквизита документа при передаче его в качестве параметра в функцию.
Оказалось, что вызов МояФункция(Фирма) в колонке журнала вызывает обращение к справочнику фирм, а вызов МояФункция(Контекст) и в функции уже Фирма = Конт.Фирма; проходит без лишнего обращения к базе.

(72) ещё есть прикольное слово ТекущийДокумент()
Как-то давно кто-то комплексную ускорял путём выкашивания из ГМ этой фигни. Проведение док-ов в полтора раза ускорил.

я тут недавно одним вместо
  БИ.ВыполнитьЗапрос(НачМесяца(ДатаДок), ТекущийДокумент(), ...)
написал
  БИ.ВыполнитьЗапрос(, ТекущийДокумент(), ...)
тоже раза в полтора.

Много такой фигни в типовых.

(73) Гм. На первый взгляд ничего криминального. Остановил отладчиком на строчке ТекДокумент = Конт.ТекущийДокумент(). Запустил SQL профайлер. Пошел в отладчике по шагам дальше. Ни Конт.ТекущийДокумент(), ни Конт.Вид() не вызвали обращения к SQL. По всей видимости 1Ска уже закешировала.
Эффективней будет, наверное, ликвидировать все обращения через две и более точки. Типа Конт.Контрагент.ОсновнойДоговор.

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

кстати, для выцеляния нужных фрагментов в профайлере можно делать так:
ЗапросСКЛ.ВыполнитьСкалярный("SELECT 'start'");
...
ЗапросСКЛ.ВыполнитьСкалярный("SELECT 'stop'");

и потом тупо поиск по 'start'

(73) Если не указано значение НачДата, то обороты не считаются, только остатки.