Описание проблемы:

Произошло резкое падение скорости проведения док-та "Перемещение товаров". На док-те из одной строки - в 10 раз, на больших документах еще заметнее. При этом, в копии 10-ти дневной давности, на идентичной конфигурации 1С, таких проблем не было. Перед этим я сделал реструктуризацию базы 1С (при этом, она разжимается), а после этого запустил скрипт
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
GO

EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)'
GO

(сжатие средствами SQL). Подобная операция выполнялась уже пять раз и никаких проблем за собой не влекла. При анализе производительности при проведении документа средствами 1С (я не уверен, что можно на 100% доверять этому анализу) выяснилось, что значительная часть времени при проведении документа тратится на запрос к регистру накопления «ПартииТоваровНаСкладахБухгалтерскийУчет». Возможно, что проблема именно с данной таблицей.

Выполненные действия:

Было выполнено обслуживание базы SQL (реиндексация, обновление статистики). Средствами 1С была сделана реструктуризация таблиц базы данных. Это ничего не изменило в существующей проблеме. Возможно, стоит провести проверку логической и физической целостности БД, но пока не было времени. Размер базы 195 гб без сжатия, 43 гб со сжатием. Расположена на сервере 2xXeon E5620, 24 gb ram, диск под базу SSD plextor m5 pro, с железом проблем нет

запрос покажешь?

История умалчивает были измения в коде

вышел из строя идин диск в рэйде.

(0) дык 10 дней назад перемещение не делало проводок, а теперь делает

это учетная политика сменилась и ни какие примочки со стороны ТиИ, dbcc и иже с неми тут не причем

1C 8.2, УПП 1.3.48.2. Место где происходит "затык" полностью типовое. Запрос к регистру "ПартииТоваровНаСкладахБухгалтерскийУчет", потом соединение его с регистром "Списанные товары"

(5)

план запроса приведите

(3) База на одном SSD диске. На другом сервере такая же история
(4) так всю жизнь делало, неужели 5 лет работали с документом при выключенных проводках.

(7)[так всю жизнь делало, неужели 5 лет работали с документом при выключенных проводках.]
ни о чем

возьми перемещения в двух экземплярах базы и сравни движухи

(0)могли слететь индексы добавленные в скулях

(8) ну  и до кучи:
- настройки RLS
- версионирование по Перемещению
- наличие в перемещениях галки УУ

"При этом, в копии 10-ти дневной давности, на идентичной конфигурации 1С, таких проблем не было. ... Подобная операция выполнялась уже пять раз и никаких проблем за собой не влекла. " платформа и конфа те же и такое...
а мерял ты сам это десятикратное замедление?

(0)
Выгрузи базу и создай ее копию на том же сервере 1С, естественно основную не удаляй.
Проверь скорость проведения в этой новой копии.

(0) Я тут недавно поднимал тему - оптимизация производительности УПП. Тот же самый регистр. Проверил план запроса, не было индексов у некоторых измерений, поправил, дало небольшой выигрыш. Знатоки, скажите, а можно ли асинхронно писать движения в регистры (если их насчитывается 19) и даст ли это выигрыш в производительности?

к (11)перезапусти службу сервера 1С. лучше вообще всё железо или хотя бы службы 1С и скуля. потом проверка таблиц, простая модель и шринки базы и файлов. вообще надо смотреть. если память меньше базы можно подождать погонять, как отработает кэшировнаие.

(13)"асинхронно писать " это то чего нам не хватало в 1С. в ут11 скоро будет )))

(10) +1
ну и дежурный вопрос на какую дату рассчитаны итоги по Рг

(8) дельный совет. Но файлы "отчет о движениях" идентичны
(11) Да. 1=ТекущееВремя(). Проведение док-та. 2=ТекВремя(). 1-2= равно времени проведения. А на док-тах из 40-50 строк проведение может идти больше часа.
(12) копия на разных серверах работает одинаково
(14) "проверка таблиц" - ТИИ средствами 1с, все пункты?

(6) Прошу прощения, не знаю как это сделать
(9) Так платформа за этим следит, и при реструктуризации должна вернуть пропавшие индексы?
(10) RLS для полных прав вообще нет. "версионирование по Перемещению" - не понял.

(18) Рг сведений версии объектов

(18)  см. (16)
а далее стоит натянуть на 10 дневной давности копию cf-ник от текущей и замерить производительность

(20) все регистры рассчитаны на 31.01.14. Cf накатывал, без изменений

