Partilhar via

System Center - desempenho Service Manager

  • Artigo

Importante

Esta versão do Service Manager chegou ao fim do suporte. Recomendamos que atualize para o Service Manager 2022.

Desempenho do System Center - Service Manager funções e funcionalidades do servidor são afetadas por diferentes fatores. Geralmente, existem três áreas em que o desempenho positivo e negativo é mais percetível no Service Manager:

  • Service Manager capacidade de resposta da consola. É o período de tempo decorrido entre a execução e a conclusão de uma ação na consola.

  • Tempo de inserção de dados para os conectores. Este é o tempo que demora Service Manager a importar dados quando um conector é sincronizado.

  • Tempo de conclusão do fluxo de trabalho. É o tempo que os fluxos de trabalho demoram a aplicar automaticamente qualquer tipo de ação.

Desempenho do conector

A sincronização inicial do conector pode demorar muito tempo; por exemplo, 8 a 12 horas para uma grande sincronização inicial com Configuration Manager. À medida que um conector é sincronizado inicialmente, pode esperar que o desempenho sofra em todos os processos e funções de servidor Service Manager durante este período de tempo. Isto ocorre devido à forma como os dados são inseridos sequencialmente na base de dados Service Manager, que é uma base de dados do Microsoft SQL Server. Apesar de não conseguir acelerar o processo de sincronização inicial do conector, pode planear a sincronização inicial e garantir que o processo de sincronização é concluído muito antes de Service Manager ser colocada em produção.

Quando a sincronização inicial estiver concluída, Service Manager continuar a sincronizar as diferenças, que não têm um impacto mensurável no desempenho.

Desempenho do fluxo de trabalho

Os fluxos de trabalho são processos automáticos que se produzem. Eles incluem o envio de notificações por correio eletrónico, o passo seguinte na ativação de um pedido de alteração e a aplicação automática de um modelo.

Entre as considerações sobre o desempenho do fluxo de trabalho incluem-se as seguintes:

  • Normalmente, os fluxos de trabalho começam e terminam num minuto. Quando Service Manager funções de servidor estão numa carga de trabalho pesada, os fluxos de trabalho não são concluídos tão rapidamente como o normal.

  • Além disso, quando se criam novos fluxos de trabalho (tais como uma nova subscrição de notificação), adiciona-se mais carga ao sistema. À medida que o número de novos fluxos de trabalho criados aumenta, o tempo de execução de cada fluxo de trabalho também aumenta.

Quando o sistema está sob uma carga pesada ( se, por exemplo, estiver a ser criado um grande número de novos incidentes e cada incidente gerar muitos fluxos de trabalho), o desempenho poderá ser afetado negativamente.

Impacto da função de grupo, fila e utilizador no desempenho

Os grupos e as funções de utilizador devem ser planeados com antecedência. Os grupos devem ser criados com moderação e de modo a terem o menor âmbito possível. Em seguida, deve preencher inicialmente a base de dados com dados de Active Directory Domain Services (AD DS), Configuration Manager e System Center Operations Manager antes de criar os seus grupos.

Muitas vezes, os administradores criam grupos para garantir que os utilizadores têm acesso apenas a grupos especificados. Por exemplo, num cenário poderá pretender criar um subconjunto de incidentes como aqueles que afetam os computadores que são utilizados pelo pessoal de recursos humanos. Neste cenário, poderá pretender que o grupo de Servidores Sensíveis apenas possa ser visto ou modificado por pessoal específico. Assim, para ativar este tipo de acesso, seria necessário criar um grupo para todos os utilizadores e um grupo para computadores sensíveis e, em seguida, certificar-se de que uma função de segurança tenha acesso aos grupos Todos os Utilizadores e Servidores Sensíveis. Inevitavelmente, a criação de um grupo que contenha todos os utilizadores resulta num impacto no desempenho, uma vez que Service Manager verifica frequentemente para determinar se existem alterações no grupo. Por predefinição, esta verificação acontece a cada 30 segundos. Para um grupo grande, a verificação das alterações cria uma carga pesada no sistema e pode abrandar consideravelmente o tempo de resposta.

