Настройка показателей производительности 1с
Обновлено: 07.07.2024
Сбор технологической информации для расследования проблем производительности и работоспособности с помощью ЦУП с использованием внешней обработки
В процессе эксплуатации информационной системы пользователи могут сталкиваться с различными технологическими проблемами, такими, как проблемы производительности, стабильности и работоспособности. При решении некоторых проблем такого вида может быть полезен Центр управления производительностью (ЦУП) – конфигурация, входящая в состав Корпоративного инструментального пакета (КИП).
Поскольку развертывание ЦУПа в информационной системе клиента не всегда целесообразно, технологическая информация, необходимая для расследования, может быть собрана с помощью внешней обработки с целью дальнейшего анализа с использованием Центра управления производительности.
Обработка AnalyticalIndicatorsGathering_1.0.1.2.epf находится в каталоге EXE\EnterpriseToolsPackage\PerformanceManagementCenter\AnalyticalIndicatorsGathering_1.0.1.2.epf
Порядок использования
Обработка может быть открыта в произвольной информационной базе. Перед первым использованием необходимо выполнить настройку подключения к анализируемой информационной базе.
Настройка подключения и сбора технологического журнала
Для обеспечения возможности сбора информации следует настроить подключение обработки к исследуемой информационной базе, а также настроить сбор технологического журнала. Для этого следует открыть формы настройки, доступные по соответствующим гиперссылкам, заполнить поля формы и нажать кнопку Проверить настройки.
Информация о порядке настройки подключения и сбора технологического журнала доступна во встроенной справке соответствующих форм настройки.
После того как настройки будут выполнены, станет доступным сбор данных. Информация о выполненных настройках сохраняется при закрытии обработки. При следующем открытии выполнять настройку не требуется (при условии, что реквизиты подключения, указанные в процессе настройки, не изменились).
Виды показателей
После того как первичная настройка завершена, необходимо выбрать виды показателей, информация по которым будет собираться.
Доступны следующие виды:
Анализ запросов - Позволяет определить наиболее длительные и частые запросы к серверу СУБД, Анализ серверных вызовов - Позволяет определить наиболее длительные и частые клиент-серверные вызовы, Анализ ожиданий на блокировках 1С - Позволяет определить причины ожиданий на управляемых блокировках, Анализ ожиданий на блокировках СУБД - Позволяет определить причины ожиданий на блокировках СУБД (доступен только информационных баз, работающих под управлением MS SQL Server), Анализ взаимоблокировок 1С - Позволяет определить причины взаимоблокировок на управляемых блокировках, Анализ взаимоблокировок - Позволяет определить причины взаимоблокировок на уровне СУБД в исследуемой информационной базе (доступен только информационных баз, работающих под управлением MS SQL Server)Параметры показателей
При необходимости у пользователя существует возможность уточнить некоторые параметры сбора технологической информации:
Длительность хранения файлов ТЖ - Длительность хранения файлов технологического журнала, указываемая в файле logcfg.xml при включении сбора данных. В случае превышения длительности хранения сервер анализируемой информационной базы автоматически удаляет файлы технологического журнала. Не рекомендуется указывать большое значение, т.к. файлы журналов могут занимать значительный объем. Минимальная длительность серверного вызова - Минимальная длительность запроса, который регистрируется в технологическом журнале. Не рекомендуется указывать слишком маленькое значение, т.к. это значительно увеличит объем журналов и время анализа. Минимальная длительность запроса - Минимальная длительность клиент-серверного вызова, который регистрируется в технологическом журнале. Не рекомендуется указывать слишком маленькое значение, т.к. это значительно увеличит объем журналов и время анализа. Получать планы запросов - Признак получения планов для анализируемых запросов.Сбор данных
После нажатия на кнопку Старт, обработка включает сбор технологической информации. Данные будут собираться до тех пор, пока не будет нажата кнопка Стоп.
Рекомендуется ограничивать длительность сбора информации в зависимости от характера нагрузки исследуемой информационной базы:
При высокой нагрузке (одновременно работает большое количество пользователей либо выполняются тяжелые операции обработки данных) - минимально необходимое время для регистрации проблемы (обычно в пределах нескольких минут, но не более 15 минут), При умеренной нагрузке (одновременно работает небольшое количество пользователей, тяжелые операции обработки данных не выполняются) - время, необходимое для регистрации проблемы, При низкой нагрузке (например, если база тестовая, и активность пользователей отсутствует) - длительность сбора практически не ограниченаПри этом следует учитывать, что фактический сбор данных может начаться чуть позже (с задержкой до одной минуты) в связи с периодичностью чтения настроек рабочими процессами платформы 1С:Предприятие. Также в процессе сбора рекомендуется контролировать размер формируемых журналов (размер каталогов, указанных в настройках обработки).
Выгрузка данных
После завершения сбора данных становится доступной выгрузка собранных данных в произвольный каталог. Для выгрузки следует убедиться, что интересующие замеры выбраны в списке сеансов сбора данных (установлен флаг Выгружать собранные данные), указать каталог экспорта и нажать кнопку Выгрузить.
Важно: Обратите внимание, что собранные данные удаляются из исходных каталогов только после выполнения выгрузки в каталог экспорта либо после удаления замеров из списка сбора данных. Если по каким-либо причинам собранные данные выгружать не требуется, то следует удалить их вручную.
Важно: Обратите внимание, что сбор технологических журналов отключается в момент нажатия кнопки Стоп. Поскольку собираемые технологические журналы могут занимать значительный объем, то в случае нештатного завершения клиента 1С:Предприятия с открытой обработкой, находящейся в режиме сбора данных, необходимо самостоятельно отключить сбор технологических журналов путем ручного внесения изменений в файл logcfg.xml.
Анализ данных в ЦУП
Выгруженные данные могут быть загружены в ЦУП (доступно начиная с версии ЦУП 2.1.3). После завершения загрузки данные становятся доступны для разбора, аналогично данным, собранным с использованием ЦУПа. Результаты разбора могут быть проанализированы с помощью монитора просмотра результатов анализа.
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
Рис. 1
Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
Обычно для 1-10 пользователей выбирается файловый режим
От 10 и более пользователей выбирается режим работы с использованием SQL
В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
Сервер «1С» и СУБД (MS SQL или PostgreSQL)
Как рассчитать мощности сервера для 1С в файловом режиме работы?
В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
Как рассчитать мощности сервера для 1С в варианте работы с SQL?
В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
Неправильный выбор мощностей
Неквалифицированная настройка сервисов виртуальной инфраструктуры
Недостаточное внимание к тестированию производительности платформы «1С»
Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
Существенно сократить расходы
Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
Обеспечить централизованное администрирование и мониторинг
Организовать эффективную и безопасную удаленную работу
Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
Это позволяет ускорить работу таких операций как:
Создание базы данных
Добавление файлов, журналов или данных в существующую базу данных
Увеличение размера существующего файла (включая операции автоувеличения)
Восстановление базы данных или файловой группы
Для включения настройки:
На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
На правой панели дважды кликните Выполнение задач по обслуживанию томов
2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
Для включения настройки:
В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
Разверните узлы Настройки безопасности и Локальные политики
Выберите папку Назначение прав пользователя
Политики будут показаны на панели подробностей
На этой панели дважды кликните параметр Блокировка страниц в памяти
В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
5. Отключить механизм DFSS для дисков.
Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
Чтобы отключить его только для дисков, нужно:
Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
Установить значение параметра EnableFairShare в 0
6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
Чтобы отключить сжатие файлов в каталоге, необходимо:
Открыть свойства каталога
На закладке Общие нажать кнопку Другие
Снять флаг «Сжимать» содержимое для экономии места на диске
7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
Для настройки параметра необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Дополнительно
Установить значение параметра равное единице
8. Ограничить максимальный объем памяти сервера MS SQL Server.
Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Память
Указать значение параметра Максимальный размер памяти сервера
9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
Для установки флага необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Процессоры
Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
10. Установить размер авто увеличения файлов базы данных.
Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
Для установки размера авторасширения необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
Для переноса файлов необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Запомнить имена и расположение файлов
Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
Поставить флаг Удалить соединения и нажать Ок
Открыть Проводник и переместить файл данных и файл журнала на нужные носители
В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
Нажать кнопку Добавить и указать файл mdf с нового диска
В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
12. Вынести файлы базы TempDB на отдельный диск.
Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
Для переноса базы TempDB на отдельный диск необходимо:
Запустить Management Studio и подключиться к нужному серверу
Создать окно запроса и выполнить скрипт:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
Перезапустить MS SQL Server
13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
Для включения Shared Memory необходимо:
Запустить диспетчер конфигурации SQL Server
Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
Поставить значение Да и нажать Ок
Протокол Именованные каналы нужно выключить аналогичным образом
14. Перезапустить службу MS SQL Server
Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
В ходе исследований проблем производительности систем 1С, решил изложить тезисно основные рекомендации, наблюдения, идеи.Так называемый чек-лист, который поможет вам улучшить характеристики производительности вашей системы. А если они уже используются, то еще раз проверить все по пунктам, поскольку при некоторых действиях они могут отключаться. В статье рассматриваются только настройки для СУБД MS SQL Server и ОС Windows Server.
Общие рекомендации по повышению производительности системы.
Включаем на сервере СУБД уровни изоляции транзакций ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT
Данная рекомендация хорошо известна и возможно упоминать о ней не стоило было бы, но без нее статья была бы не полной. Повторение - мать учения.
Этот режим позволяет уменьшить ожидания на блокировках чтения, т.к. чтение в транзакции измененных данных в этом случае не ждут завершения изменяющей транзакции, а читают старую версию, которая была до изменения. Для этого необходимо выполнять следующий скрипт SQL, после каждого перезапуска службы сервера 1С и после обновлений конфигурации информационной базы (т.к. платформа 1С при указанных событиях может отключать необходимый уровень изоляции транзакций):
И да, не стоит сразу бежать проверять, устанавливать данный режим. Если у вас 8.3 без режима совместимости с 8.2, то данный режим включен по умолчанию.
Устраняем эскалацию (укрупнение) блокировок
Для устранения большей части избыточных блокировок на СУБД, связанных с эскалацией, можно попробовать использовать такие методы:
Установить в настройках СУБД параметр LOCKS, вместо 0.
Когда параметр locks установлен в 0, укрупнение блокировки происходит тогда, когда память, используемая текущими структурами блокировки, достигает 40 процентов от пула памяти компонента Компонент Database Engine . Если параметр locks установлен не в значение 0, укрупнение блокировки происходит, когда количество блокировок достигает 40 процентов от значения, указанного для параметра locks.
Включить на сервере СУБД флаг трассировки 1224
Включить можно так:
Этот флаг отключает укрупнение блокировок на основе количества блокировок. Стоит отметить, что чересчур активное использование памяти может включить укрупнение блокировок обратно.
Ищем документы, которые делают более 10000 записей в 1 регистр за 1 раз.
Если при выполнении одной транзакции записывается более 10000 записей в регистр, тогда это приводит к блокировкам этих регистров полностью (эскалации) и нарушает параллельную работу всех пользователей, которые обращаются к данным этих регистров, в момент выполнения этой транзакции. Для устранения проблем с конфликтами блокировок и избыточными ожиданиями, которые возникают в процессе выполнения таких длительных транзакций, необходимо реализовать в коде конфигурации механизм, который будет фиксировать транзакцию с количеством записей, не более чем по 10000 записей за один раз, для исключения эскалации блокировок на сервере 1С и СУБД. В результате такого механизма, будет существенно повышена параллельность работы пользователей во всей информационной базе. Особенно с операциями, которые используют те же регистры.
Повышаем производительность процессора на сервере приложений 1С
Большие таблицы
Одной из причин понижающих производительность системы, являются большие размеры таблиц, к которым происходят запросы. Для того чтобы повысить производительность, нужно стремится максимально уменьшить объем базы и таких таблиц. Следует рассмотреть возможность проведения свертки данных в базе,скорее всего данные прошлых периодов не нужны в оперативной работе. По ним можно свернуть остатки, подробные данные по движениям и истории перенести в архив. В качестве альтернативы свертке данных, можно рассмотреть вариант перепроектировки системы таким образом, чтобы объем данных ,хранимый в таблицах, позволял выполнять запросы с требуемой нам скоростью. Для этого необходимо реализовать механизм оперативных и неоперативных данных. Общий подход должен быть следующим – при записи новых данных в информационную базу, данные должны помещаться в регистры оперативного назначения а по истечении временного органичения (месяц,квартал, год) должны перегружаться в архивные регистры , чем достигается скорость доступа к данным и балансируется нагрузка на сервер. Причем данные неоперативных регистров можно хранить в другой базе данных и на другом сервере. Данные служебных регистров, при этом можно просто очищать от устаревшей информации. При реализации данной концепции, может понадобится модернизировать существующие механизмы конфигурации для возможности получения данных из оперативных и архивных регистров. Данная концепция также позволит существенно сократить объем оперативной базы, повысить скорость работы пользователей, повысить легкость ее обслуживания для регламентных заданий СУБД (Обновление статистики, Перестроение или фрагментация индексов), необходимых для поддержания производительности системы на необходимом уровне.
6. Состояние итогов регистров
Ищем таблицы итогов, в которых хранятся нулевые значения. В таких случаях запросы, использующие такие таблицы для выборок, отбирают большое количество не нужных (нулевых) записей! Пересчет итогов за периоды и текущих итогов позволит ускорить операции записи и чтения итогов.
Пересчет текущих итогов можно осуществлять следующими способами:
С помощью соответствующего пункта «Тестирование и исправление информационной базы» в конфигураторе.
С помощью команды ПересчитатьТекущиеИтоги() встроенного языка для нужных регистров ( в том числе возможна реализация пересчета итогов одновременно по нескольким регистрам и с помощью фоновых или регламентных заданий )
Заполняем реквизиты доступа к ранее созданной БД test:
Указываем учетную запись, под которой будет осуществляться подключение к БД (тут все зависит от ваших предпочтений, доменная или иcпользовать учетную запись MS SQL):
Далее можно, ничего не меняя, нажимать "next". В конце будет итоговое окно:
Нажимаем «Test Data Source» и получаем заветное: "TESTS COMPLETED SUCCESSFULLY!". Как показала практика, наличие этой прекрасной надписи не означает отсутствия проблем в дальнейшем.
Проверяем, что новый источник появился:
Этап II. Настройка счетчиков производительности.
Создаем новый набор счетчиков.
Идём в контрольную панель и вызываем «Administrative Tools» (Control Panel\All Control Panel Items\Administrative Tools)
Открываем «Performance Monitor» и в раздел «User Defined» добавляем новую коллекцию счетчиков:
Выбираем «Create manually (Advanced)»:
Указываем, что мы хотим логировать именно счетчики производительности:
На следующем экране представлены все возможные счетчики. Для примера возьмем один:
В разделе «Processor» есть счетчик «% Processor time». В нижнем списке уточняем, какое ядро хотим мониторить. Для примера выбираем «Total» и нажимаем «Add». Это позволит отслеживать в процентах общую нагрузку по всем ядрам.
Указываем интервал сбора данных. Выбираем, к примеру, 15 секунд.
Далее без изменений, поэтому можно сразу жать "финиш". В итоге получаем набор счетчиков, но он пока не запущен, и запускать его пока что рано.
Перенастраиваем набор на БД MS SQL
Заходим в DataCollector01 и перевыбираем параметр Log format с Binary на SQL
Далее в параметре «Data source name» выбираем созданный в первом разделе провайдер
Идём в настройки New Data Collector Set. На закладке «Schedule» добавляем задание по старту счетчиков на ежедневной основе.
На закладке «Stop Condition» выставляем условия окончания сбора счетчиков. Я выбрал в качестве ограничения размер БД в 10 Гб.
Сохраняем и з апускаем счетчики
Проверяем, что данные начали собираться в БД MS SQL:
Этап III. Получение данных и их обработка в 1С
Теперь нужно получить данные из этой БД и как-то интерпретировать. Для этого нам понадобятся 2 функции:
Подключение к БД:
Получение данных из БД
В описываемом примере используется только 1 счетчик, но на самом деле их может быть много, поэтому сначала получим их список из таблицы [CounterDetails]:
Результат разбиваем на 3 списка (можно одним, но не наглядно):
- Список объектов контроля (ОЗУ, процессор и т.д.) [ObjectName]
- Список счетчиков [CounterName]
- Список экземпляров (Например нагрузку на процессор можно отслеживать в общем, а можно по ядрам) [InstanceName]
В итоге, выбрав нужное значение, в каждом из списков можно получить ID, по которому мы получим данные из таблицы [CounterData]. Помимо ID в условии указываем интервал времени, за который мы хотим получить информацию:
Для построения графика достаточно выбрать CounterDateTime и CounterValue.
В итоге получилась обработка следующего вида.
Для удобства помимо графика на форму выведены таблицы результатов запросов.
Настройки подключения к БД видны на закладке «Настройки». В событии"ПриСозданииНаСервере" можно прописать их автозаполнение
При контроле сервера каждому требуется свой состав счетчиков. Каждый для себя определяет границы счетчиков, превышение которых не желательно (это могут быть рекомендованные показатели или выбранные для себя эмпирически). Чтобы всё это не держать в голове, было принято решение вести в обработке таблицу соответствия:
1. Имя счётчика (в нижнем регистре)
2. Значение которое будет отчерчено на графике зеленой линией
3. Описание счетчика.
Для примера, в обработке заполнил полностью для рассматриваемого счетчика. Результат видно на основном скрин-шоте:
Никаких уникальных технологий не применялось, всё сделано именно на уровне "для чайников", из-за этого кому-то код может показаться "не на уровне". Так что пожелания и к онструктивная критика - приветствуются.
Если где-то описал сумбурно и требуется больше пояснений или кода - готов откорректировать.
Специальные предложения
. мониторить сразу несколько серверов. (4) Самьій главньій тут вопрос - это смотреть данные в динамике.
Я еще собираю статистику по журналу регистрации, ну и счетчики, которые сервер 1с отдает с помощью утилиты rac/ras (отвязался от com, но привязался к 8.3), все это храниться в grpaphite + elasticsearch, ну и отображается с помощью graphana. График в обработке - только визуализация, сделана скорее для демонстрации.
Причина сбора данных в БД:
1. Объем хранимой информации. Например, данные за месяц, необходимых мне счетчиков, в файлах занимают 17 Гб, в БД 3 месяца занимают 6 Гб.
2. При сбоях сервера или при сильной нагрузке наблюдались "пробелы" в файле счетчика. При сборе в БД пока что такой проблемы не обнаружено
3. Использование T-SQL для поиска необходимых данных. Например, сколько раз счетчик превышал заданное значение в течение дня/недели/месяца и тому подобное. Т.е. более гибкий и удобный анализ собранных данных.
4. Можно собирать данные чаще, чем раз в 15 секунд и получить возможность автоматизации реакции на события на сервере.
5. Можно сделать “dashboard” из 10 графиков для мониторинга производительности сервера получая информацию об оперативной памяти, процессоре, латчах или блокировках, или мониторить сразу несколько серверов.
особенно меня радуют статьи "в интернете не нашел, поэтому. " так и хочется спросить сколько секунд искал
теперь по статье - открываете системный монитор действия - свойства - источник - базы данных.
чтобы снимать данные каждую секудну идете рядом в свойствах - общие - элементы диаграммы - съем показаний каждые: 1 секунда
интервал анализируемых данных выбирается свойства - источник - диапазон времени
как говориться без комментариев
про сбои данных полная чушь, точно также данные и в базу могут не попасть
показания можно писать в файлы периодически изменяя файл, чтобы гарантировать целостность большей части данных
при указании нескольких источников точно также можно посмотреть графики с разных серверов
(8) Gilev.Vyacheslav, Суть стаьи не конкурировать с другими сервисами, а показать что и как можно сделать.
Меня не интересует отправка данных на сторонние ресурсы + черный ящик, который не ясно как работает (как минимум по соображениям инф. безопасности) . В нем есть описание счётчиков и обоснование граничных условий? Ссылки на MSDN? + стоимость 10 000 руб. для юр. лиц.
про сбои данных полная чушь, точно также данные и в базу могут не попасть(10) т.е. код так и не посмотрели, но решили порассуждать "не читал, но осуждаю"
похвальный подход, вопросов больше нет
(11) DenIv, именно потому что и наш код, и многие сторонние обработки уже много раз заново изобретались - данная статья нового контекста не несет на мой взгляд
"За пользование своим сервисом вы просите денег. " ну 100 рублей мы просим потому что когда 3 года сервис работал бесплатно, люди настраивали десятки гигабайт в месяц к нам заливать, а при этом не разу не пользовались, поэтому мы сделали скорее психологический барьер чтобы ненужную работу наши сервера не делали, если 100 рублей - это как цуп за 84 000 руб., то готовы взять 1 рубль или даже бесплатно, главное что вы обязуетесь выключить заливку, если не будете заглядывать больше месяца
если уж говорить про сбор счетчиков, уж хотя бы написали бы про подкладывание счетчиков загруженности оборудования в трассировку профайлера, многим лень почитать, хоть новое узнают люди )))
данные за месяц, необходимых мне счетчиков, в файлах занимают 17 ГбЭто какие такие счетчики занимают 17Гб за месяц?! Вы показания вообще всех счетчиков пишете или просто по большому количеству серверов?
Показания 25 основных счетчиков (Система, дисковая, MS SQL) одного сервера за полгода - меньше полутора гигабайта в общей папке скай-драйв - 6 файлов в сутки по 1,6 Мб.
В 08:00 автоматом стартуют, весь день пишутся, после 20:00 выключаются. В случае сбоя - оповещают.
Можно было и в СУБД писать, но скай-драйв по доступности универсальней, в любой момент с любого устройства можно открыть и изучить. А для продвинутого мониторинга есть ЦУП. Это какие такие счетчики занимают 17Гб за месяц?! Вы показания вообще всех счетчиков пишете или просто по большому количеству серверов?
PhysicalDisk(_Total)\% Disk Read Time
PhysicalDisk(_Total)\% Disk Write Time
PhysicalDisk(_Total)\Avg. Disk Bytes/Read
PhysicalDisk(_Total)\Avg. Disk Bytes/Write
PhysicalDisk(_Total)\Current Disk Queue Length
PhysicalDisk(_Total)\Disk Read Bytes/sec
PhysicalDisk(_Total)\Disk Write Bytes/sec
PhysicalDisk(ххх)\Avg. Disk sec/Read по 3-м дискам
PhysicalDisk(ххх)\Avg. Disk sec/Write по 3-м дискам
Processor(_Total)\% Processor Time
Processor(_Total)\DPCs Queued/sec
При наличии 11 дисков и 16 CPU занимает за сутки 390 МБ.
Для продвинутого мониторинга есть много продвинутых систем, например SCOM.А что ЦУП начали раздавать дешевле 100 000 рублей? При наличии 11 дисков и 16 CPU занимает за сутки 390 МБ.
Забавно, я привел статистику с большим числом счетчиков для сервера с 16 CPU (8 аппаратных), 2 массива (9 дисков из которых 6 SSD), счетчики пишутся в двоичный формат раз в 10 сек. Ну и как я уже писал пишутся не нон-стоп, а с 8:00 до 20:00.
Единственный, на мой взгляд, недостаток - пока файл сбора данных не закроется нельзя его открыть для анализа. В этом плане запись в СУБД дает преимущество, можно смотреть данные почти в реальном времени. У вас сколько транзакций? А операций ввода-вывода? Если 1 диск и 1 CPU - то 1 Мб за глаза.
(2) Gilev.Vyacheslav
Вячеслав, стесняюсь спросить: Ваш сервис, разве не по этому же принципу работает? Вы какими мотивами руководствовались когда изобретали свой велосипед?
К чему это негатив? Идея не нова, действительно, но в интернетах, кроме Ваших сервисов, которые собирают по тому же принципу показания, но только в Ваши БД, и ЦУПа, ничего вменяемого БЕСПЛАТНО действительно нет.
Ваш HardwareClient82 - это конфигурация собрал что-то отправил куда-то, получил ответ с истиной. Логика совершенно другая. За пользование своим сервисом вы просите денег.
Здесь все прозрачно, не кофа, а обработка, денег не стоит.
Процитирую. Вас же: - "как говориться без комментариев "
PS. Ваш авторитет в данной области ни у кого не вызывает сомнений, однако, именно поэтому Ваша позиция : все дерьмо я Д`артаньян смотрится как-то странно
(2) h00k ЦИБ - стоит нормальных денег, плюс без подготовки и обучения понять что-то в ЦУПе сложно (ИМХО).
platonov.e; Nikola_N; user792548; igor.ofitserov; ivv1970; shalimski; murat_; Vary; AlexO; Babuin; JohnyDeath; + 11 – Ответить Спасибкi. Однозначно плюс.Можно просто пустую SQL-ую базу создать.
И вместо Com-соединенения использовать внешние источники данных. Единственная неприятность - в таблице CounterData у поля CounterDateTime тип char(24) - это по идее дата + время + миллисекунды замера - там только 23 символа. Приходится во внешнем источнике принудительно указывать 23 символа. ЦКК вроде умеет это делать же? Счетчики я им точно собирал, с графиками, в разных режимах. Так данные тоже пробовал данные собирать, самый прикол - забыл модель базы из фулл в симпл поставить - в считаные часы сожрало все логами. (0) без относительно к велосипеду, но не пойму почему НЕ внешние источники данные, а ADO.DB, судя по интерфейсу у вас уже есть объект внешний источник. И тогда настройка была бы штатной от 1С. (13) lustin, возможно я не правильно понял вопрос, но если речь про объект метаданных, то в таком случае придётся привязываться к определенной конфигурации 1С
научитесь лучше пользоваться SQL Server Profiler
там всё есть. с отборами
Отличная идея.
Однозначно ПЛЮС
Еще бы лучше в настройках и в запросах имя базы.
А то ругается ))
Не запускается сбор, ошибка «Вызов SQLAllocConnect завершился в ошибкой %1»
Журнал показал
Источник PDH, Код события 3041, в описании ошибки вот это:
Вызов SQLAllocConnect завершился с ошибкой [Microsoft][ODBC SQL Server Driver][SQL Server]Ошибка входа пользователя ""…
БД и Сервер на котором запускается сбор, не объединены в домен. Сборщик стартует от имени локальной учетки, как быть?
Читайте также: