Configuration Manager perguntas frequentes sobre dimensionamento e desempenho do site

Separe as caixas de entrada Configuration Manager e SQL Server arquivos em pelo menos dois volumes diferentes. Essa separação permite otimizar os tamanhos de alocação de cluster para os diferentes tipos de E/S executados.

Para o volume que hospeda as caixas de entrada do servidor de sites, use NTFS com unidades de alocação 4K ou 8K. O ReFS grava 64k mesmo para arquivos pequenos. Configuration Manager tem muitos arquivos pequenos, portanto, o ReFS pode produzir sobrecarga de disco desnecessária.

Para discos que contêm SQL Server arquivos de banco de dados, use a formatação NTFS ou ReFS, com unidades de alocação de 64K.

Matrizes modernas de unidades de estado sólido (SSD) e Armazenamento Premium do Azure podem fornecer IOPS alto em um único volume, com poucos discos. Normalmente, você adiciona mais unidades a uma matriz para armazenamento adicional, não taxa de transferência adicional. Se você estiver usando discos físicos baseados em fuso, talvez precise de mais IOPS do que pode gerar em um único volume. Você deve alocar 60% do total recomendado de IOPS e espaço em disco para o arquivo .mdf , 20% para o arquivo .ldf e 20% para os arquivos temporários de log e dados. Os arquivos .ldf e temp podem residir em um único volume com 40% (20% + 20%) do IOPS alocado.

SQL Server versões anteriores a SQL Server 2016 criadas por padrão apenas um arquivo de dados temporário. Você deve criar mais, para evitar SQL Server bloqueios e aguardar o acesso a um único arquivo. As opiniões da comunidade variam no melhor número de arquivos de dados temporários a serem criados, de quatro a oito. O teste revela pouca diferença entre quatro e oito, para que você possa criar quatro arquivos de dados temporários igualmente dimensionados . Seus arquivos de dados tempdb devem ter até 20 a 25% do tamanho do banco de dados completo.

Quando configurável, defina a memória do controlador RAID como 70% de alocação para operações de gravação e 30% para operações de leitura. Em geral, use uma configuração de matriz RAID 10 para o banco de dados do site. O RAID 1 também é aceitável para sites de pequena escala com requisitos de E/S baixos ou se você usar SSDs rápidos. Com matrizes de disco maiores, configure discos de reposição para substituir automaticamente discos com falha.

Exemplo: Máquina física com discos físicos

As diretrizes de dimensionamento de um servidor de site colocated e SQL Server com 100.000 clientes são 1200 IOPS para caixas de entrada do servidor de site e 5.000 IOPS para arquivos SQL Server.

Sua configuração de disco resultante pode parecer:

1. Não inclui discos sobressalentes recomendados.
2. Esse valor é de configurações de disco de exemplo.

O Hyper-V oferece desempenho semelhante a um servidor físico, se os recursos de hardware (núcleos de CPU e armazenamento de passagem) forem 100% dedicados à máquina virtual (VM). Usar arquivos de disco .vhd ou .vhdx de tamanho fixo causa um impacto mínimo de desempenho de E/S de 1 a 5%. O uso de arquivos de disco .vhd ou .vhdx em expansão dinâmica causa até 25% de impacto no desempenho de E/S para a carga de trabalho Configuration Manager. Se você precisar expandir dinamicamente discos, compense a adição de um desempenho adicional de IOPS de 25% à matriz.

Ao executar seu servidor de site Configuration Manager ou SQL Server dentro de uma VM, isole as unidades do sistema operacional host Hyper-V do sistema operacional da VM e das unidades de dados.

Para obter mais informações sobre como otimizar VMs, consulte Ajuste de desempenho de servidores Hyper-V.

Exemplo: servidor de site baseado em VM do Hyper-V

As diretrizes de dimensionamento para um servidor de site colocated e SQL Server com 150.000 clientes são 1800 IOPS para caixas de entrada do servidor de site e 7400 IOPS para arquivos SQL Server.

Sua configuração de disco resultante pode parecer:

1. Não inclui discos sobressalentes recomendados.
2. Tamanho fixo, passagem .vhdx para a unidade de VM dedicada ao volume subjacente.
3. Esse valor é de configurações de disco de exemplo.

Comece lendo o Configuration Manager em perguntas frequentes do Azure.

