Partilhar via

System Center - Desempenho do Service Manager

O desempenho das funções e recursos de servidor do System Center - Service Manager é afetado por diferentes fatores. Geralmente, há três áreas onde o desempenho positivo e negativo é mais percetível no Service Manager:

  • Capacidade de resposta do console do Service Manager. Este é o período de tempo que leva desde o momento em que você executa algum tipo de ação no console até que ele seja concluído.

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

  • Tempo de conclusão do fluxo de trabalho. Este é o período de tempo que os fluxos de trabalho levam para aplicar automaticamente algum tipo de ação.

Este artigo descreve como o desempenho das funções e recursos de servidor do System Center - Service Manager é afetado por diferentes fatores.

Desempenho do conector

A sincronização inicial do conector pode levar uma quantidade significativa de tempo; por exemplo, 8 a 12 horas para uma grande sincronização inicial com o Configuration Manager. À medida que um conector é inicialmente sincronizado, é de esperar que o desempenho diminua para todas as funções e processos do servidor do Service Manager durante esse período. Isso ocorre devido à maneira como os dados são inseridos sequencialmente no banco de dados do Service Manager, que é um banco de dados do Microsoft SQL Server. Embora não seja possível apressar o processo de sincronização inicial do conector, pode planear essa sincronização inicial e assegurar que o processo seja concluído bem antes de o Service Manager ser colocado em produção.

Quando a sincronização inicial estiver concluída, o Service Manager continuará sincronizando 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 ocorrem. Eles incluem o envio de notificações por e-mail, a próxima etapa da ativação de uma solicitação de alteração e a aplicação automática de um modelo.

As considerações de desempenho do fluxo de trabalho incluem o seguinte:

  • Normalmente, os fluxos de trabalho começam e terminam dentro de um minuto. Quando as funções de servidor do Service Manager estão sob uma carga de trabalho pesada, os fluxos de trabalho não são concluídos tão rapidamente quanto o normal.

  • Além disso, quando você cria novos fluxos de trabalho, como uma nova assinatura de notificação, uma carga adicional é colocada no sistema. À medida que o número de novos fluxos de trabalho criados aumenta, o tempo necessário para a execução de cada fluxo de trabalho também aumenta.

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

Impacto do grupo, da fila e da função de usuário no desempenho

Você deve planejar grupos e funções de usuário com antecedência. Você deve criar grupos com moderação e criá-los para o menor escopo possível. Em seguida, você deve preencher inicialmente seu banco de dados com dados dos Serviços de Domínio Ative Directory (AD DS), do Configuration Manager e do System Center Operations Manager antes de criar seus grupos.

Muitas vezes, os administradores criam grupos para garantir que os usuários tenham acesso apenas a grupos especificados. Por exemplo, em um cenário, talvez você queira criar um subconjunto de incidentes, como incidentes que afetam computadores usados por pessoal de recursos humanos. Nesse cenário, talvez você queira que apenas pessoal específico possa exibir ou modificar o grupo de Servidores Confidenciais. Em seguida, para habilitar esse tipo de acesso, você precisará criar um grupo para todos os usuários e um grupo para computadores confidenciais e, em seguida, garantir que uma função de segurança tenha acesso aos grupos Todos os Usuários e Servidores Confidenciais. Inevitavelmente, a criação de um grupo contendo todos os usuários resulta em impacto no desempenho porque o Service Manager frequentemente verifica se há alterações no grupo. Essa verificação ocorre uma vez a cada 30 segundos, por padrão. Para um grupo grande, a verificação das alterações cria uma carga pesada no sistema e pode diminuir consideravelmente o tempo de resposta.

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

Atenção

A edição incorreta do registo pode danificar gravemente o seu sistema. Antes de fazer alterações no Registro, você deve fazer backup de todos os dados valiosos no computador.

Especificar manualmente o intervalo de verificação de alteração de grupo

Para especificar manualmente o intervalo de verificação de alteração de grupo, siga estas etapas:

  1. Execute o Regedit e navegue até HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Crie um novo valor DWORD chamado GroupCalcPollingIntervalMilliseconds.

  3. Para seu valor, especifique o intervalo em milissegundos. O resultado é multiplicado por 6. Por exemplo, para definir o intervalo para 10 minutos, digite 600000.

  4. Reinicie o serviço System Center Management.

Solução 2: Você pode usar um script do Windows PowerShell para adicionar objetos de um tipo, como "Usuários", a uma função de usuário. Essencialmente, um analista conectado nessa função pode acessar todos os objetos que têm um tipo igual a "Usuário". Se você usar esse método, eliminará a necessidade de um grupo grande ("Todos os usuários") e a verificação dispendiosa que o Service Manager executa para determinar essa associação ao grupo. No servidor de gerenciamento do Service Manager, você pode executar o seguinte script do Windows PowerShell para adicionar o tipo "usuário" a uma função "RoleName". Você precisa modificar este script de exemplo para seu ambiente.

