Dimensionamento do site do Gestor de Configuração e FAQ de desempenho

Separe as caixas de entrada do Gestor de Configuração e SQL Server ficheiros em pelo menos dois volumes diferentes. Esta separação permite-lhe otimizar os tamanhos de alocação de clusters para os diferentes tipos de E/O que realizam.

Para o volume que hospeda as caixas de entrada do servidor dos seus sites, utilize o NTFS com unidades de atribuição 4K ou 8K. O ReFS escreve 64k mesmo para ficheiros pequenos. O Gestor de Configuração tem muitos ficheiros pequenos, por isso o ReFS pode produzir sobrecargas desnecessárias em disco.

Para discos que contenham ficheiros de base de dados SQL Server, utilize formatação NTFS ou ReFS, com unidades de atribuição de 64K.

As matrizes modernas de unidades de estado sólido (SSD) e Azure Premium Armazenamento podem fornecer IOPS elevados num único volume, com poucos discos. Normalmente adiciona mais unidades a uma matriz para armazenamento adicional, e não produção adicional. Se estiver a utilizar discos físicos baseados em eixos, poderá precisar de mais IOPS do que pode gerar num único volume. Deverá alocar 60% do total recomendado de IOPS e espaço em disco para o ficheiro .mdf, 20% para o ficheiro .ldf e 20% para os ficheiros temporários de registo e dados. Os ficheiros .ldf e temporários podem residir num único volume com 40% (20% + 20%) do seu IOPS atribuído.

SQL Server versões mais cedo do que SQL Server 2016 criadas por padrão apenas um ficheiro de dados temporário. Deve criar mais, para evitar SQL Server fechaduras e esperar pelo acesso a um único ficheiro. As opiniões comunitárias variam sobre o melhor número de ficheiros de dados temporários para criar, de quatro para oito. O teste revela pouca diferença entre quatro a oito, para que possa criar quatro ficheiros de dados temporários igualmente dimensionados. Os ficheiros de dados temporários devem ter até 20 a 25% do tamanho da sua base de dados completa.

Quando configurável, deite a memória do controlador RAID a 70% para alocação para operações de escrita e 30% para operações de leitura. Em geral, utilize uma configuração de matriz RAID 10 para a base de dados do site. RAID 1 também é aceitável para sites de pequena escala com baixos requisitos de E/S, ou se utilizar SSDs rápidos. Com matrizes de disco maiores, configure discos sobressalentes para substituir automaticamente os discos em falha.

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

As diretrizes de dimensionamento para um servidor de site e SQL Server com 100.000 clientes são 1200 IOPS para caixas de entrada de servidores de sites e 5000 IOPS para ficheiros SQL Server.

A configuração do disco resultante pode parecer:

1. Não inclui discos sobressalentes recomendados.
2. Este valor provém de configurações de discos exemplo.

O Hiper-V oferece um desempenho semelhante a um servidor físico, se os recursos de hardware (núcleos CPU e armazenamento de passagem) forem 100% dedicados à máquina virtual (VM). A utilização de ficheiros de disco de tamanho fixo .vhd ou .vhdx provoca um impacto mínimo de desempenho de 1 a 5%. A utilização de ficheiros de disco de expansão dinâmica .vhd ou .vhdx causa um impacto de desempenho de 25% de I/S para a carga de trabalho do Gestor de Configuração. Se necessitar de discos de expansão dinâmica, compense adicionando um desempenho adicional de 25% de IOPS à matriz.

Ao executar o servidor do site do Gestor de Configuração ou SQL Server dentro de um VM, isole as unidades de oss do host host Hyper-V a partir do VM OS e unidades de dados.

Para obter mais informações sobre a otimização de VMs, consulte os Servidores Hiper-V de Afinação de Desempenho.

Exemplo: Servidor de site baseado em Hiper-V VM

