Добрый день!

Чтобы найти узкие места в коде, можно воспользоваться онлайн инструментом http://www.gilev.ru/querytj/ для мониторинга и анализа долгих запросов.

Инструмент ориентирован прежде всего на клиент-серверный вариант 1С:Предприятие 8 и MS SQL Server. Хотя часть функций работает и в других связках.

Мы (команда gilev.ru) разработали этот инструмент для себя, но раздаем его бесплатно для всех желающих. Единственное ограничение - рано или поздно наступит критический момент когда наши аппаратные ресурсы закончится и нам придется думать о финансовой стороне. А пока все выглядит "радужно" и можно пользоваться (даже нашим конкурентам)!

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

На текущий момент сервисом пользуются 500 человек (учетных записей). Из них 150 - это наши "проекты", остальное - энтузиасты.
Размер базы данных

Общее описание сервиса - http://www.gilev.ru/querytj/
Инструкция по настройке - http://www.gilev.ru/setupquerytj/
Видеоинструкция по настройке - http://youtu.be/anQZ1XQtmPM
Вопросы по настройке и эксплуатации - http://www.gilev.ru/forum/viewforum.php?f=3
Вопросы в скайп по настройке (если выше перечисленное не помогло) gilev_slava

Почта для вопросов [email protected]

Цель данной ветки - проинформировать о бесплатных возможностях по диагностики узких мест в коде.

__________________________
Согласовано с Волшебником.

(0) 2 вопроса

1) Будет ли в дальнейшем форма просмотра данных локально, без использования вашего веб-сервера?
2) Можно ли самому впилить свою форму просмотра и зарубить отправку данных на ваш сервер?

Ветка согласована.

(1) Вопросы по настройке и эксплуатации - http://www.gilev.ru/forum/viewforum.php?f=3

Некоторые технические характеристики:
Размер базы данных немного больше 100 Gb.
Система использует "разделители".
Клиентская часть - 8.2.
Серверная часть - 8.3.

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

Особенности инструмента:
- показывает запросы платформы (ЦУП не показывает)
- сбор происходит по всем информационным базам сервера (не зависимо от того где субд)
- использует только Технологический Журнал, COM-соединения с базами и других подключений не имеет (в отличии от ЦУП)
- логины и пароли для мониторинга информационных баз не требует и не подключается
- в серверной части можно посмотреть фильтром конкретную базу, а также можно оценить код всех информационных баз посовокупности

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

+(6) Ой! Не дочитал до конца.

Вообще сервис не бог весть какой сложный, мы думали что подобное уже давно сделают. Брать за "ранжирование" кода по ТЖ  не видим смысла.
(7) Да :), в клиенте можно выставить любую длительность, но надо понимать, что это скажется на информационной системе через просадку железа. Если выставить порог в 0 - это значит все запросы которые были в памяти фактически "будут записаны на диск".

особенность, обнаруженные в процессе эксплуатации как другие утилиты мониторинга на платформе 1С:
после "падения сервера 1с" наш сервис не забывает "о том что он собирал логи" и мы еще пока не разу не ловили нехватки места на диске

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

(10) не знаю, но нам попадают такие запросы как "реструкторизация" в конфигураторе, запрос к "config", инсерты "при пересчете итогов" и т.п.

мы пользуемся тем же самым ТЖ что и Вы :)

(11) Теперь ясно. Имелись ввиду такие запросы, которые ЦУП исключает из рассмотрения по все видимости в виду отсутствия возможности на них повлиять изменением конфигурации. )

(12) в теории - нельзя повлиять;
на практике - чистка "программно из 1с" распухших настроек пользователей,
выполнение реструктуризации в ТиИ для "незавершенных корректно регламентов",
очистка нулевых записей пересчетом итогов в таблицах итогов, распухших нулевыми записями,
и т.п. и т.д.

приведу простой пример как легко обнаружить нашим сервисом проблему (пусть не шибко сложный, но реальный)

клиент говорит - раньше так все классно было, прямо "летало"
а три недели назад неожиданно начались "тормоза"

поставили наш сервис и "обалдели" ни один из запросов не использует кластерный индекс - а все просто, когда они загружали через DT конфигурация в самом начале сказала "не могу сделать вставку не уникального значения", ну ребята нажали "ок" и стали работать как будто все нормально - ну как же, данные то все залились :)))

в итоге, запустили ТиИ с реструторизацией, исправили неуникальное значение (дубль), снова сделали ТиИ, индексы построились платформой и система "пришла в норму"

хэппи енд

(14) А если ошибок нет, ТИИ не помгает а "тормоза" появились резко, причем тормоза как на сикульной, так и на файловой версии, ТИИ (как сказал) так и chkdbfl не помогли, вы решите такую проблему ?

(15) ну так для этого и делали инструментарий, решим

(16) 1С к которой обращались и выслали им проблемную базу, так ничего и не ответили, а Вы, смотрю, напористые.

Жаль это было давно и копии этой базы у меня уже нет, но факт был, победить не смогли, дотянули до НГ сделали свертку. Позже таких проблем не видели.

Спасибо что откликнулись.

если ли смысл пробовать для postgres ?

(18) мы лично не разу не запускали

если есть энтузиазм, расскажите что получилось - в нашей практике как раз последнее время задач с postgresql не было

ни разу...

На заметку.
Еще один пример, который позволяет обнаружить проблемы - рассмотрение значений параметров запросов с типом "дата", когда попадают значения сильно больше или сильно меньше рабочей даты (скажем с дельтой на 10 лет)

Как правило это означает, что либо "прошедшим" либо "будущем" временем ОШИБОЧНО введены данные, особенно это характерно при загрузках, когда "меньше контроля данных" при вводе.

вчера после создания ветки была не одна попытка зарегистрировать "левые ящики" (да не будет оно так работать)

уважаемые "конкуренты"! - не бойтесь "светиться"
БиТ к примеру официально попросил и получил более двух десятков учеток пачкой :)

(14) так и запишем.
ТиИ с реструктуризацией решает половину проблем с тормозами

(22) Что значит левые ящики ?

(23) если база битая, то зачастую да. остальное решает логическая целостность.

Это если база битая.

(23) ТиИ зачастую их "обнаруживает" - исправить не уникальность записей эта процедура сама не может к примеру :)
Но в чем то Волшебник прав - на крупных предприятиях на больших базах считается "нереально выполнить ТиИ" и порой недооценка значимости этой процедуры приводит к "детским" ошибкам.

