Ошибки в ЦУП и способы решения

Очень хорошая и, главное, полезная статья.
Большое спасибо!

Пожалуйста, надеюсь пригодится :)
Мне в свое время очень не хватало такой статьи.
Кстати, все эти ошибки остались и в последней версии ЦУП.

Плюс - уже за самую первую фразу:

Подписался

Почему в нашем аналоге ЦУПа http://www.gilev.ru/querytj/ нет ошибки:


Клиентская часть, собирающая логи тж не использует dll-библиотеку, делает это средствами 1С.

И соответственно рекомендация из статьи:

не требуется, работает везде.

Далее, ошибка

в нашем инструменте http://www.gilev.ru/hardware/ не возникает, так как не используется WMI и системные средства вне 1С. У нас напрямую происходит настройка в самом "мониторе производительности" Windows, который пишет значения в базу данных на MS SQL Server.

Далее, ошибка

не возникает, потому что http://www.gilev.ru/querytj/ вообще не использует V82.COMConnector

Далее, потребности в

в нашем инструменте нет, оптимизацию этого блока мы делаем за Вас.

Если хотите избежать проблем платного 1С:ЦУП, можете использовать бесплатный http://www.gilev.ru/querytj/

Спасибо

Граждане, укажите незрячему, где этот архив?

Порадовала коллекция. Пару грабель видел лбом. =)))

ну и еще немного про цуп

"Пользователь, от имени которого запущен ЦУП". А кто это?

1. Пользователь, под которым зашли в Windows и запустили 1С, подключенного к базе ЦУП.
2. Администратор кластера 1С
3. Владелец SQL-базы
4. Пользователь, от имени которого 1С сервер подключается к исследуемой базе.

2-4 могут быть связаны с учетной записью Windows (причем не обязательно из п1), а могут не связываться.
Учетные записи Windows могут быть локальными, а могут быть доменными.

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

Почему инструкции пишут так, что вопросов больше, чем ответов?

Этот термин используется в описаниях, рекомендациях. Увы, нет полного и толкового описания и не понятно, почему что-то не работает, хотя должно или работает, хотя вроде не должно... Нажимаешь пункт "Инструкция" в настройке, все по пунктам делаешь - не помогает. А то, что нет возможности сохранить незаконченную настройку не укладываетсяч в голове (приходится править конфигурацию, чтобы отключить проверку). Проблемы берутся непонятно откуда и исчезают, непонятно куда (но реже). Вроде настроил, работает, но админ ставит новый сервер или новый SQL и приходится все переустанавливать. С другими базами проблем нет, а с ЦУП - есть.

Запустить удалось, вот только на это ушло полдня (а не 15-20 минут) и самое грустное, что если это понадобится сделать снова - опять может уйти полдня (или больше).

Есть еще одна "бомба" при просмотре статистики
смотрим процедуру ЖурналПоказателей.ПодготовитьДанныеДляПросмотра и видим запрос:
|ВЫБРАТЬ
| *
|ПОМЕСТИТЬ
| ЖурналПоказателей
|ИЗ
| РегистрСведений.ЖурналПоказателей
|ГДЕ
| ИнформационнаяБаза = &ИнформационнаяБаза
|ИНДЕКСИРОВАТЬ ПО
| Период,
| Показатель,
| НомерЗаписи
во временную таблицу помещается весь(!) журнал и чем дольше вы ведете статистику тем больше вы тратите время на её просмотр.
Исправляется просто - добавьте условие И Период МЕЖДУ &НачалоИнтервала И &КонецИнтервала
и установите параметры
Запрос.Параметры.Вставить("НачалоИнтервала", Контекст.НачалоИнтервала()-1);
Запрос.Параметры.Вставить("КонецИнтервала", Контекст.КонецИнтервала()+1);
Второй вариант, если графики не нужны а нужны только данные - используйте обработку из вложения.

Отключать блокировки не хочется, счетчики на английском, в PMU добавлен пользователь, все по инструкции сделали и перепроверили. Что еще может быть, посоветуйте

Здравствуйте!
При настройке ЦУП при включении параметра "Блокировки" возникли проблемы - ошибка 148 ( 0x800007d0: ) не удалось собрать значения счетчиков производительности.
Архитектура сети:
1С сервер запущен под локальным пользователем SRV1CV8, доступ к базе SQL через пользователя "sa", SQL находится на другом компе. ЦУП запускается под доменным пользователем (например "Иванов"). Пользователь Иванов входит в группу "Счетчики производительности", SQL на русском, в код добавил определения счетчиков на русском. К моему сожалению, ошибка использования всё равно есть. Подскажите где ещё копать, отключать "блокировки" не хочется.