As diretrizes de dimensionamento para um servidor de site e SQL Server com 150.000 clientes são 1800 IOPS para caixas de entrada de servidores de sites e 7400 IOPS para ficheiros SQL Server.

A configuração do disco resultante pode parecer:

1. Não inclui discos sobressalentes recomendados.
2. Tamanho fixo, pass-through .vhdx para a unidade VM dedicada ao volume subjacente.
3. Este valor provém de configurações de discos exemplo.

Comece por ler o Gestor de Configuração no Azure frequentemente fez perguntas.

A infraestrutura Azure como um VM de serviço (IaaS) que alavancam discos baseados em Premium Armazenamento podem ter IOPS elevados. Nestes VMs, configurar discos adicionais para necessidades de espaço em disco antecipadas, em vez de para IOPS adicionais.

O armazenamento Azure é inerentemente redundante e não requer vários discos para disponibilidade. Pode riscar discos em Disk Manager ou Espaços de Armazenamento para fornecer espaço e desempenho adicionais.

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

• Otimizar o desempenho da aplicação

• Orientação de discos

Exemplo: Servidor de site baseado em Azure

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

A sua máquina Azure resultante pode ser um DS13v2 (oito núcleos, 56 GB) com a seguinte configuração do disco:

1. Este valor provém de configurações de discos exemplo.
2. A orientação Azure permite colocar o TempDB no D local, baseado em SSD: unidade, dado que não excederá o espaço disponível e permite uma distribuição adicional de I/O do disco.

Exemplo: Servidor de site baseado em Azure (para aumento instantâneo do desempenho)

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

Altere os discos no exemplo Azure anterior para ver como o IOPS muda.

DS13v2

1. Os discos são listrados com Espaços de Armazenamento.
2. Este valor provém de configurações de discos exemplo. O tamanho do VM limita o desempenho.
3. A orientação Azure permite colocar o TempDB no D local, baseado em SSD: unidade, dado que não excederá o espaço disponível e permite uma distribuição adicional de I/O do disco.

Se precisar de mais desempenho no futuro, pode aumentar o seu VM para um DS14v2, que duplicará o CPU e a memória. A largura de banda adicional permitida por esse tamanho VM também aumentará instantaneamente o disco disponível IOPS nos seus discos previamente configurados.

DS14v2

1. Os discos são listrados com Espaços de Armazenamento.
2. Este valor provém de configurações de discos exemplo. O tamanho do VM limita o desempenho.
3. A orientação Azure permite colocar o TempDB no D local, baseado em SSD: unidade, dado que não excederá o espaço disponível e permite uma distribuição adicional de I/O do disco.

Ambos podem funcionar adequadamente, assumindo que o servidor único é adequadamente dimensionado, ou a conectividade da rede é suficiente entre os dois servidores.

A SQL Server remota requer o custo inicial e operacional de um servidor adicional, mas é típica entre a maioria dos clientes em grande escala. Os benefícios desta configuração incluem:

• Opções de disponibilidade de site aumentadas, tais como SQL Server Always On
• Capacidade de executar relatórios pesados com menos ouvidos para o processamento do site
• Recuperação de desastres mais simples em algumas situações
• Gestão de segurança mais fácil
• Separação de papéis para a gestão SQL Server, como com uma equipa separada da DBA

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

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

Por predefinição, SQL Server utiliza toda a memória disponível no seu servidor, potencialmente esfomeando o SISTEMA e outros processos na máquina. Para evitar potenciais problemas de desempenho, é importante alocar a memória a SQL Server explicitamente. Nos servidores do site com SQL Server, certifique-se de que o SO tem RAM suficiente para a caching de ficheiros e outras operações. Certifique-se de que ainda há RAM suficiente para o SMSExec e outros processos do Gestor de Configuração. Ao executar SQL Server num servidor remoto, pode alocar a maior parte da memória a SQL, mas não a todos. Reveja as diretrizes de dimensionamento para orientação inicial.

