Замер производительности 1С #508804


#0 by Alex_MA
Всем доборго утра! Ветка в продолжении темы: Решил замерить производительность на примере проведения документа "РеализацияТоваровУслуг". Производительность тестировал в трех базах: 1)1С:Предприятие 8.1 (8.1.15.14) ("Управление торговлей", редакция 10.3 (10.3.13.2)) На моем компьютере поднят SQL Server 2005 Standart. Агенты сервера 1С Предприятия: 8.1)C:Program Files1cv81in agent.exe -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files1cv81server" -debug 8.2)C:Program Files1cv828.2.12.80in agent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:Program Files1cv82srvinfo - debug" В процессе отладки и замера производительности было установлено, что львиная доля перепроведения уходит на проведение по партионному учету. Данный модуль выполняется на сервере, о чем нам свидетельствует скриншот проведения в 8.1: Те же самые действия в 8.2 (Совместимость 8.1) Сдесь вопрос: "Почему не показано где выполняется код ? Не вижу сервера" В 8.2 (Без совм.) тоже самое Такое ощущение что все выполняется на клиенте ? Может я что то не так делаю, подскажите. Большое спасибо за внимание.
#1 by чувак
А что, на центр поддержкии 1с упала молния? :)
#2 by Alex_MA
От сюда и грабли наверное долгого перепроведения документов. Код не выносится на сервер
#3 by Alex_MA
что посоветуешь ?
#4 by Alex_MA
Только что позвонил франям, сказали по такому не консультируют
#5 by Alex_MA
up ?
#6 by Alex_MA
up...(
#7 by Живой Ископаемый
"Такое ощущение что все выполняется на клиенте ?" - почему?
#8 by Живой Ископаемый
Вернее давай ты сделаешь такое: Зайдешь в базу локально - на том компе, на котором работает сервер 1С и тоже запустишь проведение этого документа... Время уменьшится?
#9 by Живой Ископаемый
а, стоп - у тебя сервер и СКЛ и клиент во всех трех случаях - локально на твоей машине? Так с чего ты ждешь прироста производительности?
#10 by Злая БаЦЫла
Ну во первых при запуске службы 8.2  "C:Program Files1cv82srvinfo" -debug кавычки перед -debug по этому и может не работать отладка на сервере. И непонятно какая мощьность сервера может железа тупо не хватает. И еще если "На моем компьютере поднят SQL Server 2005 Standart." это уже минус посмотри сколько оперативки свободной... ее просто не MS SQL ее сжирает под чистую. А для нормальной работы рабочих процессов 1С ее нуждо от 1,5 ГБ на один процесс. Короче делай нормальный клиент сервер и все будет нормально.
#11 by Alex_MA
Да СУБД на моей машине, однако, я пробовал подключать БД и с удаленной машины, подсоединяясь ко мне как к серверу. Результат такой же. >>Так с чего ты ждешь прироста производительности? Хотелось бы вернуть ту производительность которая была до перехода на 8.1. Конфигурации под 8.1 и под 8.2 абсолитно одинаковые, так что изменения конфы исключены.
#12 by Alex_MA
сейчас проверю кавычки
#13 by Живой Ископаемый
просто код не будет выполняться на той же железяке просто от того, что он выполняется от имени rphost а не 1св8. Возможны какие-то конечно вариации из-за того что сервер например 64-битный - но это копейки, и их ощутишь только уж при сильно затратной операции.
#14 by Alex_MA
строки агентов все Ок
#15 by Alex_MA
был прав в том отношении, что была не правильная строка отладки для 8.2 Вот правильная: "C:Program Files1cv828.2.12.80in agent.exe" -debug -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:Program Files1cv82srvinfo" Нашлось таки место где программа очень сильно тормозит, вот она А вот тормознутый запрос: ВЫБРАТЬ    СписанныеТовары.НомерСтрокиДокумента КАК НомерСтрокиДокумента,    ПартииТоваровНаСкладах.Номенклатура,    ПартииТоваровНаСкладах.ДокументОприходования КАК ДокументОприходования,    РегистрСведений.СписанныеТовары КАК СписанныеТовары        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(            ИЗ            КОНЕЦ)            И (ПартииТоваровНаСкладах.Склад = СписанныеТовары.Склад ИЛИ ПартииТоваровНаСкладах.Склад = &ПустойСклад)
#16 by Живой Ископаемый
а на 8.1 он стало быть выполняется раз в 10 быстрее?
#17 by Alex_MA
нет, только что заметил закономерность в том, что есть ограниченное кол-во документов, которые тормозят как на 1С 8.1 и на 1С 8.2. Вообщем думаю что проблема не в 8.2, а в самих документах. Большое спасибо за помощь. Ну и запрос тоже не идеален конечно.
#18 by Alex_MA
+ и они находяться в начале месяца, т.е. начал перепроведение и на этом же дне все встало, проверять дальше стал - последующие документы после 5 числа вообще все Ок
#19 by Alex_MA
Вообщем тормоз из за партионного учета. Восставновление последовательности может помочь ?
#20 by Dem1urg
Если очень нужно ускорить или точнее понять из-за чего тормоза попробуй SQL Profiler посмотреть в какой sql запрос это превращается и посмотреть его план. Может где индексов не хватает? Проверь заодно настройки sql базы и наличие заданий по перестроению индексов и обновлению статистики. Настройки tempdb проверь.
#21 by Fragster
я бы смотрел в то место, что у тебя сначала соединение с реальным регистром идет, а потом отбор...
#22 by Fragster
+ перенеси СписанныеТовары во временную таблицу с этим Где СписанныеТовары.Регистратор = &ОсновнойДокумент а потом уже внутренне соединяй. ИМХО результат тот же будет
#23 by Alex_MA
сейчас попробую
#24 by Alex_MA
типа так ? ВЫБРАТЬ    СписанныеТовары.Номенклатура,    РегистрСведений.СписанныеТовары КАК СписанныеТовары    СписанныеТовары КАК СписанныеТовары        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(                        ИЗ
#25 by Fragster
не только. у тебя еще в настройках виртуальной таблицы используется этот  регистр СписанныеТовары
#26 by Alex_MA
Где то неправильно выводит, т.к. запрос выполняется, но выводит null-ы
#27 by Fragster
#28 by Alex_MA
подожди, параметры вирт таблицы все Ок:
#29 by Fragster
зачем мы отбирали данные-то?
#30 by Fragster
еще и выбрать различные можно
#31 by Alex_MA
))) так ч писал, тоже не Ок. Да и к стати, не факт что это будет правильно во втором пакетном запросе. т.к. мы первый запрос ограничили по
#32 by Alex_MA
+ а в исходном запросе в парам. вирт. таблицы беруться все записи по регистратору
#33 by Fragster
правильно все. у нас во втором запросе из регистра списанные товары берутся записи по &ОсновнойДокумент и по &Ссылка
#34 by Alex_MA
Соглашаюсь. Просто знаешь, там в модуле высчитывается строка партии, а у меня не задан псевдоним в запросе. КоличествоОстаток КАК Количество и СтоимостьОстаток КАК Стоимость, такая вот фигня. Так что пардон. Запрос выполняется конечно на порядок быстрее, результат сейчас проверяю.Спасибо за помощь.
#35 by Fragster
с тебя когняк, короче
#36 by Alex_MA
А у тебя как данный запрос стандартный или переписал ?
#37 by Fragster
у меня нету такого запроса вообще. здесь, где я сейчас работаю - вообще нет партионного учета. но всякого УГ полно, которое я счас рефакторю и оптимизирую. а партионный учет внедрять буду, ибо назрела необходимость (правда это только в планах - сначала все текущее нужно в более красивый и быстрый и масштабируемый вид перевести)
#38 by Fragster
+ тут гомункулус из самописки, переписанной из 7.7 неизвестными мастерами + куски из разных типовых наклеены сверху
#39 by Fragster
+ из 7.7 тоже такой же - самописки с приклеенными кускаи из типовых
#40 by vista
Как же так??? Как же тогда переписать запрос? Может быть использовать следующее: set xact_abort on; set no_count on; dbcc showcontig dbcc enable_awe on Как-то так, да? По сути ведь нужно сделать выравнивание extent'ов, оптимизировать структуру GAM, IAM и уменьшить сдвиг в SGAM для минимизации indid до 0, чтобы на плане запросов не было table scan, а побольше было index seek.
#41 by vista
Согласен. Если база - MS SQL, то этот вариант считается наилучшим!!!
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С