(24) указываешь при регистрации "чужой" ящик

Немного истории развития сервиса:
в сентябре 2012 - "расшарили" инструмент для общего пользования http://gilev.blogspot.ru/2012/09/1.html
в октябре 2012 - сервис получил "начальную" известность, сделали прогноз роста популярности http://gilev.blogspot.ru/2012/10/blog-post_4.html
и тогда же пошли первые отзывы о сервисе http://gilev.blogspot.ru/2012/10/online-1.html

в ноябре 2012 - опубликовали первую статистику накопленных данных сервисом http://gilev.blogspot.ru/2012/11/blog-post.html и разумеется случился Инфостарт Евент 2012, на котором презентовали широко возможности инструмента http://youtu.be/3jOVKom0f1w

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

в декабре 2012 - мы расширили сервис новыми возможностями:
появилась закладка с оценкой загруженности железа в момент исполнения запроса;

добавили закладку с апдексом, которая выполняет даже 2 функции:
1) показывает вклад запроса в общее замедление операции
2) для проблемных мест показывает текст запроса субд http://gilev.blogspot.ru/2013/03/1.html

добавили на таблицу ранжирования длительности запросов "вклад" ожиданий блокировок (из сервиса блокировок)

(0) в чем преимущество перед Data Collection?

(32) что такое Data Collection ?

тогда же в декабре 2012 провели вебинар, целиком его не получилось записать, но часть все таки попала - вот она http://youtu.be/aoDqFNzp6d8 - показана часть возможностей сервисов

(33) у ms sql сбор данных о производительности.

(35) ну ответ очевиден - виден контекст 1С прежде всего, ранжирование происходит не по запросам SQL, а по контексту 1с

продолжаю "вылазку в историю"
январь 2013 ознаменовался массовым приходом серьезных предприятий на наши сервисы, некоторые из них лежат в публичных референсах с использованием онлайн-сервисов, например http://goo.gl/oKCP5

(36) сервис показывает где тяжелый запрос находится в конфе 1с? что-то типа как у софт-пойнта?

февраль 2013 начался с еще одного расширения функционала - добавили временные метки для большего удобства, теперь можно выполнять например "исследования нагрузочного тестирования" быстро помечая нужные моменты времени "начало теста", "конец 1й итерации" и затем быстро использовать их в отборах
тогда же сделали рассказ о практическом применении и записали на видео http://youtu.be/nrCGWm-2jog
(правда звукозапись немного подвела :), но понять можно )

(38) софтпоинт берет деньги! этот сервис бесплатен
возможности сервиса описаны http://www.gilev.ru/querytj/, можно быстро посмотреть работу (ссылка на демо там же)

(40) тогда круть конечно!

февраль 2013 закончился еще одним небольшим улучшением фильтров для анализа http://gilev.blogspot.ru/2013/03/blog-post_20.html, но куда важнее что в феврале мы сделали обратную связь через форум  http://www.gilev.ru/forum/ и благодарны тем, кто советом и делом помогает нам улучшать этот инструмент!

благодаря советам пользователей, мы начали "учить" сервис очевидным моментам, например распознавать код с автоматическими блокировками http://gilev.blogspot.ru/2013/03/blog-post_12.html
правда не обошлось без смешного - сначало по ошибки конфигурацию на управляемых блокировках он понимал как "с автоматическими", потому что реструкторизация данных происходит с более высоким уровнем изоляции в транзакциях ;)

возвращаясь к вопросу (1)
еще с декабря многие заговорили о "как бы нам его портировать себе"
Это сложный технически вопрос, и на сколько сервис просто выглядит снаружи (во всяком случаи мы старались), на столько сложен он технически в плане обслуживания. Причем речь идет не о "сетупе", а именно об обслуживании.
Пока мы не разу "не обрезали" данные, конечно это больше спортивный интерес и вызов для нас, но уже несколько раз апгрейдили сервер. Зато уже переделывали алгоритм отображения данных.

На форуме http://www.gilev.ru/forum/viewtopic.php?f=3&t=19 прозвучала мысль об "офлайновой" эксплуатации системы как "передавать" данные на сервис в условиях когда на предприятии нет доступа в интернет.

К партнерской конференции 1С мы подговили такую возможность
http://gilev.blogspot.ru/2013/03/blog-post_14.html и теперь клиент может передавать данные через флешку/почту.

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

(46) Если Вы хотите помочь нам в чем то, напишите на почту [email protected]. Если что то будет дельное, мы еще Вас и отблагодарим, ок?

(47) ок!

Возвращаясь к исходной теме, как сервис может помочь в решении сложных проблем, описан "учебный пример" http://www.gilev.ru/forum/viewtopic.php?f=6&t=96 где
запрос

в терминах 1с

ВЫБРАТЬ
ВТ_Номенклатура.Номенклатура,
РегистрДляДемонстраций.Склад,
РегистрДляДемонстраций.Контрагент,
РегистрДляДемонстраций.Организация,
РегистрДляДемонстраций.Количество
ИЗ
ВТ_Номенклатура КАК ВТ_Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РегистрДляДемонстраций КАК РегистрДляДемонстраций
ПО ВТ_Номенклатура.Номенклатура = РегистрДляДемонстраций.Номенклатура

в терминах субд

SELECT
T1._Q_000_F_000RRef,
T2._Fld10068RRef,
T2._Fld10070RRef,
T2._Fld10071RRef,
T2._Fld10072
FROM #tt1 T1 WITH(NOLOCK)
LEFT OUTER JOIN _AccumRg10067 T2
ON (T1._Q_000_F_000RRef = T2._Fld10069RRef)

в случаи отсутствия "покрывающего" индекса имеет план запроса http://goo.gl/hAXQd

