System Center — производительность Service Manager

  • Статья

Важно!

Поддержка этой версии Service Manager завершена. Мы рекомендуем выполнить обновление до Service Manager 2022.

Производительность System Center— Service Manager роли и компоненты сервера зависят от различных факторов. Как правило, существует три области, в которых положительные и отрицательные показатели наиболее заметны в Service Manager:

  • Service Manager скорость реагирования консоли. Время, которое проходит от момента, когда будет предпринят какой-либо вид действия в консоли, до момента выполнения этого действия.

  • Время вставки данных для соединителей. Это время, необходимое для импорта данных Service Manager при синхронизации соединителя.

  • Время завершения рабочего процесса. Время, которое затрачивается рабочими потоками на автоматическое применение какого-либо вида действия.

Производительность соединителя

Начальная синхронизация соединителя может занять значительное время; например, от 8 до 12 часов для крупной начальной синхронизации с Configuration Manager. Так как соединитель изначально синхронизируется, вы можете ожидать снижения производительности для всех ролей и процессов сервера Service Manager в течение этого времени. Это происходит из-за способа последовательного вставки данных в базу данных Service Manager, которая является базой данных Microsoft SQL Server. Хотя вы не можете ускорить процесс начальной синхронизации соединителя, вы можете запланировать начальную синхронизацию и убедиться, что процесс синхронизации завершится задолго до того, как Service Manager будет переведен в рабочую среду.

После завершения начальной синхронизации Service Manager продолжит синхронизацию различий, которые не оказывают измеримого влияния на производительность.

Производительность рабочего процесса

Рабочие процессы — это процессы, выполняемые автоматически. К ним относится отправка уведомлений по электронной почте, переход на следующий этап активации запроса на изменение и автоматическое применение шаблона.

Ниже перечислены факторы, влияющие на производительность рабочих процессов.

  • Обычно рабочие процессы начинаются и завершаются в пределах одной минуты. Если Service Manager роли сервера находятся под большой рабочей нагрузкой, рабочие процессы выполняются не так быстро, как обычно.

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

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

Влияние групп, очередей и пользователей на производительность

Следует как можно раньше планировать группы и пользовательские роли. Группы необходимо создавать, исходя из соображений экономии, в том числе создавая их для минимально возможной области. Затем необходимо сначала заполнить базу данных данными из доменные службы Active Directory (AD DS), Configuration Manager и System Center Operations Manager перед созданием групп.

Часто администраторы создают группы, чтобы гарантировать, что пользователи имеют доступ только к указанным группам. Например, в некоем сценарии может потребоваться создать подмножество инцидентов, например инцидентов, влияющих на компьютеры сотрудников отдела кадров. В этом сценарии можно разрешить возможность просмотра или изменения группы конфиденциальных серверов только определенным сотрудникам. Затем, чтобы разрешить такой тип доступа, потребуется создать группу для всех пользователей и группу для конфиденциальных компьютеров, а затем обеспечить доступ роли безопасности к группе всех пользователей и к группе конфиденциальных серверов. Создание группы, содержащей всех пользователей, неизбежно приводит к снижению производительности, так как Service Manager часто проверяет наличие изменений в группе. Такие проверки выполняются по умолчанию каждые 30 секунд. Для большой группы проверка изменений создает большую нагрузку на систему и может значительно замедлить время отклика.

Решение 1. Вы можете вручную указать, как часто Service Manager проверяет наличие групповых изменений, изменив раздел реестра. Например, если задать частоту проверок не каждые 30 секунд, а каждые 10 минут, можно существенно повысить производительность. Тем не менее очереди и цели уровня обслуживания — это специальные типы групп, которые используют один интервал опроса вычисления группы. Таким образом, увеличение значения интервала опроса приводит к увеличению времени для целевых вычислений на уровне очередей и уровня обслуживания.

Внимание!

Неправильное изменение реестра может серьезно повредить систему. Перед внесением изменений следует сделать резервную копию всех ценных данных на компьютере.

Задание интервала проверки изменения группы вручную

  1. Запустите редактор реестра и перейдите в раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Создайте новое значение DWORD с именем GroupCalcPollingIntervalMilliseconds.

  3. Укажите значение интервала в миллисекундах. Результат умножается на 6. Например, чтобы задать интервал в 10 минут, введите 600000.

  4. Перезапустите службу управления System Center.

