Добрый день!

Чтобы найти узкие места в коде, можно воспользоваться онлайн инструментом 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]

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

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

(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