верхний уровень
|--Nested Loops(Left Outer Join, WHERE:([tempdb].[dbo].[#tt10].[_Q_000_F_000RRef] as [T1].[_Q_000_F_000RRef]=[first].[dbo].[_AccumRg10067].[_Fld10069RRef] as [T2].[_Fld10069RRef]))

ветка 1
|--Index Scan(OBJECT:([tempdb].[dbo].[#tt10] AS [T1]))

ветка 2
|--Clustered Index Scan(OBJECT:([first].[dbo].[_AccumRg10067].[_Accum10067_ByPeriod_TRN] AS [T2]))

где ключевым моментом является "сканирование" индекса - это плохо!

в случаи создания покрывающего индекса (в данном примере это индексирование измерения)
http://goo.gl/khW1K

Во втором случаи уже происходит операция INDEX SEEK - и это хорошо! Так как в примере выясняется что помимо скорости сканирование "лишних" записей делает "избыточную" область блокирования, которая увеличивает вероятность отказа ввода данных в систему из-за сообщения об ошибке на превышения таймату блокировки.

Таким образом, помимо основной цели - ускорять запросы решается задача устранения избыточных блокировок! Разумеется это также нас подводит к суровой необходимости "учиться читать планы запросов".

Есть одна тема о которой можно писать достаточно часто и много - это "безопасность облаков". Нам задают вопрос о "надежности и приватности" данных каждую неделю и это нормально.

Я бы разделил всю аудиторию на:

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

Прекрасно понимаю, что не все программисты (такой вопрос нормален и для директора и для менеджера, и возможно не все доверяют своим программистам) - но основной наш аргумент, посмотрите код и убедитесь сами. Именно по этой причине мы его и не закрываем - чтобы сделать прозрачность работы системы.

Какие данные отображаются в информационной системе наглядно можно посмотреть https://skynet.gilev.ru/QueryTJ/

Демо: учетная запись work без пароля.

Смотрю и коллеги из Софтпоинта тоже зашли на огонек "полюбопытствать", приветствую :)

Мне в привате задали правильный вопрос "что это вы все материальные блага и коммунизм рассказываете для других, а зачем вы для себя делали, ведь есть цуп?"
раскрою ответ, но зайду "издалека" (до вечера еще много времени :) )

Да, действительно, мне фирма 1С подарила лично ЦУП, за это им большое спасибо! Более того и у Раруса есть купленная версия. Да и многие клиенты сейчас пошли продвинуты и уже приходят с ЦУПом (т.е. уже купили в составе 1С:КИП). Но...

Свою деятельность по повышению производительности начинал сам. Тогда еще такого понятия как ЦУП или 1С:Эксперт не было. Поэтому моими инструментами были профайлер, отладчик ну и другие стандартные и всем знакомые инструменты.

Поскольку обнаруживать проблемные места в коде и улучшать в коде у меня стало получаться, это стало приносить деньги.
Ну а несколько лет назад уже работая в коллективе единомышленников стало очевидно, что с ростом потока "проектов" нужно и себестоимость работ снижать, и качество повышать за счет автоматизации рутинных моментов.

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

Если многие IT руководители только приблизительно знают как у них обстоят дела с производительностью, то для меня этот вопрос прозвучал в новом свете - а как обстоят дела у моих клиентов с производительностью? Т.е. вопрос не звучит про одного единственного клиента, а про всех сразу. При чем если раньше как технический специалист подключался к их информационной системе, то теперь это делают мои коллеги. Насколько сильно верить на слово надо людям - это философский вопрос имхо. Ведь есть к примеру стажеры :)

Есть еще два вопроса, на которые ЦУП не давал ответов:

1. Как мне осуществлять контроль качества работ по повышению производительности, выполняемых моей командой специалистов?
2. Верить заказчику и своим подчиненным на слово?

Если описывать формально потребности, то можно сказать так:

Нужно знать ход не одного проекта, а 10-15 проектов одновременно, и состояние загрузки семи сотрудников.
 
Необходимо обеспечить доступность/простоту представления информации, на основании которой принимаются решения.
 
Одновременно эту информацию должен видеть не только я, но и руководители со стороны Заказчика, на каждом из проектов.

Надо сказать, что меня не осеняло и ночью как Менделееву таблицы не снились.
В рамках проектов ЦКТП, которые мы делали с 1С, мы посмотрели сначало как это делают "другие".

Сотрудники "1С "для проектов "1С:ЦКТП" решили просто - всю рутинную работу по сбору данных делают партнеры и выгружают файлы на ftp сервер "1С" для последующего анализа.

Но даже такой вариант создает проблемы: много проектов -  много файлов.

Иногда результаты из "1С:Центр Управления Производительностью" весят порядка 50 Гб, перенос файлов - это долго и ДОРОГО (поверьте, время на копирование - это тоже себестоимость проекта).

Самое оптимальное решение - хранить все нужное в "централизовано". Кто то назвал бы это "облаком", не уверен, но не суть.

В августе 2012 года мы выполнили свой первый проект на нашем онлайн сервисе "Анализ долгих запросов".

С первого же проекта оценил преимущества:
 
1) Вижу всю необходимую информацию
2) Очень большая экономия времени (не надо ожидать параметров подключения куда-либо)
3) Все проекты в одном месте
4) Не надо помогать заказчику смотреть данные, они все это делают одновременно сами

Результат - проекты стали "на поток":

Мы получили значительное уменьшение себестоимости проектов (в 2-3 раза)

Заменили платный 1С:КИП (84000 руб.) на бесплатный облачный сервис

Уменьшили сроки (например, вместо 3х дней на сбор стало хватать одного дня)

Появились новые возможности:

- мы стали бесплатно делиться онлайн-инструментами
- пользователи помогают нам улучшать сервисы (см. http://www.gilev.ru/forum)
-лояльность клиентов возросла

Поскольку не бывает так что все сотрудники с одинаковой квалификацией или есть доступные ресурсы, иногда и сам снимаю корону и одеваю фартук и смотрю в сервисах на случаи, которые например раньше наши сервисы не фиксировали, коллективно их разбираем.
Мне нравится, что детализация запроса показывает информацию так, что там не видно имени пользователя и материал максимально "обезличен",т.е. удобно демонстрировать информацию для анализа.

Не думаю, что сервисы останутся в таком виде. Как говорится, аппетит приходит во время еды. Планы у нас наполеоновские :)

Если у Вас есть идеи, что будет полезно улучшить, пишите в наш  форум, ведь Вы первый кто от этого выиграет.

Спасибо!

(0) Проблемы могут быть не только в запросах, но и в программном коде. Такие ситуации анализируются?

(71) а такое возможно? есть только наверное по шаблонам каким то искать.

(72) учитывая, что 1Ска на каждый пук с объектом/ссылкой лепит запрос, да не один, (недавно обсуждали), вполне может быть

Мне кажется нужно на главной странице Вам прям написать, что если база не на управляемых блокировках, даже не пытайтесь что либо сделать, а с начала переводите на управляемые !!!

А есть случаи когда автоматический режим лучше управляемого, речь об блокировках !

(75) какие случаи?

(76) случаи использования конфы(БД) 1С ?