При попытке анализа взаимоблокировок получил ошибку в стиле "Ошибка метода ЗаписатьТекст и предложение открыть форму настройки базы. После чего эти замеры намертво зависли в мониторе анализа, не удалялись и не обсчитывались. Убрать смог только с помощью кнопки "Повторить".

Еще какая-то странная проблема - информацию собираю, аналитические показатели выбираю, например анализ запросов, время запросов ставлю 0, получать план запроса - Да. Выполняю замер, минут 6-7, запросы точно есть, около 100 за это время проходит, но после анализа, когда должен показать запросы и их планы, выскакивает окошко с надписью "Анализ проблем на выбранном участке не может быть выполнен. Возможные причины: 1. Список показателей производительности не содержит ни одного аналитического показателя 2. Выбранный интервал просмотра не содержит проблем производительности". Получается просто так посмотреть план запроса им нельзя, только в случае какой-то проблемы? Или у меня что-то не так настроено?

Да, и анализ этих 7 минут замера идет буквально несколько секунд, не дольше пол минуты. Хотя это боевая база.

В тексте журнала, в общем, все есть, а вот в регистры почему-то он эту информацию затягивать не хочет, то ли пути в ТЧ замера найти не может, хотя они туда попадают... Завтра доразбираюсь, в общем.

Засад много возникает, в общем. Пока не приблизился к пониманию. Ставлю галочку. Каждый такт он собирает инфу о запросах. СборЗапросовВключен = Истина. Как только галочку снимаю - он ставит ее в Ложь и удаляет мой замер. А у этого замера в ТЧ хранится путь к технологическому журналу. Соответственно при попытке загрузить пути в ДанныеТЖ - туда не пишется никакой путь, только пустые значения. При попытке загрузить журнал - делается запрос по этому регистру. Но данных там нет. Соответственно в процедуре ЗагрузитьТехнологическийЖурнал() ничего не происходит. Нет данных - нечего обрабатывать, он говорит - проблем производительности нет. Ковыряю дальше, возможно что-то не так понимаю... А у вас в регистрах ДанныеТЖ и Технологический журнал какие данные хранятся? И все ли замеры хранятся или есть удаленные номера?

Возникла похожая проблема, но в конфигуратор еще на залазил, думал с настройками проблема. А тут похоже такая же проблема.
Имеем:
Windows Svr 2012 R2 Standart
MS SQL 2012
Центр управления производительностью, редакция 2.0 (2.0.12.11)
База для тестирования: Стандартный нагрузочный тест (из КИПа)

Все настроено, ошибок нет, логи журнала пишутся. Показатели аналитики добавлены соответственно.
После окончания замера в просмотре получаю ту же ошибку: Нет проблем с производительностью.
Буду рад помочь разобраться.

По моей связке:
Windows Svr 2012 R2 Standart
MS SQL 2012
Центр управления производительностью, редакция 2.0 (2.0.12.11)

В моем случае проблема была в следующем (более детально со скриншотами во вложении к посту)
При обработке данные и записи в РС Технологический журнал вылетала ошибка: "Запись с такими ключевыми полями существует" (дубли при записи).
При анализе таблицы выяснилось, что дубли по полю МоментВремени.
Сделал при записи временный костыль, данные начали записываться нормально.
И форма с анализом открывается без проблем.

Если, честно не знаю, разворачивал его (ЦУП) несколько раз, так же пробовал разворачивать демо базу, подключал к разным базам: УПП (демо), Стандартный нагрузочный тест (из КИПа), к пустой базе с одним заполненным справочником номенклатуры (для нагрузки использовал консоль запросов).
Результаты в каждом случае одни и те же. Тем более по отладки видно, что данные собираются и парсятся, а само сохранение разобранных данных вываливается с ошибками.
Возможные проблемы как я считаю это:
1. Глюк в версии релиза ЦУПа;
2. Проблема в связке Win Server 2012 R2 + MS SQL 2012;
3. Платформа 1С;

Так же возможны проблемы в то случае если используется версия 8.3, не исключено что ЦУП не допилили для работы с новой версией платформы.
ЦУП 2.0.5 или 2.0.7 с 8.2 работает точно без проблем, ну за исключением тех, которые описаны в этой статье :)

Подписался! А после начала курса по Оптимизации .. Ваши посты взлетят от просмотров и плюсов! :)

Я сам сперва смотрел на эти курсы, захотел очень... А потом почитал программу курсов и понял, что за год настраивания ЦКК и ЦУП, анализа данных, переписывания этих конфигураций "под себя" - мне они уже не так много дадут. Да и денег нет. Я долго мучаюсь с ЦУП и ЦКК и еще долго буду, так что опытом делиться вполне готов, будем обсуждать.

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

