Эксперт - это человек, совершивший все возможные ошибки в очень узкой области.
Часто приходится работать с ЦУП (Центр Управления Производительностью), в итоге наступил, наверное, на все грабли, какие только возможно. Представляю вашему вниманию список частых (и не очень) ошибок в ЦУП и способы их решения.
90% проблем с ЦУП возникает из-за неверной настройки, прав доступа, по вине администраторов и т.д.
Здесь же приведены как раз остальные 10%, т.е. ошибки в коде ЦУП и прочие ситуации, которые возникают, даже если все настроено правильно.
Точка входа в процедуру PdhAddEnglishCounterW не найдена в библиотеке DLL pdh.dll
Клиентская часть, собирающая логи тж не использует dll-библиотеку, делает это средствами 1С.
И соответственно рекомендация из статьи:
Использовать ОС не ниже Windows Vista
не требуется, работает везде.
Далее, ошибка
Counters.cpp : 112 (0xc0000bb8) – Не удалось добавить счетчик производительности
в нашем инструменте http://www.gilev.ru/hardware/ не возникает, так как не используется WMI и системные средства вне 1С. У нас напрямую происходит настройка в самом "мониторе производительности" Windows, который пишет значения в базу данных на MS SQL Server.
Далее, ошибка
Ошибка аутентификации при попытке входа в базу ЦУП в терминале, на отдельной машине все запускается и ошибки нет
8.
Gilev.Vyacheslav
187212.09.13 23:22 Сейчас в теме
(7) нам любят задавать вопросы типа "а чем вы лучше?", пока не попробуешь, не узнаешь. При чем не буду говорить, что у нас все идеально, но постоянно занимаемся улучшением. Мы этим инструментом пользуемся сами каждый день, это лучшая гарантия имхо.
...Измененные функции "ИмяСчетчикаКоличествоВзаимоблокировокMSSQL" и "ИмяСчетчикаКоличествоОжиданийMSSQL" есть в архиве.
...заменить код функции «ПодготовитьБлокировки», есть в архиве.
...коде процедуры «ПодготовитьПредпологаемыхВиновников», исправленная процедура есть в архиве
(13) Gilev.Vyacheslav,
Если Вы намекаете на то, что ЦУП не анализирует дедлоки на управляемых блокировках, то об этом сказано в документации.
Или здесь что-то другое имеется ввиду?
"Пользователь, от имени которого запущен ЦУП". А кто это?
1. Пользователь, под которым зашли в Windows и запустили 1С, подключенного к базе ЦУП.
2. Администратор кластера 1С
3. Владелец SQL-базы
4. Пользователь, от имени которого 1С сервер подключается к исследуемой базе.
2-4 могут быть связаны с учетной записью Windows (причем не обязательно из п1), а могут не связываться.
Учетные записи Windows могут быть локальными, а могут быть доменными.
В результате когда что-то не работает и выскакивает сообщение о нехватке прав, абсолютно неясно кому и каких прав не хватает...
Почему инструкции пишут так, что вопросов больше, чем ответов?
Этот термин используется в описаниях, рекомендациях. Увы, нет полного и толкового описания и не понятно, почему что-то не работает, хотя должно или работает, хотя вроде не должно... Нажимаешь пункт "Инструкция" в настройке, все по пунктам делаешь - не помогает. А то, что нет возможности сохранить незаконченную настройку не укладываетсяч в голове (приходится править конфигурацию, чтобы отключить проверку). Проблемы берутся непонятно откуда и исчезают, непонятно куда (но реже). Вроде настроил, работает, но админ ставит новый сервер или новый SQL и приходится все переустанавливать. С другими базами проблем нет, а с ЦУП - есть.
Запустить удалось, вот только на это ушло полдня (а не 15-20 минут) и самое грустное, что если это понадобится сделать снова - опять может уйти полдня (или больше).
Есть еще одна "бомба" при просмотре статистики
смотрим процедуру ЖурналПоказателей.ПодготовитьДанныеДляПросмотра и видим запрос:
|ВЫБРАТЬ
| *
|ПОМЕСТИТЬ
| ЖурналПоказателей
|ИЗ
| РегистрСведений.ЖурналПоказателей
|ГДЕ
| ИнформационнаяБаза = &ИнформационнаяБаза
|ИНДЕКСИРОВАТЬ ПО
| Период,
| Показатель,
| НомерЗаписи
во временную таблицу помещается весь(!) журнал и чем дольше вы ведете статистику тем больше вы тратите время на её просмотр.
Исправляется просто - добавьте условие И Период МЕЖДУ &НачалоИнтервала И &КонецИнтервала
и установите параметры
Запрос.Параметры.Вставить("НачалоИнтервала", Контекст.НачалоИнтервала()-1);
Запрос.Параметры.Вставить("КонецИнтервала", Контекст.КонецИнтервала()+1);
Второй вариант, если графики не нужны а нужны только данные - используйте обработку из вложения.
Отключать блокировки не хочется, счетчики на английском, в PMU добавлен пользователь, все по инструкции сделали и перепроверили. Что еще может быть, посоветуйте
(20) ikbokov,
1. Если у вас используются домены, то сервер 1С для базы ЦУП запущен под локальным пользователем, а вы дали права доменному.
В это случае лучше запустить сервер 1С под доменным пользователем. Проверьте этот момент.
2. Если п.1 не сработает то пройдитесь отладчиком и посмотрите в какой момент возникает ошибка.
3. Если п.1 и п.2 не помогла, тогда можно отказаться от показателей Количество таймаутов и количество взаимоблокировок.
Либо можно их получить без помощи ЦУП, а с помощью все того е PerfMon.
4. Если ничего не помогает, тогда сложно вот так сказать, не видя системы. Надо подключаться и смотреть.
Здравствуйте!
При настройке ЦУП при включении параметра "Блокировки" возникли проблемы - ошибка 148 ( 0x800007d0: ) не удалось собрать значения счетчиков производительности.
Архитектура сети:
1С сервер запущен под локальным пользователем SRV1CV8, доступ к базе SQL через пользователя "sa", SQL находится на другом компе. ЦУП запускается под доменным пользователем (например "Иванов"). Пользователь Иванов входит в группу "Счетчики производительности", SQL на русском, в код добавил определения счетчиков на русском. К моему сожалению, ошибка использования всё равно есть. Подскажите где ещё копать, отключать "блокировки" не хочется.
Пользователь Иванов входит в группу "Счетчики производительности"
Он должен входить в эту группу на сервере СУБД
SQL на русском, в код добавил определения счетчиков на русском
Не всегда в этом случае счетчики тоже на русском, запустите Performance Monitor и проверьте названия счетчиков Ms SQL.
Если они на английском, то нужно будет вернуть англ. название.
Так же нужно проверить следующее условие:
Убедитесь (по-умолчанию так и есть), что на компьютере, где запущен сервер СУБД:
- запущена служба "Удаленный реестр (Remote Registry)";
- для пользователя, от имени которого запущен клиент ЦУП, есть право чтения раздела реестра "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib";
- в параметрах групповой политики (gpedit.msc) присутствует строка "Software\Microsoft\Windows NT\CurrentVersion\Perflib" в параметре "Политика Локальный компьютер \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \ Параметры безопасности \ Сетевой доступ: удаленно доступные пути и вложенные пути реестра".
Если совсем ничего не помогает, тогда прогоните через отладчик, и посмотрите где возникает ошибка.
При попытке анализа взаимоблокировок получил ошибку в стиле "Ошибка метода ЗаписатьТекст и предложение открыть форму настройки базы. После чего эти замеры намертво зависли в мониторе анализа, не удалялись и не обсчитывались. Убрать смог только с помощью кнопки "Повторить".
Еще какая-то странная проблема - информацию собираю, аналитические показатели выбираю, например анализ запросов, время запросов ставлю 0, получать план запроса - Да. Выполняю замер, минут 6-7, запросы точно есть, около 100 за это время проходит, но после анализа, когда должен показать запросы и их планы, выскакивает окошко с надписью "Анализ проблем на выбранном участке не может быть выполнен. Возможные причины: 1. Список показателей производительности не содержит ни одного аналитического показателя 2. Выбранный интервал просмотра не содержит проблем производительности". Получается просто так посмотреть план запроса им нельзя, только в случае какой-то проблемы? Или у меня что-то не так настроено?
(28) necropunk,
Скорее всего у вас не собираются логи ТЖ.
Это может быть по нескольким причинам, например если вы указали не ту базу при настройке ЦУП которую вы исследуете. Проверьте ту ли базу вы указали.
Пройдите мастер настройки еще раз, особое внимание уделите шагу включения ТЖ.
После включения записи показателя Анализ запросов в ЦУП подождите 1 минуту и посмотрите пишутся ли логи в ТЖ, откройте текстовые файлы логов и посмотрие есть ли там запросы и планы.
Если СУБД MS SQL то никаких проблем быть не должно.
(29) СУБД Microsoft SQL, тех. журнал точно пишется, 8 гигов уже папка, планы запросов в нем есть, смотрел. Когда ЦУП анализирует журнал в процессе настройки, ищет там файлы рпхост и прочие - смотрел отладчиком, он точно находит этот журнал и файл настроек. Грешу на pmc.dll, может прав где недодал и он компоненту не может зарегистрировать правильно. Версия ЦУП-а последняя, ума не приложу пока в чем дело, ладно, буду разбираться...
(30) necropunk,
Если бы небыло прав, то это выяснилось бы еще на этапе настройки.
Попробуйте снова пройти мастером все пункты, если не поможет тогда берем отладчик в руки и смотрим на каком этапе возникает засада.
(31) все перепроверял внимательно. Отладчиком смотрю - у меня в списке показателей, при просмотре, нет Анализа запросов. И добавить я его не могу, то есть, где-то, по какой-то причине, он убирает его из списка. Ладно, разберусь - опишу проблему, может поможет кому.
В тексте журнала, в общем, все есть, а вот в регистры почему-то он эту информацию затягивать не хочет, то ли пути в ТЧ замера найти не может, хотя они туда попадают... Завтра доразбираюсь, в общем.
Засад много возникает, в общем. Пока не приблизился к пониманию. Ставлю галочку. Каждый такт он собирает инфу о запросах. СборЗапросовВключен = Истина. Как только галочку снимаю - он ставит ее в Ложь и удаляет мой замер. А у этого замера в ТЧ хранится путь к технологическому журналу. Соответственно при попытке загрузить пути в ДанныеТЖ - туда не пишется никакой путь, только пустые значения. При попытке загрузить журнал - делается запрос по этому регистру. Но данных там нет. Соответственно в процедуре ЗагрузитьТехнологическийЖурнал() ничего не происходит. Нет данных - нечего обрабатывать, он говорит - проблем производительности нет. Ковыряю дальше, возможно что-то не так понимаю... А у вас в регистрах ДанныеТЖ и Технологический журнал какие данные хранятся? И все ли замеры хранятся или есть удаленные номера?
Возникла похожая проблема, но в конфигуратор еще на залазил, думал с настройками проблема. А тут похоже такая же проблема.
Имеем:
Windows Svr 2012 R2 Standart
MS SQL 2012
Центр управления производительностью, редакция 2.0 (2.0.12.11)
База для тестирования: Стандартный нагрузочный тест (из КИПа)
Все настроено, ошибок нет, логи журнала пишутся. Показатели аналитики добавлены соответственно.
После окончания замера в просмотре получаю ту же ошибку: Нет проблем с производительностью.
Буду рад помочь разобраться.
(35) Bad_Developer, В общем, провел два дня в отладчике. Проблема первая: было отключено выполнение фоновых заданий. Включил задания, в регистр попадали данные, но не совсем те и ненадолго. Отладить фоновое задание возможности не было, написал обработку с вызовом этого метода, просто одна строчка:
Анализ.ЗаданиеПолучитьИсходныеДанные(СсылканаОбъект);
где ссылка на объект - это документ замера созданный. Причем, его долго ловил довольно - он сразу после загрузки данных удаляется, там надо поставить точку отладки перед "Замер.Удалить()" и прекратить отладку. Потом я запустил на отладку мою обработку. Уже не в фоновом режиме, поэтому провалился в отладку, все внимательно изучил и все прекрасно отработало. Толко потом происходит удаление этого документа, а так как он регистратор - то и всех движений регистра "ДанныеТЖ" тоже. В общем, я закомментил все удаления документов замера пока.
(37) ЦУП использую последний, 2.0.12.15. вообще, подозреваю, что кто-то до меня какую-то настройку установил или константу, пока не важно, сейчас все работает, будет время - разберусь, пока не до этого совсем.
Коллеги, доброго времени суток!
Никто не сталкивался с подобной ошибкой? -
{ОбщийМодуль.СтруктураМетаданных.Модуль(38):
[СтруктураХранения = СоединениеИБ.ПолучитьСтруктуруХраненияБазыДанных(, ТерминыСУБД);]}:
Ошибка при вызове метода контекста (ПолучитьСтруктуруХраненияБазыДанных)
(Произошла исключительная ситуация (1C:Enterprise 8.3.10.2466): Ошибка инициализации модуля: Документ.ЗаявкаНаРасходованиеДенежныхСредств.МодульМенеджера
{Документ.ЗаявкаНаРасходованиеДенежныхСредств.МодульМенеджера(2501,3)}: Процедура или функция с указанным именем не определена (ПолучитьДанныеОбъектаПоМакетам))
Происходит после остановки замера, при состоянии "Получение исходных данных"
Коллеги, доброго времени суток!
Никто не сталкивался с подобной ошибкой? -
{ОбщийМодуль.СтруктураМетаданных.Модуль(38):
[СтруктураХранения = СоединениеИБ.ПолучитьСтруктуруХраненияБазыДанных(, ТерминыСУБД);]}:
Ошибка при вызове метода контекста (ПолучитьСтруктуруХраненияБазыДанных)
(Произошла исключительная ситуация (1C:Enterprise 8.3.10.2466): Ошибка инициализации модуля: Документ.ЗаявкаНаРасходованиеДенежныхСредств.МодульМенеджера
{Документ.ЗаявкаНаРасходованиеДенежныхСредств.МодульМенеджера(2501,3)}: Процедура или функция с указанным именем не определена (ПолучитьДанныеОбъектаПоМакетам))
Происходит после остановки замера, в состоянии "Замер завершен"
По моей связке:
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С для экспертов, в ней описаны практически все ситуации по оптимизации но сжато остальное надо додумывать самому или ковырятсься в потрохах.
(46) Bad_Developer, Книгу читал, да, хорошая вещь, если ты про книгу эксперта по технологическим внедрениям. Надо заметить, ЦКК сейчас тоже трэш и угар - если имя сервера больше 20 символов - мониторинг памяти не работает, к примеру, процедур мало, очень много допиливать приходится, от обращений к кластеру до рассылок. Когда она на обычных формах была - и контрольных процедур много было и работало все стабильнее, имхо...
Спасибо огромное за статью!
Добавлю свой комментарий по ошибке "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 из нового релиза, а то предположительно можно получить много сюрпризов.
Столкнулся еще с одной ошибкой. ЦУП не может обработать результаты анализа одной из баз. С другими базами все нормально. При попытке обработки собранных анализов возникает ошибка "Ошибка при вызове метода контекста (ПолучитьСтруктуруХраненияБазыДанных)". Никто не знает в чем может быть дело?
(56) necropunk,
Не сталкивался, видимо какую-то новую ошибку посадили.
Обычно все ошибки ЦУП решаются пройтись хорошенько отладчиком. Если вам удастся решить эту проблему, большая просьба, отпишитесь пожалуйста в этой ветке. Добавлю в коллекцию.
(57) В общем, побился над проблемой довольно долго, но потому что балбес - не догадался включить журнал регистрации. Как только включил - он поймал ошибку и записал в журнал расшифровку. В моем случае было сразу две ошибки, связанные с конфигурацией серверов.
(65) одна - не помню точно уже, не записал, в общем, связана была с правами, а вторая - с СОМ-компонентой, то ли еще одну версию платформы поставили, то ли с правами тоже связано, уже не помню точно а журнал регистрации давно потрачен.
(56) necropunk,
Попробуй в отдельной обработке установить COM-соединение с проблемной базой данных и в соединении вызови функцию ПолучитьСтруктуруХраненияБазыДанных().
(56)
Была такая же ситуация. Посмотрел в журнале регистрации цупа вышел на то что не компилится модуль менеджера справочника в исследуемой базе из которого вызывается процедуры модуля. ПОставил этому модуля галку внешнее соединение и все ок
MSSQL.cpp : 79 ( 0x36b7: The requested lookup key was not found in any active activation context. ) - SQL Server connection failed.
Возникает такая ошибка при регламентном мониторинге. При этом во время настройки соединения проблемы нет. Такое ощущение, что проблема возникает, когда появляется какая-то взаимоблокировка. Все права сделал по инструкции.
(60) Sиlьver,
Эта ошибка обычно как раз и возникает при анализе дедлоков. Проверьте права на каталог трассировки, пользователь MS SQL Server должен иметь туда полный доступ
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 эта группа есть. Не знаете в чем может быть причина?
(69) cheburashka,
В этой версии MS SQL Server такую группу убрали и без нее все должно работать.
А что у вас возникает ошибка на этом шаге?
Там пользователь ОС клиента ЦУП должен иметь разрешение Alter Trace на сервере СУБД.
(70) ошибка возникает на шаге "Сервер ЦУП (Трассировки)": MSSQL.cpp : 80 ( 0x36b7: Указанный ключ соответствия не обнаружен ни в одном из активных контекстов активации. ) - SQL Server connection failed.
Причем у вас это ошибка MSSQL.cpp : 79 а у меня MSSQL.cpp : 80. В инструкции сказано, что нужно пользователя добавить в эту группу. Но ведь группы нет. При этом шаг "Трассировка" прошел успешно. Права на папку с трассировками имеют "Все".
(71) cheburashka,
Там вообще можно ничего не указывать, это шаг не обязателен.
Просто если вы укажите сетевой каталог то трассировки будут удалятся после использование.
Проще ничего не указывать и удалить трассировки потом вручную, чем разбираться с правами доступа.
(72) это я знаю из Вашего курса, но возможность автоматического удаления трассировок мне понравилась и я решил ею воспользоваться. Но после того как столкнулся с ошибкой, а инструкция указывала на то же самое, что делается на шаге "Трассировки", то я подумал, что эта группа пользователей Windows важна и шаг "Трассировка" я не выполнил, хотя ошибок не получил.
(73) cheburashka,
Сейчас проверил, очень странное поведение вроде в ЦУП выполняется один и тот же запрос, однако на шаге трассировок он выполняется успешно, а на шаге Сервер (трассировки) выполняется с ошибкой даже при наличии всех прав.
Если надо что бы трассировки удалялись, просто перепишите код ЦУП что бы на этом шаге не было проверок, а молча удалялись файлы трассировок.
(97) Kamikadze, а причем здесь флаг Удалять трассировки?
Вам надо попробовать 2 варианта решений:
1. Пользователю ОС под которым запущен клиент ЦУП и пользователю ОС под которым запущен сервер 1С на котором размещается база ЦУП, нужно дать права «Alter trace» в SQL Server, просто откройте инструкцию на шаге настройки «Трассировки» и сделайте все по шагам еще раз, только сделать это нужно для двху пользователей.
2. Проверить, что у пользователя под которым запущен сервер СУБД есть доступ на чтение и на запись в указанный каталог трассировки.
Andreynikus, у меня еще такой вопрос к Вам: если я хочу мониторить 2 разные базы, находящиеся на одном сервере в одном кластере, я могу при настройке указать для них одинаковые папки для хранения логов ТЖ и трассировок?
(76) cheburashka,
Да можно, т.к. ЦУП все равно создает еще один подкоталог с уникальным именем так что конфликта не будет.
Можно даже 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'
Тестирование и исправление базы не помогло.
Подскажите пожалуйста в какую сторону копать?
(86) Bloood,
1. Попробуйте заменить процедуры в конфигурации ЦУП исправленными процедурами из архива к статье.
2. У вас случайно не MS SQL Server 2014?
Коллеги, столкнулся с такой проблемой. Собираю трассу ЦУПом, блокировки поймал. Начинается анализ и... сильно задумывается. На несколько часов, а то и суток. Обычно нет возможности дождаться конца анализа.
"Виснет" в общем модуле "АнализБлокировок1С" на разделении строк блокировок:
ВсеБлокировки = КипОбщий.РазделитьСтрок('нашиблокировки", ",")
то есть, из-за обилия блокировок, он не может их оперативно разделить. В какую сторону дальше искать для быстрого анализа?
Трасса 2-3 минуты
(90) wondkind,
Зайдите в функцию и посмотрите на какой именно строке он зависает или зацикливается. Там функция всего на пару десятков строк.
Такое чувство что он впадает в какой-то бесконечный цикл. Пройдитесь под отладчиком и посмотрите в чем именно проблема в данной функции.
(91) вчера слишком загружен был. Спасибо большое за совет. Так и сделал.
Зависало на разделении строк в массив. Какая-то не очень оптимизированная функция стандартно была.
Строка ~307 тысяч символов. Встроенная функция разделения строки проходит ПО КАЖДОМУ символу и потом его прибавляет к строке массива.
То есть, функция "найти" не использовался, а сравнивало каждый символ с символом разделителя.
Исправил, всё заработало.