SQL Server alocação de memória deve ser arredondada para toda a GB. Além disso, à medida que a RAM aumenta para grandes quantidades, pode deixar SQL Server ter uma percentagem mais elevada. Por exemplo, quando estiver disponível 256 GB ou mais de RAM, pode configurar SQL Server até 95%, uma vez que ainda preserva muita memória para o SO. Monitorizar o ficheiro da página é uma boa forma de garantir que há memória suficiente para o SISTEMA e quaisquer processos do Gestor de Configuração.

Pode encontrar problemas de contenção de memória se houver mais de 16 núcleos físicos e RAM insuficiente no seu SQL Server. A carga de trabalho do Gestor de Configuração funciona melhor quando pelo menos 3-4 GB de RAM por núcleo está disponível para SQL. Ao adicionar núcleos à sua SQL Server, certifique-se de aumentar a RAM em quantidades proporcionais.

Em geral, os grupos de disponibilidade têm um efeito negligenciável no desempenho do sistema quando existe uma rede suficiente entre os servidores de réplica. Pode ter um rápido registo de registo de dados .ldf crescimento de ficheiros num ambiente de grupo de disponibilidade ocupado. No entanto, o espaço de ficheiro de registo é automaticamente libertado após uma cópia de segurança de base de dados bem sucedida. Adicione um trabalho SQL Server para a base de dados do Gestor de Configuração para realizar uma cópia de segurança, por exemplo, a cada 24 horas, e uma cópia de segurança .ldf a cada seis horas. Para obter mais informações sobre grupos de disponibilidade e Gestor de Configuração, incluindo mais sobre SQL Server estratégias de backup, consulte Prepare-se para utilizar um grupo de disponibilidade SQL Server Always On.

SQL Server compressão não é recomendada para a base de dados do Gestor de Configuração. Embora não existam problemas funcionais com a compressão ativada numa base de dados do Gestor de Configuração, os resultados dos testes não mostram muitas poupanças de tamanho em comparação com o potencial impacto de desempenho considerável no sistema.

Quaisquer segredos na base de dados do Gestor de Configuração já estão armazenados de forma segura, mas adicionar SQL Server encriptação pode adicionar mais uma camada de segurança. Não existem problemas funcionais que permitam a encriptação na sua base de dados, mas pode haver até uma degradação de desempenho de 25%, dependendo das tabelas que escolhe encriptar e da versão de SQL Server que está a usar. Portanto, criptografe com cuidado, especialmente em ambientes de grande escala. Lembre-se também de atualizar os seus planos de backup e recuperação para garantir que pode recuperar com sucesso os dados encriptados.

Para versões suportadas de SQL, consulte o Suporte para versões SQL Server. Do ponto de vista do desempenho, todas as versões suportadas de SQL Server cumprem os critérios de desempenho exigidos. No entanto, SQL Server 2016 ou mais recentes tende a superar SQL Server 2014 em alguns aspetos da carga de trabalho do Gestor de Configuração. Além disso, correr SQL Server 2014 no SQL Server nível de compatibilidade de 2012 (110) melhora o desempenho em geral. Na hora da instalação, as bases de dados do Gestor de Configuração em execução no SQL Server 2014 estão definidas para o nível de compatibilidade 110. SQL Server 2016 ou mais recente está definido para o nível de compatibilidade padrão da versão SQL Server, como 130 para SQL Server 2016. A atualização SQL Server no lugar não atualiza os níveis de compatibilidade até instalar a próxima versão atual do Gestor de Configuração.

Se vir intervalos ou lentidão invulgares em determinadas consultas de SQL em SQL Server 2016 ou posterior, como quando utilizar o RBAC na Consola de Administração, tente alterar o nível de compatibilidade SQL Server na base de dados do Gestor de Configuração para 110. Correr a SQL Server nível de compatibilidade 110 em SQL Server 2014 e versões mais recentes de SQL Server é totalmente suportado. Para obter mais informações, consulte SQL consulta dos tempos fora ou console devagar em determinadas consultas de base de dados do Gestor de Configuração.