Solução 1: pode especificar manualmente a frequência com que Service Manager verifica a existência de alterações de grupo ao modificar uma chave de registo. Por exemplo, se a frequência de verificação de grupos for alterada de 30 segundos para 10 minutos, o desempenho melhora significativamente. No entanto, os objetivos de nível de serviço e de filas são tipos de grupos especiais que utilizam o mesmo intervalo de consulta de cálculo de grupo. Assim, aumentar o valor do intervalo de consulta resulta em tempos mais longos para cálculos de objetivos de nível de serviço e fila.

Atenção

A edição incorreta do registo poderá danificar gravemente o sistema. Antes de efetuar alterações no registo, deve criar uma cópia de segurança de todos os dados importantes existentes no computador.

Para especificar manualmente o intervalo de verificação de alterações em grupos

  1. Execute Regedit e navegue para HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Crie um novo valor DWORD com o nome GroupCalcPollingIntervalMilliseconds.

  3. Para definir esse valor, especifique o intervalo em milésimos de segundo. O resultado é multiplicado por 6. Por exemplo, para definir o intervalo como 10 minutos, introduza 600000.

  4. Reinicie o serviço de Gestão do System Center.

Solução 2: pode utilizar um script Windows PowerShell para adicionar objetos de um tipo, como "Utilizadores", a uma função de utilizador. Essencialmente, um analista com sessão iniciada nesta função pode aceder a todos os objetos que tenham um tipo igual a "Utilizador". Se utilizar este método, elimina a necessidade de um grupo grande ("Todos os Utilizadores") e a verificação dispendiosa que Service Manager efetua para determinar a associação a este grupo. No servidor de gestão Service Manager, pode executar o seguinte script Windows PowerShell para adicionar o tipo de "utilizador" a uma função "RoleName". Tem de modificar este script de exemplo para o seu ambiente.

Para executar um script do Windows PowerShell de modo a adicionar objetos a uma função de utilizador

  • Modifique o seguinte script conforme necessário e, em seguida, execute-o:
#  
# 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."  
}

Ver desempenho

Quando criar vistas, planeie utilizar classes "típicas" no sistema sempre que possível. A maioria das classes de objetos, por exemplo, Gestão de Incidentes tem dois tipos: "típico" e "avançado". O tipo de objeto típico contém referências simples a um pequeno subconjunto de dados relacionados com um item. O tipo avançado contém várias referências complexas a dados relacionados com um item. Os tipos típicos são projeções simples e os tipos avançados são projeções complexas. A maioria dos tipos de objetos avançados são utilizados para preencher diferentes campos em formulários que normalmente não pretende ver apresentados numa vista. Sempre que criar uma vista com base num tipo de objeto avançado e quando abrir a vista, Service Manager consulta a base de dados e é lida uma grande quantidade de dados. No entanto, muito pouco dos dados obtidos é apresentado ou utilizado.

Se encontrar problemas de desempenho com as vistas que definiu quando utiliza tipos de objeto avançados nas vistas, mude para utilizar tipos típicos. Em alternativa, pode criar os seus próprios tipos de projeção que contenham apenas os dados em que precisa para basear uma vista.

desempenho da base de dados Service Manager