Или 100% гарантировано, что использование управляемого режима лучше(с точки зрения производительности) чем автоматического в независимости от структуры/алгоритмов конфы и т.д. ?

(77) это в (74)(75) вопрос, что ли, был?

(71) проблемы с производительностью могут быть не только в запросах или программном коде:
- оптимизировать можно бизнес-процессы
- обучить пользователя (не нажимать на все подряд)
- оптимизировать/изменить алгоритм
- оптимизировать код и запросы
- оптимизировать рекламенты по обслуживанию и настройки среды
- оптимизировать/сбалансировать железо

Сервис Анализа долгих запросов предназначен для анализа долгих запросов. По нашему опыту они составляют 80% проблем.

Сервис взаимодействует с другими сервисами - которые решают смежные задачи.
Конечно, какие то задачи сервисы не решают по очень простой причине - мы автоматизируем решение тех проблем, с которыми нам пришли реальные клиенты. Приведите клиента с новой проблемой, и мы сделаем инструментарий.

+(77) Скажем так, бывали ли в истории случаи когда после перевода на УБ стало на порядок хуже ?

(78) Ага типа того.

(74) Зачем, сервис при первом же обнаруженном запросе это и так скажет. Поясните пожалуйста мысль.

(75) управляемые блокировки требуют дополнительных накладных ресурсов и если этот механизм использовать не по назначению а лепить "потому что так рекомендуют гуру", то можно и навредить
но все решения фирмы 1с за последние годы переведены на управляемые блокировки, поправьте меня, если ошибаюсь

(82) сдуру можно всё, что хочешь, сломать

(71) к примеру - взаимоблокировки - это не проблема долгих запросов, для нее есть http://www.gilev.ru/deadlock/ специализированный сервис

(84) полная карта публичных сервисов есть здесь http://www.gilev.ru/online/
еще есть "внутренние"... :)

Как взаимодействуют сервисы для обсуждаемого здесь сервиса Анализа долгих запросов показано на схеме http://goo.gl/JXmvc

Есть к примеру другой сервис http://www.gilev.ru/sqlsize/ - мы им неактивно пользуемся, а вот админы наших клиентов "любят" его, хотя это нам не понятно :)

(80) у нас такого не было в практике (хуже от упр. блокировок не становилось)
было обратное - мы апдекс внедрили на конфигурации которую не успели перевести в упр. режим, пришлось переделывать код с учетом "блокировок на диапазоны" механизма АПДЕКС (у нас теперь переключатель куда логировать - регистр или журнал регистрации)

(83) простой пример чрезмерного увлечения упр.блокировками - это наложить на запрос на чтение лишнюю область блокирования - это сервер не загрузит, но параллельность ошибочно легко ухудшит
чтобы в такие ситуации не попадать, делаем контрольные примеры, чтобы убедиться что блокируются только те данные, которые по логике должны блокироваться

(80) тут такая история вспомнилась - мы вообще решали проблему  с управляемыми блокировками - это хоть и косвенно делу относится, но все же

у управляемых блокировок тоже есть понятие эскалации блокировок (укрупнения)
если писать большие объемы данных (десятки тысяч строк) то легко получить такую проблему

если на субд можно попытаться заблокировать эскалацию http://www.gilev.ru/escalation/ , то на сервере 1С таких ключей нет - надо уменьшать в коде объемы данных за раз или бить транзакции где позволяет логика (т.е. не провоцировать условия укрупнения блокировки на сервере 1С)

Планируется ли неонлайновый сервис? По разным причинам онлайн может быть невозможен.

(91) а по каким причинам? чем Вас софтпоинт или ЦУП от 1С не устраивает?

(0)чей то ошибку выдает, не могу создать - Logcfg.xml, пишет возможно нет доступа, я сам ручками создаю там нормально, он откуда его пытается создать, под какими правами не пойму?

(93) ответил в http://www.gilev.ru/forum/viewtopic.php?f=3&t=115 - пишите пожалуйста туда
эта ветка не предназначена для техподдержки, ее цель данной ветки - проинформировать о бесплатных возможностях по диагностики узких мест в коде.

(92) ЦУП возможно будет закуплен. Вопрос раасматривается.
А причина - нет физически интернета. И не будет в разумные сроки.

P.S. Кстати, никогда не сталкивались с банками, например, где бывают особо интересные политики по доступу в интернет :)

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

Можем и ЦУПом диагностику сделать, и в рамках 1С:ЦКТП (фирму 1с привлечь). Утром задача, вечером стулья :)

В более-менее крупных IT-департаментах бывают "второстепенные" задачи. Я их называю "перевод стрел". Выглядит это так: Аудит производительности проводится с целью "оценить кто виноват в медленной работе 1С — программист или сисадмин?". Это конечно забавно :)

Тем не менее, это несложно сделать с помощью двух сервисов - анализа долгих запросов и анализа загруженности оборудования http://www.gilev.ru/hardware/.

Вторым сервисом оценивается загруженность оборудования.

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

Вопрос финансовой состоятельности в маленьких компаниях по поводу апгрейда железа несерьезен, так как платить регулярную зарплату программисту за оптимизацию кода все равно дороже. Если Вы так не думаете — не делайте поспешных выводов. Ответьте на вопрос: как часто в программе изменяется код? Может ли эта правка ухудшить скорость? Может ли ухудшить скорость «типовое» обновление?

Если сервис показывает перегрузку, то для небольших компаний выгодней проинвестировать в железо. Хороший запас мощности часто компенсирует "огрехи" в коде.

Однако что же делать крупным компаниям? Крупным компаниям тоже есть смысл инвестировать железа. Будете смеяться, но в них не считают уже как следует деньги и получается, что все равно выгодней купить железо. (Не всегда конечно).

"Середнячкам" хуже всего. И дешево железо не купить, чтобы дало эффект, и найти другой вариант тоже не просто.

Бесплатный онлайн-сервис Анализа долгих запросом, который можно назвать «Доказательство, почему виноват программист», а точнее — сервис показывает все долгие запросы, которые существуют на сервере СУБД, и их общий вклад в замедление системы. Это означает, что теперь злобный сисадмин  может воспользоваться на http://www.gilev.ru/services/online бесплатным сервисом «Анализ долгих запросов» и доказать, что программисту есть над чем «почесать репу»…
:)

Ради справедливости надо сказать, что мы видели исключения. Есть мнение что «при блокировках железо не бывает загружено», а мы видели обратное. И вариант «если скажем процессоры загружены под 100% и к ним очереди, то надо их апгрейдить» тоже при хорошем бюджете можно решить например путем реализации новым алгоритмом кода.
Но все же в жизни такие сложные варианты у Вас не возникнут, в 80% случаях эти закономерности работают.