VMs iaaS (infraestrutura do Azure como serviço) que aproveitam discos baseados em Armazenamento Premium podem ter IOPS alto. Nessas VMs, configure discos adicionais para necessidades de espaço em disco antecipadas, em vez de para IOPS adicional.

O armazenamento do Azure é inerentemente redundante e não requer vários discos para disponibilidade. Você pode tarar discos no Gerenciador de Discos ou Espaços de Armazenamento para fornecer espaço e desempenho adicionais.

Para obter mais informações e recomendações sobre como maximizar Armazenamento Premium desempenho e executar SQL Servers em VMs IaaS do Azure, consulte:

• Otimizar o desempenho do aplicativo

• Diretrizes de discos

Exemplo: servidor de site baseado no Azure

As diretrizes de dimensionamento de um servidor de site colocated e SQL Server com 50.000 clientes são oito núcleos, 32 GB e 1200 IOPS para caixas de entrada do servidor de site e 2800 IOPS para arquivos SQL Server.

O computador do Azure resultante pode ser um DS13v2 (oito núcleos, 56 GB) com a seguinte configuração de disco:

1. Esse valor é de configurações de disco de exemplo.
2. As diretrizes do Azure permitem colocar o TempDB na unidade D: local baseada em SSD, uma vez que não excederá o espaço disponível e permitirá a distribuição de E/S de disco adicional.

Exemplo: servidor de site baseado no Azure (para aumento de desempenho instantâneo)

A taxa de transferência de disco do Azure é limitada pelo tamanho da VM. A configuração no exemplo anterior do Azure pode limitar a expansão futura ou o desempenho adicional. Se você adicionar discos adicionais durante a implantação inicial da VM do Azure, poderá aumentar o tamanho da VM do Azure para aumentar o poder de processamento no futuro, com investimento inicial mínimo. É muito mais simples planejar com antecedência para aumentar o desempenho do site à medida que os requisitos mudam, em vez de mais tarde precisar fazer uma migração mais complicada.

Altere os discos no exemplo anterior do Azure para ver como o IOPS é alterado.

DS13v2

1. Os discos são listrados usando Espaços de Armazenamento.
2. Esse valor é de configurações de disco de exemplo. O tamanho da VM limita o desempenho.
3. As diretrizes do Azure permitem colocar o TempDB na unidade D: local baseada em SSD, uma vez que não excederá o espaço disponível e permitirá a distribuição de E/S de disco adicional.

Se você precisar de mais desempenho no futuro, poderá aumentar o tamanho da VM para uma DS14v2, que dobrará a CPU e a memória. A largura de banda de disco adicional permitida por esse tamanho de VM também aumentará instantaneamente o IOPS de disco disponível em seus discos configurados anteriormente.

DS14v2

1. Os discos são listrados usando Espaços de Armazenamento.
2. Esse valor é de configurações de disco de exemplo. O tamanho da VM limita o desempenho.
3. As diretrizes do Azure permitem colocar o TempDB na unidade D: local baseada em SSD, uma vez que não excederá o espaço disponível e permitirá a distribuição de E/S de disco adicional.

Ambos podem ser executados adequadamente, supondo que o servidor único seja dimensionado adequadamente ou a conectividade de rede seja suficiente entre os dois servidores.

O SQL Server remoto requer o custo inicial e operacional de um servidor adicional, mas é típico entre a maioria dos clientes em larga escala. Os benefícios dessa configuração incluem:

• Opções de disponibilidade de site aumentadas, como SQL Server Always On
• Capacidade de executar relatórios pesados com menos escutas no processamento do site
• Recuperação de desastre mais simples em algumas situações
• Gerenciamento de segurança mais fácil
• Separação de função para gerenciamento de SQL Server, como com uma equipe DBA separada

O SQL Server colocated requer um único servidor e é típico para a maioria dos clientes de pequena escala. Os benefícios dessa configuração incluem:

• Custos mais baixos para máquinas, licenças e manutenção
• Menos pontos de falha no site
• Melhor controle para o tempo de inatividade do planejamento

Por padrão, SQL Server usa toda a memória disponível no servidor, potencialmente passando fome no sistema operacional e em outros processos no computador. Para evitar possíveis problemas de desempenho, é importante alocar memória para SQL Server explicitamente. Em servidores de site colocados com SQL Server, verifique se o sistema operacional tem RAM suficiente para cache de arquivo e outras operações. Verifique se há RAM suficiente restante para SMSExec e outros processos Configuration Manager. Ao executar SQL Server em um servidor remoto, você pode alocar a maior parte da memória para SQL, mas não todas. Examine as diretrizes de dimensionamento para obter diretrizes iniciais.