A partir de janeiro de 2018, deverá evitar as seguintes versões SQL Server, devido a várias questões relacionadas com o desempenho ou outras questões potenciais conhecidas:

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

Sim, atualizar índices com a frequência de uma vez por semana e estatísticas como uma vez por dia para melhorar o SQL Server desempenho. Scripts de terceiros e informações adicionais disponíveis do Gestor de Configuração e SQL Server comunidades podem ajudar a otimizar essas tarefas.

Em grandes sites, algumas tabelas SQL Server, tais como CI _ CurrentComplianceStatusDetails, HinvChangeLog, podem ser grandes, dependendo dos seus padrões de utilização. Pode ser necessário reduzir ou alterar a sua abordagem de manutenção, uma a uma.

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

Há uma situação em que uma instalação SQL Server completa pode ser necessária. Se tiver um grande número de pontos de distribuição e pacotes ou fontes no seu ambiente, é possível ultrapassar 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 completos nos seus sites secundários.

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

Muitos administradores do Gestor de Configuração seguem as orientações em Recomendações e diretrizes para a opção de configuração do "grau máximo de paralelismo" em SQL Server. Na maioria dos grandes hardware modernos, esta orientação leva a uma definição máxima sugerida de oito. No entanto, se executar muitas consultas menores em comparação com o seu número de processadores, pode ajudar a defini-lo para um número mais elevado. Limitar-se a oito não é necessariamente a melhor configuração em sites maiores quando há mais núcleos disponíveis.

No SQL Servidores com mais de oito núcleos, comece com uma definição de 0, e só faça alterações se sentir problemas de desempenho ou bloqueio excessivo. Se precisar de alterar o MaxDOP porque está a encontrar problemas de desempenho a 0, comece com um novo valor pelo menos superior ou igual ao número mínimo recomendado de núcleos para o tamanho SQL Server desse site. Ir abaixo deste valor quase sempre tem implicações negativas no desempenho. Por exemplo, uma SQL Server remota para um site de 100.000 clientes precisa de pelo menos 12 núcleos. Se o seu SQL Server tiver 16 núcleos, comece a testar a sua definição MaxDOP com um valor de 12.

Tome cuidado ao desativar a proteção antivírus em qualquer sistema. Em ambientes de grande volume e segurança, recomendamos a desativação da monitorização ativa para um desempenho ótimo.

Para obter mais informações sobre exclusões antivírus recomendadas, consulte as exclusões antivírus recomendadas para o Gestor de Configuração 2012 e servidores do site de ramificação corrente, sistemas de site e clientes.

Alterar algumas definições de IIS chave, como o comprimento da fila WsusPool e o limite de memória privada WsusPool, pode melhorar o desempenho da WSUS, mesmo em instalações mais pequenas. Para mais informações, consulte hardware recomendado.

Certifique-se também de que tem as últimas atualizações instaladas para o sistema operativo em execução WSUS:

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

Consulte o guia completo da manutenção SUP do Microsoft WSUS e do Gestor de Configuração.

A monitorização tradicional do desempenho do servidor funciona eficazmente para o Gestor geral de Configuração. Também pode aproveitar os vários pacotes de gestão de Gestor de Operações System Center para o Gestor de Configuração, SQL Server e Windows Server para monitorizar a saúde básica dos seus servidores. Também pode monitorizar diretamente os contadores Windows Performance Monitor (PerfMon) que o Gestor de Configuração fornece. Monitorize os atrasos nas várias caixas de entrada para obter sinais de alerta precoce de potenciais problemas de desempenho no local ou atrasos.

Ver também

• Diretrizes de dimensionamento e desempenho do site
• Gestor de Configuração no Azure frequentemente fez perguntas