«ПартииТоваровНаСкладахБухгалтерскийУчет». Возможно, что проблема именно с данной таблицей
проиндексируй там всё что можно

индексы добавленные скулем платформа не восстанавливает

"проверка таблиц" - ТИИ средствами 1с, все пункты - нет проверка скулем на всякий случай скриптом тскл

кстати можно кэш запросов ещё очистить в скулях

вообше интересно было бы увидеть мониторы загруженности сервера виндовго со службой 1С и скульного

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

(21) а теперь стоит рассказать всё,что было сделано,
ибо игра в угадайку форуму быстро наскучивает

что делают скрипты в (0)?

всё таки про RLS ответа нет, версионирование вроде как не должно вызывать тормозов.
(21) значит дело в настройках.

Документы не перестали-ли быть исключительно оперативно проводимыми?

И ещё, если посмотреть в технологический журнал проведение того-же документа приводит к точно таким-же текстам запросов?

подписок не добавилось

?

(0) нужно анализировать план запроса

(22)
> «ПартииТоваровНаСкладахБухгалтерскийУчет». Возможно, что проблема именно с данной таблицей
> проиндексируй там всё что можно
я бы поостерегся давать такие советы не зная причин проблемы

(20) "проиндексируй там всё что можно" как проиндексировать отдельную таблицу? Что именно? Выбрал индекс, нажал Rebuild, это имелось в виду? DBCC CHECKDB не выявил ошибок. "CHECKDB обнаружил 0 ошибок размещения и 0 ошибок согласованности в базе данных" Кэш запросов в скуле чистил, ожидаемо производительность упала на 5%. Сервер общий (скуль и 1С вместе стоят). Вот хронология загрузки при проведении документа за 30 секунд
http://cs409530.vk.me/v409530440/84ed/Xo7dmQtSogg.jpg
http://cs409530.vk.me/v409530440/84f4/-ZnAeHFuuHU.jpg


(24) сжатие базы средствами SQL.  

(25) RLS точно не виноват, была добавлена строка УстановитьПривилегированныйРежим(Истина), не помогло. Версионирование влючено у двух справочников, договора и контрагенты. Возможно, что и в настройках. Сервис - настройки учета, все идентично.

Стесняюсь спросить, но "REBUILD WITH (DATA_COMPRESSION = PAGE)" назачем????????

Чтобы база умещалась на SSD, и чтобы на тестовых серверах бухи могли развлекаться в свое удовольствие, не задумываясь о том, что дисковое пространство кончится ;)
А потом, так на 15% примерно 1С быстрее работает. Проверялось на разных типах документов.

(29) не то
надо поймать в отладчике 1С "длинный запрос", проверит что в двух экземплярах базы он дает 10-кратную разницу

"раздеть" запрос в 1С до примитива, дающего расхождения
поймать запрос сиквельным профайлером

построить план запроса
ликвидировать причину

(32) Спасибо, уже примерно на этом и остановился. Осталось теперь разобраться, как это сделать. Будем искать ;)

(33) любишь ты однако мозго.ёбс.твом заниматься =)

(34) Ага. И торчать на работе, когда все бухают. ;)

Сам запрос выполняется одинаково в двух базах, и в "больной" и в "здоровой", примерно за одну секунду (в консоли запросов).
35% занимает Возврат Запрос.Выполнить().Выгрузить(ОбходРезультатаЗапроса.ПоГруппировкам);
Вот запрос:
http://vk.com/doc8469440_273747388

(36)[надо поймать в отладчике 1С "длинный запрос", проверит что в двух экземплярах базы он дает 10-кратную разницу ]
значит надо таймировать не в консоле иди запрос таки разный

сдается мне что 3.0 от КОРП версии, а у вас обычная ПРОФ версия

(38) не понял

(37) и сам запрос, и параметры к нему, абсолютно идентичны

(39) веткой ошибся

(29)попробуй средствами конфигуратора сначала
подозреваю что проблемы были всегда но тебе о них сообщили сегодня

(42) реиндексацию 1С делал. Проблемы раньше не было, т.к. на 10-ти дневной копии ее нет. Померял время выполнение запроса на большом документе: в рабочей базе 731 секунда, в копии 698. По сути, примерно одинаково. Но уж явно нет разницы в разы.