SQL Server alocação de memória deve ser arredondada para GB inteiro. Além disso, à medida que a RAM aumenta para grandes quantidades, você pode permitir que SQL Server tenham uma porcentagem maior. Por exemplo, quando 256 GB ou mais de RAM estiverem disponíveis, você pode configurar SQL Server para até 95%, pois isso ainda preserva muita memória para o sistema operacional. Monitorar o arquivo de página é uma boa maneira de garantir que haja memória suficiente para o sistema operacional e todos os processos de Configuration Manager.

Você poderá encontrar problemas de contenção de memória se houver mais de 16 núcleos físicos e não houver RAM suficiente em seu SQL Server. A carga de trabalho Configuration Manager tem melhor desempenho quando pelo menos 3 a 4 GB de RAM por núcleo estão disponíveis para SQL. Ao adicionar núcleos ao seu SQL Server, certifique-se de aumentar a RAM em quantidades proporcionais.

Em geral, os grupos de disponibilidade têm um efeito insignificante no desempenho do sistema quando há rede suficiente disponível entre os servidores de réplica. Você pode ter um rápido crescimento de arquivo .ldf de log de banco de dados em um ambiente de grupo de disponibilidade ocupado. No entanto, o espaço do arquivo de log é liberado automaticamente após um backup de banco de dados bem-sucedido. Adicione um trabalho SQL Server para o banco de dados Configuration Manager executar um backup, por exemplo, a cada 24 horas e um backup .ldf a cada seis horas. Para obter mais informações sobre grupos de disponibilidade e Configuration Manager, incluindo mais sobre estratégias de backup SQL Server, consulte Preparar para usar um grupo de disponibilidade SQL Server Always On.

SQL Server compactação não é recomendada para o banco de dados Configuration Manager. Embora não haja problemas funcionais com a habilitação da compactação em um banco de dados Configuration Manager, os resultados do teste não mostram muita economia de tamanho em comparação com o potencial impacto considerável do desempenho no sistema.

Todos os segredos no banco de dados Configuration Manager já estão armazenados com segurança, mas adicionar SQL Server criptografia pode adicionar mais uma camada de segurança. Não há problemas funcionais com a habilitação da criptografia em seu banco de dados, mas pode haver uma degradação de desempenho de até 25%. Portanto, criptografe com cuidado, especialmente em ambientes de grande escala. Lembre-se também de atualizar seus planos de backup e recuperação para garantir que você possa recuperar com êxito os dados criptografados.

Para versões com suporte do SQL, consulte Suporte para versões SQL Server. Do ponto de vista de desempenho, todas as versões com suporte de SQL Server atendem aos critérios de desempenho necessários. No entanto, SQL Server 2016 ou mais recente tende a superar SQL Server 2014 em alguns aspectos da carga de trabalho Configuration Manager. Além disso, executar SQL Server 2014 no nível de compatibilidade SQL Server 2012 (110) melhora o desempenho em geral. No momento da instalação, Configuration Manager bancos de dados em execução no SQL Server 2014 estão definidos como nível de compatibilidade 110. SQL Server 2016 ou mais recente é definido como o nível de compatibilidade padrão da SQL Server versão, como 130 para SQL Server 2016. Atualizar SQL Server em vigor não atualiza os níveis de compatibilidade até instalar a próxima versão principal Configuration Manager branch atual.

Se você vir tempo limite ou lentidão incomuns em determinadas consultas SQL no SQL Server 2016 ou posterior, como ao usar RBAC no Console Administração, tente alterar o nível de compatibilidade SQL Server no banco de dados Configuration Manager para 110. A execução no nível de compatibilidade SQL Server 110 em SQL Server 2014 e versões mais recentes do SQL Server tem suporte total. Para obter mais informações, confira Tempos de consulta SQL fora ou console lento em determinadas consultas de banco de dados Configuration Manager.

A partir de janeiro de 2018, você deve evitar as seguintes versões SQL Server, devido a vários problemas de desempenho conhecidos ou outros problemas potenciais:

• SQL Server 2012 SP3 CU1 para CU5
• SQL Server 2014 SP1 CU6 para SP2 CU2
• SQL Server RTM 2016 para CU3, SP1 CU3 para CU5