Спасибо огромное за статью!
Добавлю свой комментарий по ошибке "Counters.cpp : 112 (0xc0000bb8) – Не удалось добавить счетчик производительности". Исправление из архива не помогло, т.к. счетчики в моей локализации Windows называются иначе. Например счетчик количества взаимоблокировок в моей версии - это "Locks:Количество взаимоблокировок в секунду", а не " блокировки:"Количество взаимоблокировок/с" (как в архиве с исправленями). Точное название счетчика нужно смотреть в "Управление компьютером > Производительность > Средства наблюдения > Системный монитор".

Думаю стоит сюда перенести проблему с которой столкнулись на курсе:

Описание: Как водится с ЦУПом - очередная ошибка с правами. У пользователя, под которым запущен сервер 1С:Предприятие с ЦУП, нет прав на локальную папку Temp, в которой разбираются результаты анализа.

Решение: Пользователю, от имени которого запущен сервер 1С с ЦУП, дать полные права на папку Temp

Добрый день коллега. Большое спасибо за статью.

Подскажите, не сталкивались ли со следующей проблемой ЦУП-а:

Имеем:
Windows Server 2008 R2 (64)
MS SQL Server 2008 R2
1C 8.3.4.496 (сервер 86-x64)
ЦУП 2.0.13.10 (но это не важно - проверил на нескольких релизах 1С-ки и ЦУП-а)