(36) кому твой запрос со сторону конфигуратора нужен? Нужен текст того запроса который 1С-Предприятие передаст SQL-серверу и нужен это  текст для обоих баз.
Так вот что-бы получить этот текст Технологический Журнал самый тот инструмент (имена таблиц будут непривычные но тут поможет разобраться ПолучитьСтруктуруХраненияБазыДанных()).

(0) а проблемный регистр нормально закрывается? Т.е лишние остатки не весят?

(43)замер производительности рулит
а телепатически - индексы

(0) В общем модуле "УправлениеЗапасамиПартионныйУчет" есть процедуры "ЗаполнитьЗапросПартийНаСкладахБух(Упр/Нал)".
Там в запросе параметры виртуальной таблицы выбираются вложенными запросами из РС "СписанныеТовары".
Можно просто отдельно выполнить эти запросы, выгрузив результат в массив или временную таблицу, и результаты подставить в параметры.
В результате запросы выполняются в десятки раз быстрее.
Походу это из-за того, что SQL не может сформировать нормальный план запроса

(43) потом соединение его с регистром "Списанные товары"

переделай на временную таблицу, заплатка из 10 строк кода, ускорение ~20-30 раз

(47) опередил

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

но лучше индексов добавить.

(50) Добавив индексы, увеличим размер базы (может даже значительно). + их потом еще и обслуживать надо (дефрагментация, реиндексация).
Замену текста запросов можно вынести в свой общий модуль, а в "УправлениеЗапасамиПартионныйУчет" просто заменить строку вызова.
Стильно, модно, молодежно... Всмысле просто, элегантно, легкообновляемо

(36) из запроса:

ВЫБРАТЬ
    ПартииТоваровНаСкладах.ДокументОприходования
    
ПОМЕСТИТЬ ПартииТоваровНаСкладах


собственно тут дело в том, что типизации нет, по этому 1с вставляет ОХЕРЕННЫЙ запрос к методанным. Грабли старые, нельзя времянку делать с нетипизироваными значениями!!!!

(52) переделай на вложеный и будешь удивлен :)

а сабж скорее всего возник из-за партий (их или включили или стало сильно больше)

(52)да если там документы одного вида в конкретной базе встречаются только то можно выбрать из них те которые входят туда в регистре как вариант
(51)скажи ещё что костыли это не наш стиль )))

(50) Сегодня нет движений по регистру - завтра будут
(54) Сегодня не встречаются какие-то документы - завтра начнут их использовать
Мир изменчив...

(55)как временное решение пойдет.

Проблему удалось решить следующим образом: все прикрепленные файлы в справочнике "Хранилище доп. информации" были перенесены во внешнюю базу, после чего удалось выгрузить dt файл. После его загрузки производительность вернулась на прежний уровень. Всем большое спасибо за помощь и советы.

(47) Это всё индивидуально, в текущей УПП переделали на выборку партий во временную таблицу и соединение со списанными товарами. Как я не бился, этот новый вариант на наших данных работает сильно медленней, чем старый без временных таблиц.

(52) Тут не сильно типизация помогает, там всё-таки не "ВсеСсылки".
Меня больше расстраивает повсеместное ДокументСсылка.Проведен, ДокументСсылка.Организация в УПП 1.3 в восстановлении по партиям.

(57)
А как перенес прикрепленные файлы во внешнюю базу?
Можешь поделиться схемой того, как сейчас?
А то тут у одного клиента походу скоро такая же проблема может возникнуть.

(57)ну если только маленькая база набитая г-ном на очень плохом железе с очень малой памятью и скуль полумертвый... хрень какая-то

(58) Можете уточнить, в каком месте базы они это сделали? Аналогичная ситуация с появившимися тормозами в базе.

(0) База к хранилищу подключена? Демонически не обновлялись?

Что то мне подсказывает, что нужно искать "Commit" в таблице Config

(62) Выше уже написано: в общем модуле "УправлениеЗапасамиПартионныйУчет" есть процедуры "ЗаполнитьЗапросПартийНаСкладахБух(Упр/Нал)".
Поменяли уже давненько, на выборку партий во временную таблицу. Заплатка, про которую все говорят, делала наоборот, выборку товаров списанных во временную таблицу.
Уверен, что предполагаемые появившиеся тормоза не из-за изменений этих запросов. Пересчитайте итоги отдельно по партиям.
А вообще сама 1С говорит, что онлайн проведение по партиям - зло, обработка восстановления - добро.

(64) В обработке Восстановления - при нахождении ошибки по партиям - процедура останавливается с текстом ошибки, а в обработке проведения по партиям - нет, при определенных настройках.