Sim, atualize índices com mais frequência que uma vez por semana e estatísticas com mais frequência que uma vez por dia para melhorar SQL Server desempenho. Scripts de terceiros e informações adicionais disponíveis nas comunidades Configuration Manager e SQL Server podem ajudar a otimizar essas tarefas.

Em sites grandes, algumas SQL Server tabelas, como CI_CurrentComplianceStatusDetails, HinvChangeLog, podem ser grandes, dependendo dos padrões de uso. Talvez seja necessário reduzir ou alterar sua abordagem de manutenção para eles um por um.

SQL Server Express não tem implicações significativas de desempenho em sites secundários e é adequado para a maioria dos clientes. Também é fácil implantar e gerenciar e é a configuração recomendada para quase todos os clientes em qualquer tamanho.

Há uma situação em que uma instalação de SQL Server completa pode ser necessária. Se você tiver um grande número de pontos de distribuição e pacotes ou fontes em seu ambiente, é possível exceder o limite de tamanho de 10 GB de SQL Server Express. Se o número de pacotes vezes o número de pontos de distribuição for superior a 4.000.000, como 2.000 DPs com 2.000 peças de conteúdo, considere usar SQL Server completo em seus sites secundários.

Deixar sua configuração em 0 (usar todos os processadores disponíveis) é ideal para o desempenho geral do processamento na maioria das circunstâncias.

Muitos administradores Configuration Manager seguem as diretrizes em Recomendações e diretrizes para a opção de configuração "grau máximo de paralelismo" no SQL Server. Na maioria dos hardwares grandes modernos, essa diretriz leva a uma configuração máxima sugerida de oito. No entanto, se você executar muitas consultas menores em comparação com o número de processadores, poderá ajudar a defini-la como um número maior. Limitar-se a oito não é necessariamente a melhor configuração em sites maiores quando mais núcleos estão disponíveis.

No SQL Servers com mais de oito núcleos, comece com uma configuração de 0 e faça alterações somente se você tiver problemas de desempenho ou bloqueio excessivo. Se você precisar alterar o MaxDOP porque está encontrando problemas de desempenho em 0, comece com um novo valor pelo menos maior ou igual ao número mínimo recomendado de núcleos para o dimensionamento SQL Server desse site. Ir abaixo desse valor quase sempre tem implicações negativas de desempenho. Por exemplo, um SQL Server remoto para um site de 100.000 clientes precisa de pelo menos 12 núcleos. Se o SQL Server tiver 16 núcleos, comece a testar sua configuração MaxDOP com um valor de 12.

Tome cuidado ao desabilitar a proteção antivírus em qualquer sistema. Em ambientes de alto volume e seguros, recomendamos desabilitar o monitoramento ativo para um desempenho ideal.

Para obter mais informações sobre exclusões recomendadas de antivírus, consulte Exclusões recomendadas de antivírus para Configuration Manager 2012 e Servidores de Site do Branch Atual, Sistemas de Site e Clientes.

Alterar algumas configurações importantes do IIS, como o comprimento da fila do WsusPool e o limite de memória privada do WsusPool, pode melhorar o desempenho do WSUS, mesmo em instalações menores. Para obter mais informações, consulte Hardware recomendado.

Verifique também se você tem as atualizações mais recentes instaladas para o sistema operacional que executa o WSUS:

• Windows Server 2012: qualquer atualização cumulativa não "somente segurança" lançada em outubro de 2017 ou posterior. (KB4041690)
• Windows Server 2012 R2: qualquer atualização cumulativa não "somente segurança" lançada em agosto de 2017 ou posterior. (KB4039871)
• Windows Server 2016: qualquer atualização cumulativa que não seja "somente segurança" lançada em agosto de 2017 ou posterior. (KB4039396)

Consulte O guia completo para Microsoft manutenção do WSUS e Configuration Manager SUP.

O monitoramento de desempenho do servidor tradicional funciona efetivamente para Configuration Manager geral. Você também pode aproveitar os vários pacotes de gerenciamento do System Center Operations Manager para Configuration Manager, SQL Server e Windows Server para monitorar a integridade básica de seus servidores. Você também pode monitorar diretamente os contadores do Windows Monitor de Desempenho (PerfMon) Configuration Manager fornece. Monitore os backlogs nas várias caixas de entrada para obter sinais de alerta antecipados de possíveis problemas de desempenho do site ou backlogs.

Confira também

• Diretrizes de dimensionamento e desempenho do site
• Configuration Manager no Azure perguntas frequentes