Executar um script do Windows PowerShell para adicionar objetos a uma função de usuário

  • Modifique o seguinte script conforme necessário e 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

Ao criar modos de exibição, planeje usar classes "típicas" no sistema sempre que possível. A maioria das classes de objetos - por exemplo, Gerenciamento 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 a um item. O tipo avançado contém muitas referências complexas a dados relacionados a um item. Os tipos típicos são projeções simples; Os tipos avançados são projeções complexas. A maioria dos tipos de objeto avançados são usados para preencher campos diferentes em formulários que normalmente não se gostaria de ver exibidos em uma visualização. Sempre que você cria um modo de exibição com base em um tipo de objeto avançado e quando você abre o modo de exibição, o Service Manager consulta o banco de dados e uma grande quantidade de dados é lida. No entanto, muito pouco dos dados recuperados é exibido ou usado.

Se você encontrar problemas de desempenho com os modos de exibição definidos ao usar tipos de objeto avançados em modos de exibição, alterne para o uso de tipos típicos. Como alternativa, você pode criar seus próprios tipos de projeção que contêm apenas os dados nos quais você precisa basear uma exibição.

Desempenho do banco de dados do Service Manager

O desempenho do banco de dados do Service Manager é diretamente afetado por vários fatores, incluindo o número de consoles simultâneos do Service Manager que estão lendo ou gravando dados, o intervalo de verificação de alteração de grupo e os dados inseridos pelos conectores. Mais informações estão disponíveis neste documento. Aqui estão alguns pontos-chave:

  • Você deve ter um mínimo de 8 gigabytes (GB) de RAM para o servidor de gerenciamento que hospeda o banco de dados do Service Manager para que possa ter um tempo de resposta aceitável em cenários típicos.

  • Você deve ter pelo menos 8 núcleos de CPU no computador que hospeda o banco de dados do Service Manager.

  • Você pode obter um melhor desempenho do banco de dados segregando arquivos de log e arquivos de dados para separar discos físicos, se possível. Você pode obter mais benefícios movendo seu tempdb para uma unidade RAID física diferente da do banco de dados do Service Manager. Use um sistema de disco RAID 1+0 para hospedar seu banco de dados do Service Manager, se possível.

  • O desempenho pode ser afetado negativamente se o banco de dados do Service Manager for criado com um tamanho menor e estiver configurado para crescimento automático, especialmente por pequenos incrementos.

Consulte a ferramenta Auxiliar de Dimensionamento do Service Manager incluída no conjunto de documentação de ajudas de trabalho do Service Manager (SM_job_aids.zip) para obter ajuda na avaliação do tamanho da base de dados e criar a base de dados com um tamanho mais próximo do tamanho final. Isso ajudará o desempenho, reduzindo o número de vezes que o banco de dados precisa crescer automaticamente.

Da mesma forma, todas as outras práticas recomendadas para um banco de dados de alto desempenho também são aplicáveis. Por exemplo, se você puder tirar proveito de um subsistema de disco superior, poderá se beneficiar da divisão dos grupos de tabelas nos respetivos grupos de arquivos e movê-los para uma unidade física diferente.

Desempenho do servidor de gerenciamento do Service Manager

O desempenho do servidor de gerenciamento do Service Manager é afetado principalmente pelo número de consoles do Service Manager simultâneos ativos. Como todas as funções do Service Manager interagem com o servidor de gerenciamento, considere adicionar servidores de gerenciamento adicionais se você planeja ter um grande número de consoles simultâneos. Você deve ter 8 GB de RAM para o servidor de gerenciamento. Você deve ter pelo menos 4 núcleos de CPU por servidor de gerenciamento, supondo que tenha de 10 a 12 consoles ativos por núcleo de CPU.

Desempenho do Service Manager Console

O desempenho do Service Manager Console é afetado principalmente pelo número de formulários que seus analistas normalmente têm abertos e pela quantidade de dados recuperados pelas exibições. Você deve ter 4 GB de RAM no computador onde o Service Manager Console está instalado. Se você tiver visualizações que recuperam uma grande quantidade de dados, precisará de RAM adicional. Você deve ter pelo menos uma CPU de 4 núcleos para o computador onde o Service Manager Console está instalado. Como o Service Manager Console é um aplicativo de usuário final, recomendamos reiniciá-lo se vir um consumo excessivo de recursos. A consola do Service Manager armazena informações em memória cache de forma agressiva, o que pode contribuir para a utilização global da memória.

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