Проблема:
Все нормально установилось, подключена база, прекрасно запускается сбор статистики - видно, что данные собираются, ТЖ пухнет прямо на глазах, в нужном каталоге появляются SQL Trace, т.е. все хорошо.
Проблема возникла при попытке проведения анализа - выскочило сообщение "Анализ проблем на выбранном участке не может быть выполнен. Возможные причины: ...."
Смотрю на "Монитор анализа", а там каждый из замеров с восклицательным знаком :( - ошибка "Ошибка при вызове конструктора (COMОбъект)"

Полез отладчиком - все верно - в процедуре ПолучитьComСоединительПриложения() не отрабатывает конструкция Новый COMОбъект(ПолучитьВерсиюCom() + ".COMConnector"), т.е. попытка создать COM-объект V83.COMConnector

Попытка зарегистрировать comcntr.dll проблему не решает (пробовал и 32-хбитную версию regsvr32, и 64-хбитную) - да, записи в реестре есть, но заставить 1С-ку увидеть этот объект - никак.

Причем, что интересно - конструкция Новый COMОбъект(ПолучитьВерсиюCom() + ".Application") отрабатывает на ура - объект создается!

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

Проблема решена.

Для информации (может кого-то убережот от лишнего гемороя): Т.к. сервер 1С - 64-битный, а comcntr.dll - 32, просто зарегистрировать ее через regsvr32 было недостаточно.
Т.е. на клиенте объект COMConnector создавался по той причине, что и клиент и компонента 32-битные.

В рамках фонового задания - объект создается уже вызовом сервера - а тут уже срабатывает следующая пакость - дело в том что на 64-ных ОС сделано разделение реестра, и в зависимости от разрядности вызывающего процесса он получает от ОС разные ветки регистрации - результат сервер не видит зарегистрированную 32-ю компоненту.

Решение проблемы весьма простое - опубликовать данную компоненту как COM+ приложение, т.е. через оснастку "Component Services"
Просто делаем там дополнительную ветку V83COMConnector - и прописываем внутрь нашу dll.

Единственный минус - при обновлении платформы нельзя забывать перепрописать dll из нового релиза, а то предположительно можно получить много сюрпризов.

Все удачи.

Столкнулся еще с одной ошибкой. ЦУП не может обработать результаты анализа одной из баз. С другими базами все нормально. При попытке обработки собранных анализов возникает ошибка "Ошибка при вызове метода контекста (ПолучитьСтруктуруХраненияБазыДанных)". Никто не знает в чем может быть дело?

MSSQL.cpp : 79 ( 0x36b7: The requested lookup key was not found in any active activation context. ) - SQL Server connection failed.

Возникает такая ошибка при регламентном мониторинге. При этом во время настройки соединения проблемы нет. Такое ощущение, что проблема возникает, когда появляется какая-то взаимоблокировка. Все права сделал по инструкции.

MSSQL.cpp : 79 ( 0x36b7: The requested lookup key was not found in any active activation context. )

У меня эта ошибка возникала, когда SQL работал под пользователем LOCAL SERVCE и у него не было прав на запись в папку трассировки. Учитывая, что все описывают данную проблему, как симптом не включенного права на трассировку, долбился в стену долго.

Вот и мои 5 копеек по ошибке Counters.cpp : 112 (0xc0000bb8) – Не удалось добавить счетчик производительности:
при установке 32-битного MS SQL Server на 64-битную Windows счетчики производительности не отображаются в PerfMon и их невозможно добавить из 1С.
"Разгадка кроется в том, что утилита System Monitor (Perfmon), включенная в состав Windows x64 и используемая по умолчанию, также является 64­разрядным приложением. Microsoft не предоставляет возможности собирать информацию от 32­разрядных счетчиков 64­разрядной утилитой System Monitor (Perfmon). Но нет ли у нас и 32­разрядной версии? Да, она присутствует, поделенная на две части, одна из которых слегка замаскирована, а другая скрыта намного глубже!". Более подробно описано здесь

Andreynikus, я застрял на шаге "Трассировка" из-за того, что у меня нет группы SQLServerMSSQLUser$<SERVERNAME>$<INSTANCENAME>. Использую Windows Server 2012 R2 Standart 64x и SQL Server x64. Тут этой группы нет, есть только SQLServer2005SQLBrowserUser$<SERVERNAME>. На другом сервере с Windows Server 2008 R2 Standart x64 и SQL Server 2008 R2 64x эта группа есть. Не знаете в чем может быть причина?

Andreynikus, у меня еще такой вопрос к Вам: если я хочу мониторить 2 разные базы, находящиеся на одном сервере в одном кластере, я могу при настройке указать для них одинаковые папки для хранения логов ТЖ и трассировок?

Коллеги, подскажите пожалуйста куда копать. При настройке ЦУПа ошибок не возникает. Но оперативные данные не собираются. ТЖ не пишется. Хотя при настройке он создавался и удалялся автоматически. Заранее спасибо.

Права processadmin есть. Каталог указал C:\Program Files\1cv8\conf. Права дал группе "ВСЕ" на чтение и на изменение. При проходе мастером настроек logcfg.xm создается и автоматически удаляется. Логи тоже начинают писать, но тоже автоматически удаляются. Мастером настроек проходился раз десять. Уже наизусть вызубрил всю инструкцию)) Так же пытался указать не локальный каталог, а сетевой. Проблема осталась та же. Мастер настроек проходит без проблем, а оперативных данных нет(

Пытался подкидывать файл конфига(logcfg.xml), который создавался при проходе мастером настроек. Логи начали писаться, но ЦУП их не обрабатывает.
Так же организовал запуск службы 1с и службы sql под одним и тем же пользователем. Под этим же пользователем запускал и ЦУП. Но это не помогло.

Кстати, так же не создаются трассировки. В мастере настроек они создавались без проблем. Пытался цуп настроить к различным базам(к тестовой, к боевой) проблема одна и та же. Нет оперативных данных.

По поводу ошибки ЦУП при настройке:

Counters.cpp : 112 (0xc0000bb8) – Не удалось добавить счетчик производительности.

Долго бился, в итоге в отладке посмотрел на имя счетчика и меня смутило наличие в начале имени "\\localhost". В общем в коде модуля (общий модуль КипВнешнийКомпонент, функция ВыполнитьМетод) сделал удаление этой строки, чтобы счетчик выглядел как "\SQLServer:Locks(_Total)\Number of Deadlocks/sec", а не "\\localhost\SQLServer:Locks(_Total)\Number of Deadlocks/sec".
В итоге все заработало!
Решения проблемы в сети не нашел, поэтому делюсь. Может тоже кому-то пригодится.

Доброго дня, Коллеги.
Периодически, при анализе ожиданий на блокировках, возникает ошибка вида
{ОбщийМодуль.СтруктураМетаданных.Модуль(207)}: Не найдено имя таблицы 1С для 'Correspond=0 Splitter=0 Account=25:9ae320d5e1503f5a4c3421b79a621088 ExtDimension1=128:9c55003048bce18611dfdc2c6da892d8 ExtDimension2=85:8e68000c294e5b6c11e2cd9f8b3404dc Fld1329=169:949d01e374c042084a4970ffabb89a02 Fld1330=Null'
Тестирование и исправление базы не помогло.
Подскажите пожалуйста в какую сторону копать?

Коллеги, столкнулся с такой проблемой. Собираю трассу ЦУПом, блокировки поймал. Начинается анализ и... сильно задумывается. На несколько часов, а то и суток. Обычно нет возможности дождаться конца анализа.

"Виснет" в общем модуле "АнализБлокировок1С" на разделении строк блокировок:
ВсеБлокировки = КипОбщий.РазделитьСтрок('нашиблокировки", ",")

то есть, из-за обилия блокировок, он не может их оперативно разделить. В какую сторону дальше искать для быстрого анализа?
Трасса 2-3 минуты

На скриншоте анализ висит уже 12 часов