Г-да, добрый день.
Возникла проблема, над решением которой бьюсь уже 2-ю неделю.
Ситуация следующая:
Имеется SQL база УТ 10.3 (размерность около 17Gb)
MSQL 2008, 1с на терминальном сервере.
около 20 пользователей.
При входе в определённый вид документа (Н.: Поступление товаров, Реализация и пр.) у пользователя процесс 1cv8.exe начинает занимать 25% проц. времени. Путём нехитрых вычислений получаем, что 4 пользователя загружают проц работой по самое небалуйся.

Выполненные работы
1) Установка новой тех. платформы. Не помогло. Перепробованы порядка 7 релизов. Ситуация сохраняется.
2) Чистка кэша(сервера/пользователей). Ноль эмоций.
3) Тестирование и исправление, реиндексация и проч. То же самое.
4) Анализ ТЖ не выявил рекурсивных функций. Все работает в том же режиме. Да и не могло быть иначе, никаких доработок в ближайшее время не было.
5) Снос Касперского так же не дал результата.

Ещё небольшие соображения по этому поводу.
1)Тормоза начались 18.03. За день до этого было произведено обновление винды (Server 2008 r2). Админы снесли установленные обновления и это тоже ситуацию не разрешило.(чуть ранее, где-то неделю назад, был перенос сервера клонированием, но проблемы появились позже)
2) Проблемной является только одна база. Остальные таких нагрузок на процессор на дают.
3) Ставился тестовый сервер на котором проверялась проблемная база. Там проблем с нагрузкой нет.
4) Файловый вариант этой базы так же даёт тормоза.

Полагаю, что следующее действие - переустановка винды. Но возможно у кого-то будут ещё догадки по данной ситуации.

(0)
Переустановить базу? Создать новую, загрузить в нее инфу из старой

Пробовал. И в файловом. И в кл-серверном варианте.

(0) А кода никакого не исполняется при этом? Может регламентное задание что-то не так делает?
Вообще, конфа типовая? Если нетиповая - какие-то доработки в ней есть?

+(3) Какие-то доработки в этом документе, в смысле...

Нет. Регламентные специально все убрал.
Конфа нетиповая, но до момента обновления винды все работало как часы.

А что? Должно быть иначе? Я всегда думал - это норма.

(6) Загрузка на 100%. Не. Это не норма.

(4) В некоторых документах есть доработки, в некоторых нет. Но опять суть дела это не меняет. Последняя доработка производилась месяца 2-3 назад. Проблемы начались только 1.5 недели назад.

(0) Замер производительности что показывает?

была у меня такая фигня на 8.3.5.1389
после обновления на 1443 прошло

Для конкретного документа? (9)

(8) >При входе в определённый вид документа (Н.: Поступление товаров, Реализация и пр.) у пользователя процесс 1cv8.exe начинает занимать 25% проц. времени.
Я об этом. Если это происходит и в типовых, и в нетиповых документах, то надо смотреть, исполняется ли при этом код на встроенном языке. Если да - грешить на данные, если нет - на платформу. Кстати, версию последней ты не озвучил.

(10) Сейчас 8.3.5.1482

(0) Попробуй просто открыть конфигуратор и поправить код :)

(12) Сейчас попробую проверить. Текущая в (13)

(14) Это очень дельный совет. Но, полагаю, он не поможет.

Вообще, то, что доработки производились давно - не показатель. Данные-то менялись со временем, возможно, возникла какая-то непротестированная ситуация, ведущая к такой проблеме. Больше сказать не могу, основываясь на таких исходных данных.

(11) Когда загрузка 25%.

(17) В том то и дело. Загрузка одинакова и для доработанных документов и для недоработанных. Общие модули не менялись.

(19) А ты тупо открой конфигуратор и замерь производительность :)

...может чего удивит...

Как вариант, можно почистить КЭШ и так же очистить хранилище настроек :)

Замер производительности, что говорит?

(21) У него религия не позволяет :)

(19) Без конкретики тут масса вариантов, для начала, ещё раз говорю - надо проверить, исполняется ли при аномальной загрузке процессора код на встроенном языке.

(18) Когда пользователь входит в документ (не в список документов). Проблема характерна не для всех документов. Н.: открытие документа "Установка цен номенклатуры" не даёт нагрузку. В то же время открытие "Поступление товаров и услуг" загружает на описанные выше 25%

(23) Погодите. in process.

(24)Выполняется какой то код, который грузит проц. Замер производительности ответит на вопрос какой, но почему ты его до сих пор не запустил?

(24) Дык смотри, какой код выполняется и сколько по времени - там и причина тормозов. В противном случае проблема глубже, чем на уровне кода, но чаще всего это код 1С.

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

-"Ставился тестовый сервер на котором проверялась проблемная база. Там проблем с нагрузкой нет"
Следовательно Переустановить платформу (предварительно почистив все старые остатки от предыдущей)

(29) Собственно я этим 7 раз занимался. Были перепробованы варианты и ниже и выше. (в т.ч. и последняя на сегодняшний момент)

