Тормозит УТ+CRM

А сколько теперь по времени открываются типовые формы? Контрагенты, Номенклатура, типовые документы.

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

Если скрыть нижнюю панель информации в форме списка Партнеров - открывается быстрее или нет?

Валерий, скорее всего проблема в настройке системного ПО, а так же "железа" или же нехватке аппаратных мощностей. Давайте попробуем разобраться:

Насколько я Вас понял базы в клиент-серверном режиме работы и в качестве сервера 1С, баз данных и терминального используется один и тот же физический сервер?

Кэширование явно присутствует ... первое открытие форм справочников и форм элементов проходит значительно дольше, чем последующие...
Отсюда вопрос - кэшируются какие данные? где кэшируются? непосредственно в клиентской сесии? где-то на сервере?
может можно каким-то регламентным заданием их кэшировать?

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

На мой взгляд аномальная деградация производительности для базы с 4 пользователями. Скорее всего сильный вклад дает именно оборудование и настройки ПО.
Можете ответить по конфигурации оборудования (вопрос выше), если, конечно не секрет.

Добрый день, Андрей!

Пользователей в среднем работает 15-20.
Размер базы - около 13 ГБ
В базе, на сегодняшний день используется только блок CRM, ведется база клиентов, создаются события, задачи. Используется встроенный почтовый клиент.
Режим работы базы клиент-серверный.
Сервер баз данных и сервер приложения разнесены на разные машины.
Пользователи работают в тонких клиентах с терминального сервера.

Сервер БД (текущий):
Один четырехядерный Intel Xeon E5620 2,4 ГГЦ, 12 ГБ ОЗУ, RAID 5
Windows 2008 R2 SP1
SQL 2008 R2 x64 (верия 10.50.1600.1)

Сервер приложений 1С:
Один четырехядерный Intel Xeon E5620 2,4 ГГЦ, 8 ГБ ОЗУ, RAID 5
Windows 2008 R2 SP1
Платформа 1С x64 версия 8.3.4.465

Сервер терминалов:
Два четырехядерных Intel Xeon E5-2407 2,2 ГГЦ, 32 Гб ОЗУ, RAID 5
Windows 2008 R2 SP1

Сеть между всеми этими серверами везде 1 Гбит.

По проведенным экспериментам можно сделать следующие заключения:
1. Время задержки при открытии форм не зависит от количества работающих пользователей. Даже с одним пользователем все тормозит.
2. На типовой торговле (демо-база) релиза 11.1.15.16 все летает.
3. На демо-базе УТи ВСК релиза 2.0.6.2 тормоза присутствуют, но в два раза меньше, чем на нашей рабочей базе.
4. Работа под полными правами незначительно ускоряет процесс открытия.

Да, сервера - "виртуалки". На одном и том же физическом сервере. Используется VMware.
Скорость винтов - 7200.

Винты нам тоже не нравятся)))
Достались в наследство...
Как и VMware...

Если можно, то чуть подробнее про разнесение серверов БД и 1С. Вроде бы раньше считалось их разнесение по разным машинам кошерным)))
Если есть причины, по которым их лучше держать на одной машине, то мы с удовольствием их обсудили бы... тем более, что сейчас планируем закупать физический сервер под это...

В качестве ключевой операции можно выбрать открытие формы списка или формы элемента справочника "Партнеры".

Есть более волнующая операция - открытие формы документа "ЭлектронноеПисьмоВходящее" и создание нового документа "ЭлектронноеПисьмоИсходящее" при ответе и пересылке...
Но, насколько, я понял тут проблемы в платформе...
Так что - справочник Партнеры и его формы...

Планируем отказаться от виртуализации. Теперь задумаемся о том, чтобы сервера БД и 1С поставить на одну физическую машину.
Планируется увеличение количества пользователей до 50-60...

Да мы - только за! Тут я, собственно, опирался на информацию:



Во вложении результаты запросов.

Очистка процедурного кэша производится раз в неделю.

Собрали трассировки на тестовой базе с отключенными регламентными заданиями и одним пользователем с полными правами. Результаты во вложении.

Владимир,
в работе SQL я не увидел, каких либо проблем в виде "тяжелых" запросов (запросов выполняющихся долго). По трассировкам видно, что при исполнении всех (кроме «ответа на электронное письмо») операций сервер 1С многократно обращается (через СУБД MS SQL) к базе данных для получения различной информации. Таких запросов очень много, но все они выполняются практически мгновенно (исполнение каждого длится в среднем по 1-3 мс). Эти запросы (несмотря на их количество), не являются источником низкой производительности.

В части операции «ответ на электронное письмо» 1С к БД практически не обращается за информацией, а это значит что львиная доля трудозатрат не на стороне БД.

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

Следующий шаг – более детальный анализ замеров времени собранных на стороне 1С. Вероятно, получится найти временное решение путем корректировки кода. Например, снижение количества обменов данными между клиентскими машинами и сервером 1С, изменение алгоритмов расчета на более производительные.

Еще я бы всерьез задумался об отказе от разделения серверов 1С и БД (Вы итак стоите перед движением в этом направлении).

Теперь насчет использования памяти.
Теперь у Вас есть запрос, который позволяет увидеть, чем в данный момент занята ОЗУ сервера БД. Помониторьте какое-то время состояние памяти накануне выполнения регламентной операции по очистке процедурного кэша.
Если «SQL Plans» отнимает более 15-20% от всей памяти выделенной СУБД это не очень рациональное использование памяти. В таком случае запустите запрос, который показывает, какими именно планами заполнена память (в моем предыдущем сообщении). Например, видим такой результат:
http://www.radikal.ru
Обратите внимание на первую строчку. Если вы видите, что в памяти хранится много «adhoc» запросов, которые выполняются однократно (т.е. перед выполнением формируется план, сохраняется в памяти, но больше этот план не используется и лежит в памяти), необходимо включить в MS SQL настройку «Optimize for adhoc workloads». Это заставит SQL сохранять в памяти планы, только если запрос выполняется 2 и более раз. На примере вы можете увидеть, что под «adhoc» запросы в памяти выделено около 2ГБ, при этом в памяти хранится 19120 планов, для запросов которые выполнялись однократно. Эти планы занимают 1,2 ГБ из 2ГБ, при этом ценности никакой не несут (план ценен, если используется несколько раз).
Если же основное место занято «Prepared» запросами:
http://www.radikal.ru
Как у Вас (одноразовые планы adhoc запросов занимают всего 54мб), но процедурный кеш все равно занимает большой объем ОЗУ, следует увеличить частоту очистки процедурного кеша (с обязательным предварительным перестроением статистики). Посмотрите насколько он разрастается за один, два рабочих дня, сколько памяти у Вас остается в состоянии "Free memory". Лучше когда СУБД имеет запас свободной памяти - это снизит риск резкой деградации производительности. Когда, например срочно требуется память, но доставать ее приходится за счет удаления из памяти/считай кэша часто использующихся пользователями данных, а значит эти данные при необходимости будут читаться с диска (что ощутимо медленнее памяти, особенно для 7200RTM).