Есть один наглядный пример, демонстрирующий "бесплатную схему" предоставления доступа к инструменту для наших клиентов (в частности).

Чаще всего на рынке программ на базе «1С» вы не найдете бесплатных продуктов.

Вот скажите те, кто «автомобилисты», когда вы приезжаете на сервис, вы покупаете «стенд для диагностики авто»? Правильно, вы платите за услуги по диагностике, а стенд не покупаете.

Поэтому поэтому, когда наших сервисов для диагностики достаточно, то сами сервисы мы не продаем. Продаем наши  услуги по диагностике.

Как считаешь, когда надо начинать заниматься оптимизацией: когда уже начало неприемлемо тормозить или ещё на этапе разработки архитектуры продумывать потенциальные узкие места и строить архитектуру "с запасом"?

(99) ну твою позицию я знаю - по факту проблем )

(100) А твоя позиция?

Имхо это слишком общий вопрос: если есть подозрения что проблемы будут, то можно соломку подстелить. Обычно чем больше пользователей, тем больше соломы )))

Константин Рупасов говорил на курсах по 1С:Эксперт - крупные базы не бывают без проблем )))

Станислав, скажу за себя - наши сервисы "сами себя смотрят" :)

(103) а когда начинаются "крупные"?

(105) думаю догадываетесь у кого это спрашивать, да? :)

(101) немного подумав...

Общий смысл инструмента в режиме 24х7 это "упреждение" проблем до того, как они стали критичными.

Но даже факт наличия критичных проблем тоже требует мониторинга.

Конечно можно пофлудить "что такое критичные проблемы" :), но думаю кому надо понимает о чем речь.

Прямо сейчас мы проктикуем "апдекс" и "статус" в режиме 24х7 - они не создают нагрузки на систему (кушать не просят).

Сервис анализа долгих запросов чтобы минимизировать нагрузку - увеличиваем временной порог. Скажем до 60 секунд его можно поднять. Если другие сервисы сигнализируют превышение порогов норм, то прямо сейчас мы вручную понижаем временной порог анализа запроса, но ты подсказал хорошую мысль, надо этот момент автоматизировать. Спасибо за идею!

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

(99) А так на этапе проектирования конечно. Хорошие данные и плохой код, работают лучше чем наоборот © не помню кто

:)

А завершить этот день хочу еще одним показательным примером за сегодня - Волшебник как в воду глядел - еще один клиент не сделал пересчет итогов (проблема нулевых записей), которая легко обнаружилась нашим сервисом http://www.gilev.ru/sqlsize/  - который легко находит такие факты.

(111) У меня глаз алмаз!

ввели данные за "начало 2001", потом нашли, перепровели текущей датой, а итоги за эти годы "насчитались" )
размер итогов в 90 раз больше размера основной таблицы регистра

Прочитал цитату "внизу" мисты:
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки - вот настоящая работа.

Подумалось - а мы ищем много сволочных и маленьких и не очень ошибок - это каторга? :)))

(0) Правильно ли я понял что ключевое во всем этом... это текстовик технологического журнала ?

+(115) По ходу так и есть ... нет текстовика ... нет и анализа.

(115) да, инструмент реализует обсчет и визуализацию ТЖ

(114) да, каторга

немного подумав...

только два сервиса так делают:
http://www.gilev.ru/status/ - анализ событий (по ТЖ)
http://www.gilev.ru/querytj/ - анализ долгих событий

не используют вообще
http://www.gilev.ru/hardware/ - контроль загруженности оборудования
http://www.gilev.ru/apdex/ - статистика длительности операций

остальные используют не только ТЖ

(118) рекламный слоган: У Вас есть каторжная работа - заберем :)))

посмотрел статистику пользования сервисом за последние два дня (сколько существует эта ветка), прибавилось 15 пользователей

было бы интересно услышать впечатление о сервисе (можно сюда или в почту или в скайп, как удобней)

(120) В качестве рекламного слогана сойдёт, но я бы не советовал прописывать это в договоре.

(122) Сейчас такие заказчики пошли: "какая разница что-то в договоре написано, мы же платим деньги, значит мы решаем за что...". Только хорошо сделанная работа помогает  :)))

(18) На Postgres я запускал совместно с Вячеславом. Чуть дорабатывали клиентскую часть, возможно и серверную (этого я не знаю).
Показывает длинные запросы, а вот с планами - беда.

P.S. Себе такой сервис сделать, с поддержкой Postgres, что ли... ресурсов правда нет на открытие в общий доступ :(

Чуть оффтопа.
По-моему Postgres недооценен в плане работы с 1С. Уже вот к 100 пользователям подбираемся, пока худо-бедно справляется. Правда железо серьезное, это тоже немаловажно.

(36) "виден контекст 1С прежде всего, ранжирование происходит не по запросам SQL, а по контексту 1с"
а так нельзя определить?
(71) "Такие ситуации анализируются?"
как Вы себе представляете анализировать работу 1сного кода?! :)
(82)"но все решения фирмы 1с за последние годы переведены на управляемые блокировки"
это какие, например?
(99)" или ещё на этапе разработки архитектуры продумывать потенциальные узкие места и строить архитектуру "с запасом"?"
как можно в 1С спрогнозировать накопление данных в той или иной выборке?! Только опытным путем.
Все упирается - в невозможность 1С нормально обработать большое количество данных.
(103)"крупные базы не бывают без проблем"
Правильно Константин говорил, поэтому и осторожно относится ко всем "оптимизациям" обработки данных в 1С.
Нельзя угадать, где что вылезет.
(125)"По-моему Postgres недооценен в плане работы с 1С."
Судя по работе с 1С - переоценен. Такое количество ошибок, эксклюзивных для данной "СУБД" - это еще надо придумать, как и где словить.
"Уже вот к 100 пользователям подбираемся", моэно и тысячу в справочнике завести, но количество обрабатываемых данных от этого не увеличится.

прошу прощения, я сегодня "в полях", вечером постараюсь подробно ответить на все комментарии

(127) я бы вот хотел получить ТЕОРЕТИЧЕСКОЕ обоснование на заданные вопросы :)
Т.е. суть (смысл) реализации.
Если Вы опять уйдете в "это закрытая информация", хотя о практической части речи не идет - тогда понятно :)