O desempenho da base de dados Service Manager é diretamente afetado por vários fatores, incluindo o número de consolas de Service Manager simultâneas que estão a ler ou a escrever dados, o intervalo de verificação de alterações de grupo e os dados inseridos pelos conectores. Este documento inclui mais informações. Eis alguns pontos chave:

  • Deve ter um mínimo de 8 gigabytes (GB) de RAM para o servidor de gestão que aloja a base de dados Service Manager, para que possa ter um tempo de resposta aceitável em cenários típicos.

  • Deve ter, pelo menos, 8 núcleos de CPU no computador que aloja a base de dados Service Manager.

  • É possível melhorar o desempenho da base de dados mantendo os ficheiros de registo separados dos ficheiros de dados em discos físicos diferentes, se possível. Pode obter mais benefícios ao mover a tempdb para uma unidade RAID física diferente da da base de dados Service Manager. Utilize um sistema de discos RAID 1+0 para alojar a base de dados Service Manager, se possível.

  • O desempenho pode ser afetado negativamente se a base de dados de Service Manager for criada com um tamanho mais pequeno e estiver definida como crescimento automático, especialmente por pequenos incrementos.

Veja a ferramenta auxiliar de dimensionamento Service Manager incluída no conjunto de documentação Service Manager auxiliares de trabalho (SM_job_aids.zip) para obter ajuda na avaliação do tamanho da base de dados e crie a base de dados com um tamanho mais próximo do tamanho final. Isto ajudará no desempenho ao reduzir o número de vezes que a base de dados tem de aumentar automaticamente.

Da mesma forma, todas as outras melhores práticas para uma base de dados de alto desempenho também são aplicáveis. Por exemplo, se puder tirar partido de um subsistema de disco superior, pode beneficiar de dividir os grupos de tabelas nos respetivos grupos de ficheiros e movê-los para uma unidade física diferente.

desempenho do servidor de gestão Service Manager

O desempenho do servidor de gestão Service Manager é principalmente afetado pelo número de consolas de Service Manager simultâneas ativas. Uma vez que todas as funções Service Manager interagem com o servidor de gestão, considere adicionar servidores de gestão adicionais se planear ter um grande número de consolas simultâneas. Deverá ter 8 GB de RAM para o servidor de gestão. Deve ter, pelo menos, 4 núcleos de CPU por servidor de gestão, partindo do princípio de que tem 10 a 12 consolas ativas por núcleo de CPU.

desempenho da consola do Service Manager

O desempenho da consola Service Manager é principalmente afetado pelo número de formulários que os seus analistas normalmente têm abertos e pela quantidade de dados obtidos pelas vistas. Deverá ter 4 GB de RAM no computador onde está instalada a consola do Service Manager. Se tiver vistas que obtenham uma grande quantidade de dados, precisará de RAM adicional. Deve ter, pelo menos, uma CPU de 4 núcleos para o computador onde está instalada a consola do Service Manager. Uma vez que a consola Service Manager é uma aplicação de utilizador final, recomendamos que a reinicie se vir um consumo excessivo de recursos. A consola de Service Manager coloca informações agressivamente em cache na memória, o que pode contribuir para a utilização geral da memória.

Service Manager desempenho da base de dados do armazém de dados

O desempenho do armazém de dados é diretamente afetado por vários fatores, incluindo o número de servidores de gestão de Service Manager simultâneos que enviam dados, o volume de dados armazenados ou o período de retenção de dados, a taxa de alteração de dados e a frequência de extração, transformação e carga (ETL). A quantidade de dados armazenados no armazém de dados aumenta com o passar do tempo. É importante garantir que não se arquivam dados desnecessários. Outro fator que afeta o desempenho do armazém de dados é a definição BatchSize dos processos de ETL.

É possível melhorar o desempenho mantendo os ficheiros de registo separados dos ficheiros de dados em discos físicos diferentes. No entanto, não se deve colocar mais do que um registo de ficheiro por disco. Da mesma forma, é possível melhorar o débito colocando a tempdb num disco físico diferente daquele onde se encontram as outras bases de dados. Por último, também pode ser vantajoso colocar as diferentes bases de dados nos respetivos discos físicos. Utilize um sistema de discos RAID 1+0 para alojar o armazém de dados, se possível. Geralmente, deve ter um mínimo de 8 GB de RAM para o computador onde as bases de dados do armazém de dados estão instaladas. Se tiver origens de dados do armazém de dados adicionais do Operations Manager ou Configuration Manager, deve aumentar a quantidade de RAM para as bases de dados. Irá beneficiar de mais memória no computador que executa SQL Server que aloja o armazém de dados e ainda mais se as bases de dados Datamart e Repository estiverem no mesmo servidor. No entanto, se tiver 4000 ou menos computadores na topologia de implementação, 4 GB é suficiente. É necessário ter pelo menos 8 núcleos de CPU no computador em que a base de dados do armazém de dados está instalada. A existência de núcleos adicionais melhorará o desempenho de ETL e dos relatórios.

