Обновлено. Добавил новый документ v2.

13.05 - пятница.

Срок ?

Итоговое время остается в пределах 16 часов, само собой.

Понял. Тогда беру время на доработку. Согласны?

Мой комменент к тому что написал Давид:

- Профайлер показывает не только долгий запрос но и где не хватает индексов - это очень важно на мой взгляд

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

- Приложи logcfg как файлик

- Может видос снять ?

- "Хорошо видны" - это плохой аргумент

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

От Пирожкова

Считаю, требует доработки:
1. После первого прочтения я так и не осознал четкий план работы. Хотелось бы его видить. Ну вот я программист, у меня проблема с сервером, какие мои действия прям по списку 1-2-3?

2. Не хватает качетсвенного оформления документа: Единый шрифт и кегль Одинаковое выделение рисунков Титульный лист Содержание Список доп.литературы

3. Какие выводы я должен делать после каждого пункта? Ну увидел я, что диски пишут медлено, и что?

4. Я бы хотел в методике видеть форму документа "Отчет о мониторинге". Чтобы каждый факт мониторинга заканчивался документом, передаваемым клиенту

5. Я хотел бы видеть в документе порядок проведения мониторинга: кто когда и по чьей наводке проводит мониторинг

6. Я хотел бы видеть список компетенций и (или) знаний для работ с мониторингом. В частности, в качестве Списка доп.литературы (см. п. 2)

1. Мной не использованы ни ИТС (только для описания событий по ТЖ), ни КБ. Эта информация с курсов + книги. Профайлер не используется, т.к. в логах ТЖ есть план запроса, который и нужно анализировать.
2. В каждой из глав приведены инструкции по настройке для ручного анализа. Задача была именно, как вручную проделать.
3. По скрипту согласен, нужно приложить. Но моя задача показать, как это можно сделать вручную, чтобы человек понимал и мог в дальнейшем добавить другие счетчики, если будет необходимость. Насчет варианта с СУБД - это уже автоматизация, т.к. просмотреть вручную невозможно без инструмента. А единственный инструмент ОС, который может показать данные, работает по файлам.
4. Логи создавать вручную, ибо то что делает обработка "мусор". logcfg.xml я собираю руками. В документе приложены файлы logcfg.xml, которые были мной сделаны для реальных боевых случаев. Их и нужно использовать.
5. Руками, глазами просмотреть. В файл будут попадать только долгие запросы и они хорошо видны, как и план запроса, как и

Прочитал бегло документ. Мое мнение задача не выполнено должным образом. Доводы:

- Документ сухой и нечитаемый. большинство текста сдернуто с сайта its.1c.ru и kb.1c.ru (хотя ссылок на статьи нету, многие вещи которые есть на сайте kb вовсе не представлены, к примеру, работа с профайлером)

- Работая с этим документом НАУЧИТЬСЯ на мой взгляд невозможно т.к. есть поток букв, но нет пошаговой инструкции для настройки и анализа полного цикла. По мне так просто взята старая инструкция и дополнена без качественной переработки. Странная ситуация - мы и ту инструкцию уже в сверхурочку засунули и эту. Если ошибаюсь - то извиняйте, но по мне надо дорабатывать.

- Нет скрипта автоматического создания логов в perfmon. Показан только режим хранения данных по файлам (а в СУБД - вообще не описан, хотя я считаю что второй вариант - перспективнее)

- Как создавать логи техжурнала ? Вручную ? Для этого есть обработка - в инструкции не увидел ничего.

- Ну допустим определили мы длительные запросы ? Как обработать вручную фай

Мое, не отдам!

Хочу!

Готов взяться