Я не понял, ключ базы, он для одной только базы? Или это как ключ клиента, и баз может быть несколько?

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

НО, поскольку у Вас редкая (для нас) ситуация, мы готовы предложить такой вариант, Вы поможете нам сделать постановку задачи (так как Вы видите реальные условия), а мы ее реализуем. Поскольку ТЖ заявлен собирать планы запросов для постгреса, нам фактически нужна помощь вникнуть в разницу собираемых планов и либо преобразовать формат, либо расширить. Если Вам интересно это, пишите - давайте "сделаем это" :)

(129) Учетная запись для http://www.gilev.ru/querytj/ позволяет мониторить не одну базу как это делает ЦУП, а все информационные базы на этом сервере. В этом преимущество нашего инструмента.

(128) суть этой ветки - проинформировать о бесплатных возможностях сервиса

ваше "я" и "хочу получить" - интересно Вам, но не другим

учитывайте это в своей риторике, мы все таки не рекламируем как софтпоинт платный продукт, а делимся (дарим) наши знания, конвертированные в технологии, можно и спасибо сказать

(126) Я не про справочник говорил, а про реальных одновременно АКТИВНО работающих работающих пользователей.
И объемы, поверьте, немаленькие.

Ну а про ошибки Postgres... и как мы тогда живем, что не наблюдаем их вот уже больше двух лет? Загадка :)

(130) Хм... вы лично мне отвечали, что планы запросов для Postgres делать не будете, по крайней мере бесплатно. Ваша позиция изменилась?

А проблема там, на самом деле, в том, что планы запроса собираются, но их формат отличается от формата MsSQL, и ваш парсер его не понимает.

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

(133) наша позиция изменилась, но не сильно, мы хотим чтобы вы  тоже поучаствовали в этом проекте, как заинтересованное лицо
можем гарантировать, что ваш блок нами продаваться не будет

(126) "а так нельзя определить? " нельзя, но Вы можете попробовать и убедиться лично

(126) "это какие, например?" прямо сейчас посмотрел до чего смог "дотянуться" - УТ 11, Бухгалтерия Предприятия КОРП точно на управляемых блокировках. А что, для Вас это новость?

(134) Не совсем понял, что именно от нас требуется. Доработать клиентскую часть, чтобы она преобразовывала план запроса в формат, аналогичный MsSQL? Или доработать серверную часть? Но она ведь у вас. Или что-то иное?
Можем перейти в почту, адрес у вас должен был остаться.

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

(137) давайте в скайп или почту (мои в профиле)

(137) см. почту, если не ошибся адресом

(140) не ошибся, я уже и ответил

Возвращаюсь к исходной теме: как найти проблемный запрос 1с.
Сервис по умолчанию показывает:
- контекст 1с, т.е. строку кода с чем то вроде Запрос.Выполнить()
- запрос SQL к субд
- план запроса
- параметры запроса

но запросы бывает не всегда просто из SQL назад "сопоставить с запросом 1с", так как они могут собираться динамически и это "неточный" процесс

чтобы решить эту проблему, наш сервис "АПДЕКС" http://www.gilev.ru/apdex/ по мимо классического применения полезен вот чем

для обнаруженного проблемного запроса в http://www.gilev.ru/querytj/ есть закладка "параметры апдекс"
в классическом использовании закладка показывает процент времени исполнения запроса от времени операции, замеряемой по апдексу
это позволяет оценить, насколько потенциально можно ускорить  всю бизнес-операцию, если ускорить этот запрос

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

визуально это можно посмотреть здесь http://gilev.blogspot.ru/2013/03/1.html

(142) можно сказать, что возможность видеть запросы 1с - это тоже преимущество перед платными продуктами

периодически на партнерском форуме возникают вопросы посмотреть размер не просто базы, а таблицы, проранжированные по размерам

не надо упрашивать разработчиков платформы - есть бесплатная возможность в http://www.gilev.ru/sqlsize/

вот примерт такой ветки http://partners.v8.1c.ru/forum/thread.jsp?id=1132703
хотя казалось бы... :)

Тема v8: О чем молчит 1С (хранение оборотного регистра) также решается в http://www.gilev.ru/sqlsize/ , можно время от времени без особых усилий смотреть на количества строк чтобы принять решение нужно ли что то предпринимать для решения (ТиИ и т.п.)

(0) подскажи плз, какие проекты решались вашей командой:
- максимум пользователей
- макс объем ИБ
- макс количество распределенных точек, с указанием периодичности обновления
?

(147) мы не можем публиковать "максимумы", так как большие проекты практически всегда закрытые

максимальные параметры наши проектов существенно больше опубликованных другими фирмами в открытых источниках, есть уверенность, что по многим параметрам мы сделали самые крупные проекты в России и не только

НО... ветка не о том, какие мы молодцы, а про бесплатные инструменты, а рассказать про наши успехи мы готовы в http://www.gilev.ru/forum/viewforum.php?f=14 (там легкая авторизация, поддерживаются социалки)

Хочу рассказать об особенностях клиентской части сервиса, которая лучше поможет понять масштабы, с которыми сталкивались. С картинками эту заметку можно прочитать здесь http://gilev.blogspot.ru/2013/03/blog-post_30.html

Проще говоря, нам пришлось решать очень интересную задачу - а именно обсчитать запросы 5000 пользователей единой информационной базы 1с (не распредленка) http://4.bp.blogspot.com/-sUjlQFgY-ww/UVbsLX0WUII/AAAAAAAAEF0/qGqTXNo1poc/w497-h373/%25D0%259A%25D0%25BE%25D0%25BD%25D1%2581%25D0%25BE%25D0%25BB%25D1%258C+%25D1%2581%25D0%25B5%25D1%2580%25D0%25B2%25D0%25B5%25D1%2580%25D0%25BE%25D0%25B2+-+5474+%25D1%2581%25D0%25B5%25D0%25B0%25D0%25BD%25D1%2581%25D0%25B0+%25D0%25BA%25D1%2580%25D0%25B0%25D1%2582%25D0%25BA%25D0%25BE.jpg . В результате этого проекта появилась "галочка" обсчитывать логи "многопоточно", так как на таких масштабах логи это гигабайты логов, которые попадают к нам через веб-сервис. Поверьте, один обсчет таких логов - это "увлекательное занятие" :)

эх, гугль ужасно ссылки формирует, жуть...

всех с международным днем бэкапа :)

http://www.gilev.info/backupday

правильная ссылка http://www.gilev.info/2013/03/blog-post_31.html

