AlexNikolskyЕсли ты восстанавливаешь последовательность доков то параллельной работы у тя нет. А значит первое это сделать регламент SQL.
Далее перед запуском процедуры можешь вырубить журнал регистрации (под тормаживает).
в 8.1 есть возможность делать его небольшим...

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

Если запрос написан не оптимально то SQL будет висеть...

СПАСИБО !!! Респект и уважуха потому что мало кто так основательно все напишет!
Может кому ещё сгодится! Но я склоняюсь к тому что не железо а кривые запросы. У мню вначале описана конфига машины. В момент тормозов винты молчат даже не могнут память вся используется именно нагрузка на 1 камень самим сервером сиквела и усе и тишина..
Я как найду обязательно отпишусть вот ещё жду ответ от 1с уже 2 письма отправил. Молчат....

AlexNikolskyЭто статья про регламентные операции.

Тут добавлю что база в симпл перевести либо учись бакапить лог файл.
Из-за размеров его тормозит и существенно. Если настроить регламент то надо убрать у базы авто апдейт статистик (из-за него sql постоянно винтом пашет :( )

Базу tempdb убрать с диска С (по умолчанию она там ставится). Ей желательно отдельный винт.
Вообще микрософт рекомендует.
С под систему
Диск под tempdb который работате очень быстро на чтение и запись.
диск под лог файл с отключенным кэшем (для сохранности данных)
диск(и) под БД
Кстати базу почти сразу перевел в симпл потому что лог получался в 200 гиг :)

AlexNikolskyПредлагаю поступить след образом. В отладчике поставь замер производительности и запусти восстановление последовательности. Подожди пару-тройку часиков. Потом посмотри в замере где время потрачено более всех.

полагаю получишь строки типа: "Запрос.Выполнить();"

потом выложи текст запроса на форум и далее будем думать :)
а еще номер конфы.

Хочу посмотреть что за запросы так sql вешают. Возможно просто из-за отсутствия регламента у тя косячный план запроса получается на SQL. Регламент позволяет SQL выбрать наиболее оптимальный путь для получения данных именно поэтому он так важен.

Поставил замер и проведение суток через 7-20 часов получим данные :\

AlexNikolskyОк будем ждать. Хотя думаю 2-3 часов было бы достаточно для замера...
интересно именно провести сутки потому как основные тормоза на проведении отчетов о продажах. Тормоза ловятся именно на них А они закрываются в осном с 20-00 до 23-15 Вот этот интервал и идет с тормозами и дольше всего.

Роман79Если внимательно прочитать ссылочку, то видно,
что проблема не в 1С, а в SQL...
Тоесть был баг у SQL Server 2000, который описан здесь:
http://support.microsoft.com/?scid=kb;en-us;891553&spid=2852.
Может аналогичная ситуация и здесь вылезла...

А если внимательно почитать здесь, то тут идет разговор о сиквеле 2005 х64 СП2
И тот баг что был в сиквеле 2000 здесь насколько мне известно отсутствует.

Проведение на отметке 22-10 сегодня уже не дождусь... поплелся домой.
Результаты замера завтра с утра.

AlexNikolskyв нашем случае проблема не с сервером приложений.
а в том как выполняются запросы на SQL.
Висит именно SQL. Читай выше.

Поставил замеры
Если УчетнаяПолитика.СписыватьПартииПриПроведенииДокументов Тогда
УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка,
Движения.СписанныеТовары.Выгрузить());

Заняло 95,49% времени проведения (это заняло 12 часов) 65 документов в среднем по 1000 строк, но одна строка может двигать несколько партий.

GennaУ нас схожая проблема.
Расчет итогов по регистрам бухгалтерии на тестовой базе длиться больше трёх суток и когда закончится не известно.
SQL настроен, как надо по всем рекомендациям.
в ActivityMonitor висит INSERT блокировок нет, wait'ов тоже нет
в Windows Task Manager один из процессоров постоянно загружен на 100 %
в SQL Server Profiler периодически проскакивает жуткий запрос от приложения 1СV8 размером более 29.000 байт куча JOIN, GROUP BY, HAVING и вложенных SELECT'ов

Сам запрос во вложении, вернее его часть только гиганский SELECT который и вычисляет итоги на определённую дату (конец месяца)


Железо :

сервер БД

4 XEON двухядерных с поддержкой HT, памяти 10 Гиг, RAID1 2 винта - по ОС и СУБД
RAID5 3 винта - файла данных БД, RAID0 (хотя надо бы сделать RAID10 +2 винта или хотя бы RAID1) 2 винта - логи + темп БД

Софт :

Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) Feb 9 2007 22:47:07 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)

1C8.0 (8.0.16.2) + переделанная конфигурация на базе "Бухгалтерии предприятия 1.5.6.7"

количество субконто на счетах бух. учета увеличено с трех до шести (!)

количество строк в таблицах, используемых для хранения бух. данных:

в таблице движений регистра бухгалтерии более 2.000.000
в таблице занчений субконто регистра бухгалтерии более 19.000.000


Вопрос: как ускорить расчет итогов ?

использование файлового варианта для расчета итогов, уже невозможно (очевидно превышен внутренний лимит). Попытка залить выгрузку из клиент-серверного варианта в файловый вариант заканчивается неудачей (вернее ничем не заканчивается). Загрузка процессора 50% и так несколько дней, пока насильно не убить задачу. А в прошлом месяце всё было проблем с выгрузкой.

возможно есть алтернативные варианты расчета итогов, позволяющие параллельную работу других пользователей в ситеме ?

или как-то порциями по неделям, что ли считать ?

Если позволит размер выгрузи на момент пересчета в файловый вариант!
Оооооочень удивит :)

Сорри не дочитал конец... :(
Мы с тобой товарищи по несчастью...
Жду письмо от 1с
Оперативность настораживает....

pail Genna[quot pail][quot Genna]
Главное меню - Операции - Управление итогами

Регистр Бухгалтерии (РБ) в 8-ке - сам по себе тяжел, еще более тяжелые запросы к нему генерирует движок, и вмешаться в эти запросы на прикладном уровне никак нельзя. Именно поэтому наряду с РБ в конфигурации БП есть значительное число Регистров Накопления (РН). Они используются параллельно с РБ для отдельных (узких, но нагруженных в плане производительности) задач таким образом, что движения в РБ и РН выполняются параллельно, а для получения данных используются РН и запросы к ним.
Можно сказать, что РБ - прежде всего для типовых отчетов, типа ОСВ, а РН - для всего, что при использовании РБ недопустимо тормозит.

Использование у вас в РБ 6-ти субконто еще более усугубило ситуацию.
Наверное, это было нужно для решения каких-то прикладных задач. В таком случае решение следует пересмотреть - в пользу использования специализированных РН в этом решении, вместо дополнительных субконто РБ.
Я как-то делал БП 1.5.6.7 параллельный регистр для 41-го счета - очень нагруженного в той базе. Всей модернизации - небольшой доп. код в модуле РБ Хозрасчетный (для выполнения параллельных движений в спец.РН) и немножко модернизированных запросов для расчета себестоимости при списании.
Результат - проведение Реализации ускорилось более, чем на порядок.

Еще немного поможет перевод вашей базы на движок 8.1
Производительность действительно больше (даже без какого-либ изменения конфигурации) - правда, меньше, чем заявлено 1С, для той базы БП, что я упоминал, выигрыш составил 15%

Снимите розовые очки :) У меня 8.1 в отличие от Genna Трабла таже. ИМХО кривые запросы в сиквел однозначно!