Решение 2. Вы можете использовать скрипт Windows PowerShell для добавления объектов типа, например Users, в роль пользователя. По сути, аналитик, выполнивший вход с этой ролью, может получить доступ ко всем объектам с типом , равным "Пользователь". Если вы используете этот метод, вы устраняете необходимость в большой группе ("Все пользователи") и дорогостоящие проверка, которые Service Manager выполняет для определения членства в этой группе. На сервере управления Service Manager можно выполнить следующий скрипт Windows PowerShell, чтобы добавить тип user к роли RoleName. Этот пример скрипта необходимо изменить для своей среды.

Запуск сценария Windows PowerShell для добавления объектов в роль пользователя

  • При необходимости измените следующий сценарий, а затем запустите его:
#  
# Insert a "type" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server "put_server_name_here" -RoleName "put display name of the role here" -TypeToAdd "put display name of the type to add to scope here"  
#  
# Note:  This is a simple demonstration script without error checking.   
#   

# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  

$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  

$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   

# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) "User",   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
#  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  

# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  

#   
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}

Просмотр производительности

При создании представлений следует по возможности использовать "типичные" классы в системе. Большинство классов объектов, например Управление инцидентами, имеют два типа: "типичный" и "расширенный". Стандартный тип объекта содержит простые ссылки на небольшое подмножество данных, относящихся к элементу. Расширенный тип содержит много сложных ссылок на данные, относящиеся к элементу. Стандартные типы — это простые проекции, расширенные типы — это сложные проекции. Большинство расширенных типов объектов используются для заполнения различных полей в формах, которые обычно не должны отображаться в представлении. Всякий раз, когда вы создаете представление на основе расширенного типа объекта и открываете представление, Service Manager запрашивает базу данных и считывает большой объем данных. Однако отображается или используется очень мало полученных данных.

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

производительность базы данных Service Manager

На производительность базы данных Service Manager напрямую влияют различные факторы, включая количество одновременных Service Manager консолей, которые считывают или записывают данные, изменение группы проверка интервал и данные, которые вставляются соединителями. В этом документе даются дополнительные сведения. Далее приведено несколько основных моментов.

  • У вас должно быть не менее 8 ГБ ОЗУ для сервера управления, на котором размещена база данных Service Manager, чтобы иметь приемлемое время отклика в типичных сценариях.

  • На компьютере, на котором размещена база данных Service Manager, должно быть не менее 8 ядер ЦП.

  • Можно улучшить производительность, по возможности размещая файлы журналов и файлы данных на разных физических дисках. Вы можете добиться дополнительных преимуществ, переместив базу данных tempdb на физический диск RAID, отличный от физического диска базы данных Service Manager. По возможности следует использовать для размещения базы данных Service Manager дисковую систему RAID 1+0.

  • Производительность может отрицательно повлиять на производительность, если база данных Service Manager создается с меньшим размером и настроена на автоматическое увеличение, особенно с помощью небольших приращений.

Сведения об оценке размера базы данных см. в Service Manager вспомогательном средстве определения размера, который входит в набор документации по Service Manager заданий (SM_job_aids.zip), и создайте базу данных с размером, близким к конечному размеру. Это поможет повысить производительность за счет уменьшения количества операций автоматического увеличения базы данных.

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

Производительность сервера управления Service Manager

На производительность сервера управления Service Manager в первую очередь влияет количество активных одновременно Service Manager консолей. Так как все Service Manager роли взаимодействуют с сервером управления, рекомендуется добавить дополнительные серверы управления, если планируется иметь большое количество параллельных консолей. Для сервера управления требуется 8 ГБ ОЗУ. У вас должно быть не менее 4 ядер ЦП на сервер управления, при условии, что у вас от 10 до 12 активных консолей на каждое ядро ЦП.

Производительность консоли Service Manager

На производительность консоли Service Manager в первую очередь влияет количество форм, открытых аналитиками, и объем данных, извлекаемых представлениями. На компьютере, где установлена консоль Service Manager, необходимо иметь 4 ГБ ОЗУ. Если у вас есть представления, которые извлекают большой объем данных, потребуется дополнительная память. У вас должен быть по крайней мере 4-ядерный ЦП для компьютера, на котором установлена консоль Service Manager. Так как консоль Service Manager является приложением конечного пользователя, рекомендуется перезапустить его, если вы видите чрезмерное потребление ресурсов. Консоль Service Manager активно кэширует сведения в памяти, что может способствовать общему использованию памяти.