(141) проанализировали присланные материалы, спасибо
в ближайшие недели добавим возможность смотреть планы запроса с постгреса

(0) 500 зарегистрированных тестеров вне компании. Так?
метки.
план в постгри.

С 1 апреля! )

(155) Это хорошо, спасибо :)

(156) ветка начата не 1го апреля

желающие попрактиковаться в чтении планов запросов - добро пожаловать в ветку http://www.gilev.ru/forum/viewtopic.php?f=5&t=125

Вопрос автору
1. «1С-Рарус» — совместное предприятие фирм «1С» и «Рарус», созданное в 1994 году. «1С-Рарус» вроде дочки самой 1С. правда??

(160) http://rarus.ru/company/about/history/ достаточно подробно написано, зачем подобные вопросы задавать в этой ветке, гуглить не пробовали?

(161) Спс
1995 год
Получение предприятием «Рарус» статуса дистрибьютора фирмы «1С» - 1С: Дистрибьютор.

Расширение штата сотрудников до 15 человек.

Принято решение о создании ООО «1С-Рарус» - совместного предприятия фирм «1С» и «Рарус» с равными долями в уставном фонде у каждой стороны.

==============================================

На сайте http://www.gilev.ru/kb/

Рубрика: MS SQL Server, Администрирование, тюнинг    
MS SQL Server 2000 vs 2005 сравнение продуктов для целей эксплуатации 1С:Предприятия 8

слайд № 11
ЗАО ЭНЕРГОПРОМ МЕНЕДЖМЕНТ более 400 польз УПП
ГК Вестер объем базы около 800 ГБ
МТС расчет зп на десятки тысяч сотрудников
Евросеть более 6000 розничных точек

Вопрос
2. Напр возьмем МТС. расчет зп на десятки тысяч сотрудников.
Как это понимать? "Ура, мы смогли в кривой платформе и кривой конфигурации смогли посчитать десятки тысяч зп"
Или "Ура, мы смогли посчитать зп на 386 или 486 машинах"?

3. или другой пример ГК Вестер.
Интересно, в этой базе реальный объем данных какой?
Если побайтно посчитать объем спр + доков + и РС...

(162) http://www.v8.1c.ru/news/newsAbout.jsp?id=1568 было уже достаточно давно, если мне не изменяет память то где то в 2007  привлекался на проект, в те времена база была под террабайт, но имхо если уж говорить об объемах данных, с тех пор у нас были проекты и на более крупные объемы

МТС по причине подписанного NDA обсуждать не будем, хотя проект очень интересный был.

Про евросеть могу сказать просто - она работает :)

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

Обновили сервис "мониторинга производительности информационной системы" http://www.gilev.ru/apdex/

(133) (156) добавили возможность работы с СУБД Postgres, в том числе видеть планы запросов.

примеры веток мисты, где бы мог быть полезен наш сервис

Помогите оптимизировать SQL запрос
v8: MS SQL. как оптимизировать запрос ?
Помогите соптимизировать запрос
v8: Помогите оптимизировать запрос
v8: оптимизировать запрос
v8: Помогите оптимизировать запрос
v8: помогите оптимизировать запрос
v8: Как оптимизировать запрос - долго выполняется
v8: v8: Как оптимизировать запрос?
v8: Оптимизировать запрос
v8: оптимизировать запрос
v8: v8: ЗУП В тесте запроса добавить "Должность". Подскажите как оптимизировать текст запроса?
v8: Помогите оптимизировать запрос!
v8: Помогите переписать (оптимизировать) запрос...
v8: Оптимизировать запрос

(169) а это v8: Работа с технологическим журналом на больших базах
или нет..?

(170) Там видимо успели порезать ветку, так как не очень точно  понятна потребность "для каких задач нужен ТЖ", но если говорить про запросы, то да, наши сервисы этот вопрос закрывают,
и даже если речь идет просто о "событиях" происходящих с участием так или иначе сервера 1С (возникает нехватка лицензий, объектная блокировка при попытке отредактировать документ двумя пользователями и т.п.) то все это можно увидеть в сервисе "Анализа событий ТЖ" http://www.gilev.ru/status/

Даже больше того скажу, если Вы видите что какую то Вашу потребность текущие сервисы не закрывают, Вы скажите нам (например в скайп gilev_slava). Есть высокая вероятность что мы либо уже этот функционал делаем, либо можем сделать. Несколькими постами выше можно убедиться в этом на примере поддержки нашими сервисами Postgre.

(68) Не думаю, что сервисы останутся в таком виде. Как говорится, аппетит приходит во время еды. Планы у нас наполеоновские :)

Можете немножко рассказать о ваших планах?

(0) Может сделать статью в Книге Знаний?

http://kb.mista.ru/

(176) готов сделать статью, но это надо "устаканить размазанное здесь на две сотни постов", чешу затылок :)

(173) немножечко могу

разделить сервисы на:
1) пассивно смотрящие и позволящие делать анализ человеку - они будут бесплатные постоянно
2) корректирующие параметры системы (с разрешения администратора системы)

во вторую категорию пока хочется сделать что то простое:
- регламенты на субд по производительности
- корректировка maxdop и т.п. параметров
- корректировка схемы энергоснабжения
- корректировка нулевых записей
возможно еще что то

для начала...

Три категории должно быть
.
3. Сделать всё.
.
;-0

)))

(167) А можно подробнее, что изменилось?

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

(182) Расширена инструкция http://www.gilev.ru/setupapdex/
описанием возможности логирования запросов (отчет плюс закладка показатели апдекс в http://www.gilev.ru/querytj/)

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

Вячеслав, опишите пожалуйста основные преимущества вашего сервиса перед ЦУПом, помимо цены конечно :)

(184) см. (5)
- показывает запросы платформы (ЦУП не показывает)
- сбор происходит по всем информационным базам сервера (не зависимо от того где субд)
- использует только Технологический Журнал, COM-соединения с базами и других подключений не имеет (в отличии от ЦУП)
- логины и пароли для мониторинга информационных баз не требует и не подключается
- в серверной части можно посмотреть фильтром конкретную базу, а также можно оценить код всех информационных баз посовокупности

(184) см. (131) анализирует все информационные базы на сервере  1с

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

отличительная возможность - это видеть тексты запросов 1с рядом с запросами SQL, контекстом кода для для "особо" подозрительных мест - за счет интеграции с апдекс.

быстрее обсчет собранных данных

выдерживает работу "более" высоконагруженных систем