(28) По замеру поступления товаров (при открытии). Максимально по времени (3 с) загрузка вн. обработки торгового оборудования. Все остальные процедуры менее секунды. Но опять-таки это было и ранее. Если нужна конкретика по процедурам, спрашивайте. Сейчас проверю ещё доработанный документ.

(28) По доработанному, все прошло еще быстрее. Максимальное время на процедуру - 0.2 сек.

Помимо кэша пользователей/сервера, где ещё может сохраняться "косячная" информация, которая в последующем будет неправильно интерпретироваться 1с-кой?

(31) Поставь профайлер, посмотри, какие участки кода платформы выполняются чаще всего.

ОбновлениеОтображения()

(35) В котором выполняется действие, приводящее к обновлению отображения.

(35) +1, очень похоже. Но при закрытии дока это должно сходить на нет. Я не понял, у автора так, или нет.

(35) Проверил на поступлении. Менее секунды на "всё про всё"

(38) При закрытии нагрузка сходит на 0. Но собственно это было в условии.

На вирусы проверял? )

(39) Стопудово (35).

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

Есть правда ещё вариант, но это уже танцы с бубном. Я наблюдал загадочные тормоза при обновлении формы на двух почти идентичных компах. Решилось обновлением драйвера видеокарты.
Вопрос - если базу запустить не в терминале - всё то же самое?

(35) Для доработанного обновление отображения пролетело за 0.2 сек

(43) Айн момент. Попробую.

Совершенно непонятно:
1. Сколько времени открывается форма,
2. загрузка проца сохраняется после открытия формы?
3. Код который выполняется в момент полной загрузки проанализирован на предмет, не может ли он грузить проц.
4. Была ли попытка, весь код который попал в замер закомментировать, если была то к чему привело, если не было то почему?
Можно попробовать убрать форму как основную, пусть платформа сама сгенерит, без единой строчки кода форму документа, если там тормозов не будет, искать код который тормозит.

Профайлер уже предлагали?

Клиент 1С, как известно, однопоточный. Загрузка обшая в 25% означает, что один поток грузит одно ядро на 100%, то есть где-то крутится бесконечный цикл.

Очень вероятно, что это дрова вашего торгового оборудования. Попробуйте отключить.

(43) Не в терминале летает. Какие возможны дальнейшие действия?

(46)
1) Для поступления около 4 сек (при первом открытии и получении экземпляра ТО), менее секунды для последующих
2) Да
3) Проверен код на обновлении отображения. Времени не много, все процедуры менее 0.2 сек. Посторонних не обнаружено.
4) Зачем? Если документ открывается/обновляется за то же время как и раньше. Что это даст? Ну получу я не 1 сек, а 0.2, закомментировав участок. Вывод - я убрал процедуру соответственно на 0.8 сек ускорилось время открытия/обновления документа.

(49)Какой то код грузит проц. Если это код 1С убирая код который засветился в замере производительности можно найти где проблема. Если это он. Да с драйверами ТО тоже было много разных чудес, я их выключаю в первую очередь.

(48) Опаньки. Тогда я бы копал в сторону (47), возможно, звёзды сошлись неправильно, и драйвер торгового оборудования кошмарит терминальный сервер. В любом случае, проблема не непосредственно в 1С, а в её работе в терминале. Тут прежде всего в голову приходит ТО и обновления винды(не только на сервере, но и на клиентах).

(51) Меня обновления и смущают. Администратор сообщил, что снёс обновления установленные за день до начала тормозов. С ТО сейчас посмотрю.

В (46) человек уже даже подумал за Вас.

(53) Это не помогло. Проехали.

(52) ТО выключил, проблемы сохранились.

(46) Он не программист. Он просто систем. Администратор :)

(56) Уже сказано было выше. Проверялись процедуры открытия/обновления отображения. Максимальное время открытия - 5 сек. при первом открытии (получение объекта ТО), после - открывались без проблем. Что-нибудь сами по делу сможете сказать? 2 ваших поста - желание пошутить.

(57) Смотреть в сторону Хранилище Общих настроек :)

+(57) Вы ентого зверька тоже проанализировали?
К КЭШ-у оно не относится. Хранится в самой БД.

(59) Если вы имеете ввиду ТО, то описал выше. С отключенным ТО наблюдаются те же самые проблемы.

(58) ??? если не ошибаюсь "хранилище настроек" - объект конфигурации. Соответственно, при запуске на стороннем сервере (в случае проблем с хранилищем) должны наблюдаться те же проблемы. Поправьте меня если это не так. Может быть действительно у меня имеются пробелы в знаниях.

(61) Давай я подключусь, гляну

(62) Какие варианты подключения?

(63) team

icq: 374-881-272

Проблема решена.
Спасибо   "H A D G E H O G s" за оперативное подключение и помощь.
Проблема была в драйвере ТСД. По всей видимости текущие обновления системы его не воспринимают должным образом. Именно драйвер я и упустил из виду. Всё остальное было лишними телодвижениями.


(51) (47) (50) Вы были правы.
(60) Если вы имели ввиду ТО, то - мои извинения.