Service Manager производительности базы данных хранилища данных

На производительность хранилища данных напрямую влияют различные факторы, включая количество одновременных серверов управления Service Manager, отправляющих данные, объем хранимых данных или период хранения данных, скорость изменения данных, а также частота извлечения, преобразования и загрузки (ETL). Объем данных в хранилище данных со временем возрастает. Важно архивировать ненужные данные. Другим фактором, влияющим на производительность хранилища данных, является значение параметра BatchSize для процессов извлечения, преобразования и загрузки.

Кроме того, производительность можно улучшить, по возможности размещая файлы журналов и файлы данных на разных физических дисках. Тем не менее, следует избегать размещения нескольких файлов журналов на одном диске. Аналогично, можно улучшить производительность, помещая временные файлы базы данных на отдельный от других баз данных физический диск. Наконец, можно получить преимущества от размещения трех разных баз данных на соответствующих физических дисках. По возможности следует использовать для размещения хранилища данных дисковую систему RAID 1+0. В общем, необходимо, чтобы на компьютере, на котором устанавливаются базы данных хранилища данных, было минимум 8 ГБ ОЗУ. При наличии дополнительных источников данных хранилища данных из Operations Manager или Configuration Manager следует увеличить объем ОЗУ для баз данных. Дополнительные преимущества, в том числе связанные с объемом памяти, на компьютере под управлением SQL Server, на котором размещается хранилище данных, можно получить, если разместить базы данных киоска данных и репозитория на том же сервере. Однако если в топологии развертывания имеется не более 4000 компьютеров, достаточно 4 ГБ. Необходимо иметь по крайней мере 8 ядер ЦП на компьютере, на котором установлена база данных хранилища данных. Дополнительные ядра способствуют улучшению производительности извлечения, преобразования и загрузки, а также создания отчетов.

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

Service Manager включает встроенную поддержку файловых групп. Вы можете выиграть от этого, разместив файловые группы на разных жестких дисках. Дополнительные сведения о рекомендациях по файловой группе см. в документации по SQL Server.

Service Manager производительности сервера хранилища данных

На производительность сервера хранилища данных влияет количество серверов управления Service Manager, зарегистрированных в хранилище данных, размер развертывания и количество источников данных. Как правило, для сервера хранилища данных требуется как минимум 8 ГБ ОЗУ. Тем не менее, производительность будет повыситься благодаря дополнительному объему памяти для расширенных сценариев развертывания, в которых несколько серверов управления Service Manager вставляют данные в хранилище данных. Если приходится искать компромиссное решение по производительности, наивысший приоритет следует отдать памяти для сервера SQL Server. Чтобы избежать проблем с производительностью, необходимо иметь по меньшей мере 8 ядер ЦП.

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

Портал Self-Service предназначен для простого доступа к подаче запросов на инциденты и обслуживание. Он не предназначен для одновременной обработки тысяч пользователей.

Тестирование производительности для портала Self-Service было сосредоточено на типичных сценариях с утром в понедельник, чтобы гарантировать, что в понедельник утром сотни пользователей могут войти в систему в течение 5–10 минут и открывать инциденты с приемлемым (менее 4–5 секунд) временем отклика. Эта цель была достигнута с тем минимумом оборудования, который рекомендуется в данном документе.

Целевая производительность уровня обслуживания

Определенное количество целей уровня обслуживания, которые Service Manager поддерживает, не существует. Например, если в организации, как правило, возникает мало инцидентов, количество поддерживаемых целей уровня обслуживания выше нежели в противном случае. Однако чем больший объем инцидентов необходимо поддерживать, тем меньше количество целей уровня обслуживания, либо требуется дополнительное программное обеспечение и оборудование соответственно. Рекомендуется создать не более пяти целей уровня обслуживания для типичной конфигурации 50 000 компьютеров Service Manager. Возможно, в конкретной среде удастся создать больше целей уровня обслуживания. Однако, поскольку условия сильно различаются в разных организациях, корпорация Майкрософт не может предоставить конкретную рекомендацию по количеству целей уровня обслуживания, которые вы не должны превышать. Если в конфигурации развертывания снижается производительность из-за количества целей уровня обслуживания, рекомендуется выполнить горизонтальное масштабирование с помощью следующего более крупного сценария развертывания, как описано в статье Конфигурации для сценариев развертывания этого руководства.

Дальнейшие действия