имеет возможность получить больше детализирующей информации для проблемного запроса (имена таблиц, количество строк в них, дефрагментацию и т.п.)

показывает рядом с запросом превышение норм загруженности железа

требует меньше внимания по контролю места на жестком диске под логи ( в результате падения rphost "не теряются сессии сбора данных" )

не нужно хранить гигабайта данных логов - место на диске "забивается" на нашем сервере

наш сервис больше приспособлен для мониторинга 24х7

более простая и легкая установка
меньше трудозатрат на обслуживание
доступен везде где есть интернет

не надо делать подписку на итс чтобы получить обновление

не для всех преимущество,но все же - при настроенных самостоятельно сервисах скидка на наш аудит составляет 30 000 руб.

Особенно радует фишка с сопоставлением запросов и возможность видеть загрузку железа в момент запроса.
Спасибо за инструмент.

"анализирует все информационные базы на сервере 1с"
Ну тут преимущество довольно спорное
Зачем мне собирать данные с других баз если "тормозит" только одна?
А если баз много, для тестов и прочее.
Будет много лишних логов и мало места на диске и т.д.
Возможно, было бы более гибким решением сделать выбор, собирать данные по каким-то конкретным базам или по всем

(168) Только сбор плана в Oracle не включайте, все встанет колом :)
Не по вине 1с кстати.
Oracle почему-то очень не охотно расстается со своими планами.
Хотя может сейчас уже поправили

(195) есть мнение, что есть долго выполняемые запросы в других базах помимо основной, то они отъедают ресурсы, которые могли быть использованы для основной базы

Да, но ведь обычно разработчик точно знает какая база "тормозит
, и чаще всего дело не в ресурсах, а в коде.
Так зачем собирать лишнюю информацию?
Например, если у меня 10 средненагруженных баз на сервере и я включу тж на сбор информации по запросам, думаю серверу 1С придется туго.

Я лишь решил указать на недостатки вашей системы, и сделать более гибкую настройку.

Ну как говориться дело ваше

(198) если в десяти базах есть к примеру аналитические запросы, каждый из которых длится по две минуты, а суммарно это набегает на 20 минут, то устранив их, мы высвобождаем существенное количество аппаратных ресурсов под основную базу

Если при сборе данных ставить порог к примеру в 18 секунд, это не нагружает сервер, но видны все проблемы.

(0) Сервис - это хорошо, но в итоге все так или иначе упирается в анализ запросов или настройки сервера, что можно произвести и без сервиса.

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

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

(203) есть большие сомнения что надо оптимизировать секундный запрос
что за задача?
скорее тогда алгоритм насилует систему большим количеством ненужных запросов из вашей логики
такое может быть если например рефреш списков каждые 10 секунд  поставить

Имел в практике реальные случаи, когда запросы менее 1сек заваливали I/O так, что дисковая очередь долгое время была значительной. И причина даже не в кривом коде, который с большой частотой выполняется запрос, а например в количестве параллельно выполняемых потоков (сеансов) выполняющих такой код. В наших случаях все крутилось вокруг загрузок данных из внешней системы.

ну т.е. льете в кучу потоков, провоцируете ожидания на блокировках и ожидания ресурсах оборудования, а ответ хотите увидеть в плане запроса?
для этого больше подходят
http://www.gilev.ru/latch/ - для одной базы
http://www.gilev.ru/sqlsize/ - для одной базы и сервера (там и смотрите типы ожиданий)

Добрая тема

(205) прямо сейчас сервис http://www.gilev.ru/wp-content/uploads/2013/02/Снимок83.png обобщенно показывает процент вклада каждого типа ожидания  ( в том число IO ), но в ближайшем будущем сделаем "раскладку" в виде кода 1с

Что за действие (SDBL) HoldConnection?

(209) ответил в ветке http://www.gilev.ru/forum/viewtopic.php?f=9&t=165
просьба технические детали обсуждать там, тут ветка о бесплатных возможностях

Для тех кто хочет "пропитаться" кухней оптимизации 1с, мы начали серию "коротких" заметок, о том какие задачи нам приходится решать при обслуживании сервисов "изнутри" http://www.gilev.info/2013/04/gilevru.html

(211) Пропитался чуток, ждем продолжения.

2я часть http://www.gilev.info/2013/04/gilevru_9.html

помогли решить проблему с взаимоблокировок http://partners.v8.1c.ru/forum/thread.jsp?id=1134033
с помощью сервиса http://www.gilev.ru/deadlock/

Вячеслав, тут пытаемся воспользоваться чудо-сервисом, заходим под моей учеткой на QueryTJ, там, где "Информационная база" ничего не выбирается. Хотя клиентская часть чего-то там вам регулярно сливает.

(215) зарегистрированную учетку вижу, переданных данных нет за все время существования учетки, совет по настройке сервиса дал в ветке http://www.gilev.ru/forum/viewtopic.php?f=3&t=166 (просьба техническую часть обсуждать там)

продолжение истории http://www.gilev.info/2013/04/gilevru_4064.html

продолжение истории http://www.gilev.info/2013/04/gilevru_10.html

(175) сделал первую версию статьи Книга знаний: Бесплатный инструмент анализа проблемных запросов в Информационной системе 8.2

решение некоторых технических вопросов при настройке сервиса разобрано в http://www.gilev.ru/forum/viewtopic.php?f=3&t=65

ну вот мы и дожили до "пределов" сервера (сегодня достигли ограничения по сети),
что то как то быстро этот момент наступил...

по результатам решения отрапортуемся в блоге )

(221) Может сетку гигабитную протянуть?

Я правильно понимаю что инструменты:

http://www.gilev.ru/hardware/ - контроль загруженности оборудования
http://www.gilev.ru/apdex/ - статистика длительности операций

Можно использовать не только для 1с, но и любых других БД на MS SQL?

Насколько оперативно сервис выдает информацию в периоды максимальной нагрузки?

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

(222) то инфостарт, то проекты, все собирался написать

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

(223) да, хардваре при желании можно заюзать и для аксапты, и для сапа, у них тоже не все хорошо бывает ;)

(224) сейчас сервисы получают данные раз в час, мы планируем перепроектировать блок получения данных, но трудозатраты большие, надо на них заработать на обычных проектах сначала )

(223) апдекс в чистом виде - это просто идея замеров, но я плохо представляю как в наш сервис вы будете загонять замеры других приложений, вам придется заново написать клиентскую часть, но задача в принципе реализуемая

перевели сервисы на 8.3.3