O desempenho do data warehouse é diretamente afetado por vários fatores, incluindo o número de servidores de gerenciamento simultâneos do Service Manager enviando 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 tempo. É importante garantir o arquivamento de dados desnecessários. Outro fator que afeta o desempenho do data warehouse é a configuração BatchSize dos processos ETL.

Você pode obter um melhor desempenho segregando arquivos de log e arquivos de dados para separar discos físicos. No entanto, você deve evitar colocar mais de um arquivo de log por disco. Da mesma forma, você pode obter uma melhor taxa de transferência colocando o tempdb em um disco físico diferente dos outros bancos de dados. Por fim, você também pode se beneficiar colocando os diferentes bancos de dados em seus respetivos discos físicos. Use um sistema de disco RAID 1+0 para hospedar seu data warehouse, se possível. Geralmente, você deve ter um mínimo de 8 GB de RAM para o computador onde os bancos de dados do data warehouse estão instalados. Se você tiver fontes de dados de data warehouse adicionais do Operations Manager ou do Configuration Manager, deverá aumentar a quantidade de RAM para os bancos de dados. Você se beneficiará de mais memória no computador que executa o SQL Server que hospeda o data warehouse, e ainda mais se os bancos de dados Datamart e Repository estiverem no mesmo servidor. No entanto, se você tiver 4.000 ou menos computadores em sua topologia de implantação, 4 GB é suficiente. Você deve ter pelo menos 8 núcleos de CPU no computador onde o banco de dados do data warehouse está instalado. Núcleos adicionais ajudarão tanto o desempenho das operações ETL quanto dos relatórios.

O desempenho pode ser afetado negativamente se todos os bancos de dados do sistema forem criados com um tamanho menor e configurados para crescimento automático, especialmente por pequenos incrementos. Consulte a ferramenta Auxiliar de Dimensionamento do Service Manager incluída nas ferramentas de apoio de documentação na secção do Service Manager (SM_job_aids.zip) para avaliar o tamanho do banco de dados e criar o banco de dados com um tamanho mais próximo do tamanho final, o que ajudará o desempenho reduzindo o número de vezes que o banco de dados precisa de autoexpansão.

O Service Manager inclui suporte interno para grupos de arquivos. Você pode se beneficiar disso colocando os grupos de arquivos em discos rígidos separados. Para obter mais informações sobre as práticas recomendadas de grupo de arquivos, consulte a documentação do SQL Server.

Desempenho do servidor de data warehouse do Service Manager

O desempenho do servidor de data warehouse é afetado pelo número de servidores de gerenciamento do Service Manager registrados no data warehouse, pelo tamanho da implantação e pelo número de fontes de dados. Geralmente, você deve ter um mínimo de 8 GB de RAM para o servidor de data warehouse. No entanto, o desempenho será beneficiado por ter memória adicional para cenários de implantação avançados em que mais de um servidor de gerenciamento do Service Manager insere dados no data warehouse. Se você precisar trocar o desempenho, sua prioridade mais alta deverá ser a memória do computador que executa o SQL Server. Você deve ter pelo menos 8 núcleos de CPU para evitar problemas de desempenho.

Desempenho do portal de autoatendimento

O Portal Self-Service foi concebido para facilitar o acesso ao registo de incidentes e pedidos de serviço. Ele não foi projetado para lidar com milhares de usuários simultaneamente.

Os testes de desempenho para o Portal Self-Service foram focados em cenários típicos de "manhã de segunda-feira", especificamente, para garantir que na manhã de segunda-feira centenas de usuários possam entrar em um período de 5 a 10 minutos e abrir incidentes com tempos de resposta aceitáveis (menos de 4 a 5 segundos). Este objetivo foi alcançado com o hardware mínimo recomendado neste documento.

Desempenho dos objetivos ao nível de serviço

Não há um número específico de objetivos de nível de serviço suportados pelo Service Manager. Por exemplo, se uma organização normalmente tem poucos incidentes, ela pode oferecer suporte a mais objetivos de nível de serviço do que seria capaz de fazer de outra forma. No entanto, um volume maior de incidentes pode exigir menos objetivos de nível de serviço ou uma expansão de hardware e software adicionais, conforme apropriado. Recomendamos que você crie não mais do que cinco objetivos de nível de serviço para uma configuração típica do Service Manager de 50.000 computadores. Você poderia criar mais objetivos de nível de serviço. No entanto, como 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 você não deve exceder. Se sua configuração de implantação sofrer um desempenho insatisfatório como resultado do número de objetivos de nível de serviço, recomendamos que você expanda usando o próximo cenário de implantação maior, conforme descrito no artigo Configurações de para cenários de implantação deste guia.

Próximos passos

Para saber mais sobre as configurações de hardware e software para cenários de implantação do Service Manager, consulte Cenários de topologia de implantação recomendados.