O desempenho pode ser afetado negativamente se todas as bases de dados no sistema forem criadas com uma dimensão mais pequena e definidas para a opção AutoGrow, especialmente se for por pequenos incrementos. Veja a ferramenta Auxiliar de Dimensionamento Service Manager que está incluída no conjunto de documentação Service Manager auxiliares de trabalho (SM_job_aids.zip) para avaliar o tamanho da base de dados e criar a base de dados com um tamanho mais próximo do tamanho final, o que ajudará a melhorar o desempenho ao reduzir o número de vezes que a base de dados tem de aumentar automaticamente.

Service Manager inclui suporte incorporado para grupos de ficheiros. Pode tirar partido disto ao colocar os grupos de ficheiros em discos rígidos separados. Para obter mais informações sobre as melhores práticas do grupo de ficheiros, veja a documentação do SQL Server.

Service Manager desempenho do servidor do armazém de dados

O desempenho do servidor do armazém de dados é afetado pelo número de servidores de gestão de Service Manager registados no armazém de dados, pelo tamanho da implementação e pelo número de origens de dados. Geralmente, deve ter um mínimo de 8 GB de RAM para o servidor do armazém de dados. No entanto, o desempenho beneficiará de memória adicional para cenários de implementação avançada em que mais de um servidor de gestão de Service Manager insere dados no armazém de dados. Se tiver de trocar o desempenho, a sua prioridade mais alta deve ser a memória do computador que está a executar SQL Server. É necessário ter pelo menos 8 núcleos de CPU para evitar problemas de desempenho.

Desempenho do portal Self-Service

O Portal do Self-Service foi concebido para facilitar o acesso ao registo de incidentes e pedidos de serviço. Não foi concebido para processar milhares de utilizadores em simultâneo.

Os testes de desempenho para o Portal do Self-Service concentraram-se em cenários típicos de "segunda-feira de manhã", especificamente, para garantir que, na manhã de segunda-feira, centenas de utilizadores podem iniciar sessão num intervalo de 5 a 10 minutos e abrir incidentes com tempos de resposta aceitáveis (menos de 4 a 5 segundos). O objetivo foi atingido com o hardware mínimo recomendado neste documento.

Desempenho do objetivo ao nível do serviço

Não existe um número específico de objetivos de nível de serviço suportados pelo Service Manager. Por exemplo, se uma organização tiver normalmente poucos incidentes, pode suportar mais objetivos de nível de serviço do que poderia ser capaz de fazer de outra forma. No entanto, um volume de incidentes maior pode necessitar de menos objetivos de nível de serviço ou de um aumento horizontal de hardware e software adicionais, conforme adequado. Recomendamos que não crie mais do que cinco objetivos de nível de serviço para uma configuração típica de 50 000 computadores Service Manager. Possivelmente, pode criar mais objetivos de nível de serviço. No entanto, uma vez que as condições variam muito de organização para organização, a Microsoft não pode fornecer uma recomendação concreta para o número de objetivos de nível de serviço que não deve exceder. Se a configuração da implementação sofrer de um fraco desempenho devido ao número de objetivos ao nível do serviço, recomendamos que aumente horizontalmente com o cenário de implementação de maior dimensão seguinte, conforme descrito no artigo Configurações para Cenários de Implementação deste guia.

Passos seguintes