Estimar os requisitos de desempenho e capacidade dos Serviços do Access no SharePoint Server 2010
Aplica-se a: SharePoint Server 2010 Enterprise
Tópico modificado em: 2016-11-30
Este artigo oferece orientação sobre a superfície ocupada pelos Serviços do Access no Microsoft SharePoint Server 2010 em topologias que executam o Microsoft SharePoint Server 2010.
Neste artigo:
Características do farm de teste
Resultados do teste
Recomendações
Solução de problemas
Características do farm de teste
Esta seção descreve o conjunto de dados usado durante o teste, as cargas de trabalho adicionadas ao produto durante a coleta de dados de desempenho, o hardware usado durante o teste e a topologia de implantação desse hardware.
Conjunto de dados
A capacidade e o desempenho dos Serviços do Access dependem significativamente da composição dos aplicativos hospedados no serviço. O tamanho das tabelas e a complexidade das consultas costumam exercer o maior efeito sobre a capacidade e o desempenho. O teste usou tamanhos e complexidades representativos, mas cada aplicativo e conjunto de dados é diferente. A capacidade e o desempenho dependerão dos aplicativos utilizados, da sua complexidade específica e do tamanho dos dados.
Para avaliar o perfil de capacidade, os aplicativos dos Serviços do Access foram simulados em um farm dedicado aos Serviços do Access (nenhum outro teste do SharePoint estava sendo executado). O farm continha os seguintes sites representativos:
1.500 aplicativos dos Serviços do Access com um perfil de tamanho "Pequeno", no máximo 100 itens por lista.
1.500 aplicativos dos Serviços do Access com um perfil de tamanho "Médio", no máximo 2.000 itens por lista.
1.500 aplicativos dos Serviços do Access com um perfil de tamanho "Grande", no máximo 10.000 itens por lista.
Cada aplicativo é constituído por várias listas, e as demais listas são adequadamente dimensionadas com base nessa lista maior. Os Serviços do Access podem trabalhar com mais de 10.000 itens. Esse número foi escolhido para o perfil "Grande" porque não se esperava que o uso de aplicativos maiores fosse ser comum.
Os aplicativos foram distribuídos homogeneamente entre as seguintes opções:
Contatos Um aplicativo simples de gerenciamento de contatos dominado por uma única lista.
Projetos Um aplicativo simples de acompanhamento de tarefas e projetos dominado por duas listas (os projetos e as tarefas associadas a cada projeto).
Pedidos Um sistema simples para entrada de pedidos, semelhante ao exemplo da Northwind Traders para o Microsoft Access, mas com escala horizontal reduzida e incluindo diversas listas inter-relacionadas (pedidos, detalhes de pedidos, faturas, detalhes de faturas, pedidos de compra, detalhes de pedidos de compra etc.).
Carga de trabalho
Para simular o uso dos aplicativos, foram criadas cargas de trabalho para realizar uma ou mais das operações a seguir:
Abertura de formulários
Paginação entre os formulários
Filtragem e classificação de folhas de dados
Atualização, exclusão e inserção de registros
Publicação do aplicativo
Renderização de relatórios
Cada carga de trabalho inclui um "tempo de raciocínio" entre as ações do usuário, que varia de 5 a 20 segundos. Isso difere dos outros documentos de planejamento de capacidade do SharePoint. Os Serviços do Access possuem monitoramento de estado, e cursores de memória e conjuntos de registros foram mantidos entre as interações do usuário. Era importante simular uma sessão completa do usuário, e não apenas solicitações individuais. Para cargas de trabalho de um único usuário, há em média duas solicitações por segundo.
A tabela a seguir mostra as porcentagens usadas para determinar qual aplicativo e qual tamanho de aplicativo devem ser utilizados.
| Pequeno | Médio | Grande | |
|---|---|---|---|
Contatos |
16% |
10% |
9% |
Projetos |
18% |
12% |
10% |
Pedidos |
11% |
8% |
6% |
Definições das zonas verde e vermelha
Para cada configuração, dois testes foram executados para determinar uma "zona verde" e uma "zona vermelha". A zona verde é a taxa de transferência recomendada que pode ser mantida. A zona vermelha é a taxa de transferência máxima que pode ser tolerada durante um curto período, mas ela deve ser evitada.
A zona verde foi definida como um momento no qual o teste executado consome no máximo a metade do recurso gerador de afunilamento. Nesse caso, o recurso gerador de afunilamento era a % de CPU em qualquer uma das três camadas: o servidor Web front-end, o servidor de aplicativos (Serviços de Dados do Access) ou o servidor de banco de dados (SQL Server). Primeiramente, o afunilamento foi identificado para uma configuração em particular. Nos casos em que o afunilamento foi a CPU dos Serviços de Dados do Access, nós garantimos que a CPU consumida no teste da zona verde nos computadores dos Serviços de Dados do Access estivesse entre 40% e 50%.
Para a zona vermelha, foi selecionado um momento no qual a taxa de transferência máxima foi atingida. Essa taxa correspondeu a uma faixa de 80% a 90% da CPU. Ao procurarmos o afunilamento, examinamos a % de CPU, o uso de memória (bytes particulares), o comprimento da fila de disco, a E/S de rede e outros recursos que poderiam resultar em afunilamento.
Os testes das zonas verde e vermelha foram executados durante 1 hora com uma carga de usuário fixa.
Seus resultados podem variar
Os números específicos para capacidade e desempenho apresentados neste artigo serão diferentes daqueles usados em ambientes reais. Esta simulação é apenas uma estimativa do que os usuários reais podem fazer. Os números são apresentados para fornecer um ponto de partida para o design de um ambiente adequadamente dimensionado. Concluído o design inicial do sistema, teste a configuração para determinar se o sistema dará suporte aos fatores do seu ambiente.
Configuração e topologia do hardware
Hardware de laboratório
Para fornecer um alto nível de detalhes de resultados de testes, várias configurações de farm foram usadas para o processo. Essas configurações incluíram de um a quatro servidores Web front-end, de um a quatro servidores de aplicativos (quando os Serviços do Access ou os Serviços de Dados do Access estavam disponíveis) e um único computador servidor de banco de dados executando o Microsoft SQL Server 2008. Além disso, os testes foram realizados usando quatro computadores cliente. Todos os computadores servidor eram de 64 bits, e todos os computadores cliente eram de 32 bits.
A tabela a seguir lista o hardware específico usado para os testes.
| Função do computador | CPU | Memória | Rede | Disco |
|---|---|---|---|---|
Servidor Web front-end |
2 processadores, 4 núcleos de 2,33 GHz |
8 GB |
1 GB |
RAID 5 de 2 eixos |
Servidor de aplicativos (Serviços de Dados do Access) |
2 processadores, 4 núcleos de 2,33 GHz |
8 GB |
1 GB |
RAID 5 de 2 eixos |
Servidor de banco de dados (SQL Server) |
4 processadores, 4 núcleos de 2,6 GHz |
32 GB |
1 GB |
DAS (armazenamento de conexão direta) conectado ao RAID 0 para cada LUN (número unidade lógica) |
Topologia
De acordo com a nossa experiência, a CPU da camada do servidor de aplicativos, onde são executados os Serviços de Dados do Access, é um fator de limitação importante para a taxa de transferência. Variamos a nossa topologia adicionando mais computadores de Serviços de Dados do Access até que não houvesse mais afunilamento e, em seguida, adicionamos um servidor Web front-end para obter uma taxa de transferência ainda maior.
1x1: um computador servidor Web front-end para um computador de Serviços de Dados do Access
1x2: um computador servidor Web front-end para dois computadores de Serviços de Dados do Access
1x3: um computador servidor Web front-end para três computadores de Serviços de Dados do Access
1x4: um computador servidor Web front-end para quatro computadores de Serviços de Dados do Access
2x1: dois computadores servidor Web front-end para um computador de Serviços de Dados do Access
2x2: dois computadores servidor Web front-end para dois computadores de Serviços de Dados do Access
2x4: dois computadores servidor Web front-end para quatro computadores de Serviços de Dados do Access
Como o computador que executa o SQL Server é um computador relativamente avançado e em nenhum momento sofreu afunilamento (apesar de ter se aproximado da saturação da CPU no teste de 2x4), não variamos esse fator nas nossas topologias. Dependendo das consultas que fazem parte do ambiente de aplicativos real, estima-se que a camada de servidor de banco de dados (SQL Server) se torne o afunilamento.
O Reporting Services foi executado no modo conectado para todos os nossos testes na camada do servidor de aplicativos (Serviços de Dados do Access).
Resultados do teste
As tabelas a seguir mostram os resultados do teste dos Serviços do Access. Para cada grupo de testes, somente determinadas variáveis específicas foram alteradas para mostrar o efeito progressivo no desempenho de um farm.
Todos os testes apresentados neste artigo foram realizados com o tempo de raciocínio ou tempo de espera. Isso difere dos resultados de planejamento de capacidade para outras partes do SharePoint.
Para obter informações sobre afunilamentos dos Serviços do Access, consulte Afunilamentos comuns e suas causas, mais adiante neste artigo.
Escala geral
A tabela e o gráfico a seguir resumem o impacto da inclusão de servidores Web front-end e computadores de Serviços de Dados do Access adicionais no farm. Esses valores de taxa de transferência são especificamente para computadores de Serviços de Dados do Access e não refletem o impacto no farm em geral.
| Topologia | Máximo de soluções de linha de base (RPS) | Linha de base recomendada (RPS) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "RPS máximo e recomendado")
Resultados recomendados
O gráfico a seguir mostra os resultados da taxa de transferência sustentável recomendada.
.gif "Taxa de transferência versus ADS")
Conforme descrito anteriormente neste artigo, adicionar o quarto computador de Serviços de Dados do Access altera o afunilamento para o servidor Web front-end, enquanto adicionar um segundo servidor Web soluciona a restrição de recursos da camada do servidor Web. Isso implica que as configurações 1x1, 1x2 e 1x3 são razoáveis. No entanto, quando o quarto computador de Serviços de Dados do Access é adicionado, um servidor Web front-end também deve ser adicionado. Como a escala é linear (uma linha reta de 1x1 a 1x4), chega-se à conclusão de que a adição de um sétimo computador de Serviços de Dados do Access também possa implicar a adição de um terceiro servidor Web front-end, e assim por diante, até que as necessidade do farm sejam atendidas.
Lembre-se de que esses resultados se baseiam apenas em uma carga de trabalho simulada e que uma implantação real deve ser monitorada para localizar em que momento é necessário acrescentar servidores Web front-end adicionais para dar suporte a computadores de Serviços de Dados do Access adicionais. Além disso, os servidores Web front-end são dedicados aos Serviços do Access, enquanto, na verdade, é provável que eles sejam compartilhados com outras cargas de trabalho do SharePoint. O gráfico a seguir mostra os resultados.
.gif "Tempo de resposta versus ADS")
O gráfico a seguir mostra o tempo de resposta nesse nível de taxa de transferência. O tempo de resposta é muito rápido: em média, menos de ¼ de segundo por solicitação.
.gif "% da CPU do SQL versus ADS")
Esses resultados mostram que o computador do SQL Server não era um afunilamento, pois a adição de um segundo servidor Web front-end solucionou a falta de recursos, e a CPU do SQL Server estava sempre a menos de 50%. No entanto, observe que a instância do SQL Server é compartilhada com outros serviços do SharePoint e com o próprio SharePoint e, portanto, o efeito cumulativo pode influenciar os comprimentos das filas da CPU ou de E/S de disco a ponto de realmente os transformar em afunilamentos.
Máximo
O gráfico a seguir mostra os resultados em que a taxa de transferência ultrapassou seu limite de sustentação.
Neste gráfico, podemos ver novamente que um segundo servidor Web foi necessário para maximizar a utilidade do quarto computador de Serviços de Dados do Access. Mais uma vez, os seus resultados poderão variar, pois dependerão significativamente dos aplicativos e seus padrões de uso.
.gif "Taxa de transferência versus ADS")
Neste caso, o tempo de resposta aumenta, pois o sistema geral está sob pressão. No entanto, esses níveis continuam sendo de aproximadamente um segundo, o que é aceitável para a maioria dos usuários.
Pode parecer estranho que quatro computadores de Serviços de Dados do Access e dois servidores Web front-end tenham um tempo de resposta mais rápido do que um servidor Web front-end. Isso ocorre porque a taxa de transferência geral do sistema é elevada com dois servidores Web front-end.
Novamente, o SQL Server não é um fator de limitação nesse caso, pois adicionar o segundo servidor Web front-end retorna a uma linha de escala linear. Porém, atingimos quase 90% de uso da CPU na instância do SQL Server e, portanto, resta uma quantidade muito pequena de reserva dinâmica. Se adicionássemos um quinto computador de Serviços de Dados do Access, o computador do SQL Server provavelmente se tornaria o afunilamento.
.gif "% da CPU do SQL versus ADS")
Resultados detalhados
As tabelas a seguir mostram os resultados detalhados das configurações recomendadas.
| Geral | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Solicitações/s |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Testes/s |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Latência média |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Média da camada do servidor Web front-end | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Máximo de bytes particulares de w3wp |
9,46 E + 08 |
2,31 E + 08 |
1,49 E + 09 |
1,55 E + 09 |
8,43 E + 08 |
9,84 E + 08 |
1,19 E + 09 |
| Média da camada do servidor de aplicativos (Serviços de Dados do Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% da CPU para w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% da CPU para RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Total máximo de bytes particulares |
4,80 E + 09 |
4,89 E + 09 |
4,91 E + 09 |
4,62 E + 09 |
5,32 E + 09 |
4,82 E + 09 |
5,07 E + 09 |
Máximo de bytes particulares de w3wp |
2,10 E + 09 |
1,97 E + 09 |
2,04 E + 09 |
1,86 E + 09 |
2,00 E + 09 |
2,00 E + 09 |
2,07 E + 09 |
Máximo de bytes particulares de RS |
1,78 E + 09 |
2,00 E + 09 |
1,97 E + 09 |
1,86 E + 09 |
2,30 E + 09 |
1,89 E + 09 |
2,02 E + 09 |
| Camada do servidor de banco de dados (SQL Server) (um computador) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Média de bytes particulares |
2,96 E + 10 |
3,22 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
2,89 E + 10 |
3,22 E + 10 |
3,25 E + 10 |
Máximo de bytes particulares |
3,26 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
Comprimento médio total da fila de disco |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
As tabelas a seguir mostram os resultados detalhados das configurações máximas.
| Geral | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Solicitações/s |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Testes/s |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Latência média |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Média da camada do servidor Web front-end | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Máximo de bytes particulares de w3wp |
9,46 E + 08 |
2,31 E + 08 |
1,49 E + 09 |
1,55 E + 09 |
8,43 E + 08 |
9,84 E + 08 |
1,19 E + 09 |
| Camada do servidor de banco de dados (Serviços de Dados do Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% da CPU para w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% da CPU para RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Total máximo de bytes particulares |
4,80 E + 09 |
4,89 E + 09 |
4,91 E + 09 |
4,62 E + 09 |
5,32 E + 09 |
4,82 E + 09 |
5,07 E + 09 |
Máximo de bytes particulares de w3wp |
2,10 E + 09 |
1,97 E + 09 |
2,04 E + 09 |
1,86 E + 09 |
2,00 E + 09 |
2,00 E + 09 |
2,07 E + 09 |
Máximo de bytes particulares de RS |
1,78 E + 09 |
2,00 E + 09 |
1,97 E + 09 |
1,86 E + 09 |
2,30 E + 09 |
1,89 E + 09 |
2,02 E + 09 |
| Camada do servidor de banco de dados (SQL Server) (um computador) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% da CPU |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Média de bytes particulares |
2,96 E + 10 |
3,22 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
2,89 E + 10 |
3,22 E + 10 |
3,25 E + 10 |
Máximo de bytes particulares |
3,26 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
3,25 E + 10 |
Comprimento médio total da fila de disco |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Recomendações
Esta seção oferece recomendações gerais sobre desempenho e capacidade.
A capacidade e o desempenho dos Serviços do Access dependem significativamente da composição dos aplicativos hospedados no serviço. O tamanho das tabelas e a complexidade das consultas costumam exercer o maior efeito sobre a capacidade e o desempenho. O teste usou tamanhos e complexidades representativos, mas cada aplicativo e conjunto de dados é diferente. A capacidade e o desempenho dependerão dos aplicativos utilizados, da sua complexidade específica e do tamanho dos dados.
Recomendações de hardware
Os Serviços do Access usam um hardware padrão para servidores Web front-end e servidores de aplicativos; não são necessários requisitos especiais. As diretrizes gerais do SharePoint Server 2010 para número de CPUs, velocidade e memória se aplicam aos computadores da camada do servidor de aplicativos (Serviços de Dados do Access).
Topologias ampliadas e reduzidas
Há duas opções para aumentar a capacidade e o desempenho de uma das topologias de ponto de partida. É possível dimensionar aumentando a capacidade dos servidores existentes ou adicionando servidores à topologia. Esta seção descreve as características do desempenho geral de diversas topologias ampliadas.
Os exemplos de topologias representam as seguintes formas comuns de ampliar uma topologia para um cenário dos Serviços do Access:
Para acomodar uma carga de usuário maior, verifique os servidores de aplicativos dos Serviços do Access existentes na CPU. Adicione mais CPUs e/ou núcleos a esses servidores se possível. Adicione mais computadores servidor dos Serviços do Access conforme necessário. Isso pode ser feito até que o servidor Web front-end se torne o afunilamento para então adicionar servidores Web front-end conforme a necessidade.
Nos nossos testes, a memória na camada do servidor Web front-end e na camada do servidor de aplicativos (Serviços de Dados do Access) não é um afunilamento. Dependendo do tamanho dos conjuntos de resultados, a memória pode se tornar um problema. No entanto, não acreditamos que essa seja a regra. Rastreie os bytes particulares do processo w3wp dos Serviços de Dados do Access, conforme descrito neste artigo.
Nos nossos testes, o SQL Server não foi um afunilamento. No entanto, esses testes foram executados isoladamente de outros serviços do SharePoint Server 2010. A CPU e a E/S de disco do SQL Server devem ser monitoradas e os servidores e eixos adicionais devem ser adicionados conforme for necessário.
Configurações dos Serviços do Access relacionados ao desempenho
Uma forma de controlar as características de desempenho dos Serviços do Access é limitar o tamanho e a complexidade das consultas que podem ser realizadas. Os Serviços do Access fornecem um conjunto de limites configuráveis para controle de consultas. Cada uma das consultas a seguir pode ser configurada pela Administração Central do SharePoint. (Na seção Gerenciamento de Aplicativo, clique em Gerenciar Aplicativos de Serviço e em Serviços do Access.)
Em geral, a quantidade de dados que devem ser coletados do SharePoint para realizar uma consulta exercerá um impacto significativo no desempenho. Isso pode ser controlado de várias formas. Primeiramente, as entradas de uma consulta podem ser limitadas:
Máximo de Fontes por Consulta
Máximo de Registros por Tabela
Em segundo lugar, o tamanho resultante de uma consulta pode ser limitado:
Máximo de Colunas por Consulta
Máximo de Linhas por Consulta
Permitir Junções Externas
Além do tamanho da consulta (tamanho dos dados de entrada e saída), a complexidade do processo nos dados pode ser controlada para reduzir a carga da CPU na camada do servidor de aplicativos (Serviços de Dados do Access):
Máximo de Colunas Calculadas por Consulta
Máximo de Cláusulas Ordenar por em Cada Consulta
Obviamente, as configurações anteriores afetarão os aplicativos que podem ser executados no servidor. Por exemplo, se um aplicativo for criado com 40 colunas de saída de uma consulta, e as configurações estiverem abaixo desse nível, o aplicativo retornará um erro de tempo de execução. Deve-se atingir um equilíbrio entre as necessidades do usuário e um desempenho aceitável, e esse equilíbrio depende significativamente do tipo de aplicativos dos Access que serão executados no farm.
É possível tomar uma medida adicional mais extrema. O SharePoint Server 2010 tem suporte nativo para um conjunto de operações de consulta, o que é aprimorado pelos Serviços do Access de forma a abranger um conjunto mais amplo de cenários de aplicação. Para que os Serviços do Access melhorem as consultas do SharePoint, é possível que uma grande quantidade de dados precise ser coletada do banco de dados de conteúdo do SharePoint. Em vez disso, os Serviços do Access podem ser configurados para se limitarem somente às operações de consulta, que podem ser ter suporte nativamente pelo SharePoint. Por tanto, é necessário evitar a coleta de dados obrigatória para operações mais complexas:
- Permitir Consultas Não Remotas
Otimizações
Afunilamentos comuns e suas causas
Durante o teste de desempenho, vários afunilamentos comuns diferentes foram revelados. Um afunilamento é uma condição em que a capacidade de um elemento específico de um farm é alcançada. Isso causa uma estabilização ou uma diminuição na produtividade do farm.
A tabela na seção Solução de Problemas, mais adiante neste artigo, lista alguns dos afunilamentos comuns e descreve suas causas e possíveis soluções.
Monitoramento de desempenho
Para ajudá-lo a determinar quando fazer o dimensionamento vertical ou horizontal do sistema, use contadores de desempenho para monitorar a integridade do sistema. Use as informações das tabelas a seguir para determinar quais contadores de desempenho monitorar e o processo ao qual esses contadores de desempenho devem ser aplicados:
Servidores Web front-end
A tabela a seguir mostra contadores de desempenho e processos para o monitoramento de servidores Web no seu farm.
| Contador de desempenho | Aplicar ao objeto | Observações |
|---|---|---|
% Tempo de Processador |
Processor(_Total) |
Mostra a porcentagem do tempo decorrido em que este thread usou o processador para executar instruções. |
Bytes particulares |
Process(w3wp) |
Esse valor não deve se aproximar do Máximo de Bytes Particulares definido para processos w3wp. Se isso ocorrer, será necessária uma investigação adicional sobre qual componente está usando a memória. |
Serviços de Dados do Access
A tabela a seguir mostra contadores de desempenho e processos para monitorar servidores de aplicativos ou Serviços de Dados do Access (Serviços de Dados do Access) no seu farm.
| Contador de desempenho | Aplicar ao objeto | Observações |
|---|---|---|
% Tempo de Processador |
Processor(_Total) |
Mostra a porcentagem do tempo decorrido em que este thread usou o processador para executar instruções. |
% Tempo de Processador |
Process(w3wp) |
Os Serviços de Dados do Access são executados em seu próprio processo w2wp, que pode ser facilmente localizado por ser aquele que está recebendo a maioria do tempo da CPU. |
Comprimento Médio da Fila de Disco |
PhysicalDisk(_Total) |
Observe se há uma quantidade excessiva de gravação no disco por causa do registro em log. |
% Tempo de Processador |
Process(ReportingServicesService) |
Os relatórios são administrados pelo SQL Server Reporting Services. Caso um número excessivo de relatórios estejam sendo executados, ou caso eles sejam muito complexos, a CPU e os bytes particulares desse processo serão altos. |
Bytes particulares |
Process(w3wp) |
Os Serviços do Access armazenam os resultados das consultas no cache da memória até que a sessão do usuário expire (o limite de tempo para o qual ela é configurada). Se uma grande quantidade de dados estiver sendo processada pelos Serviços de Dados do Access, o consumo de memória do processo w3wp dos Serviços de Dados do Access aumentará. |
Bytes particulares |
Process(ReportingSrevicesService) |
Os relatórios são administrados pelo SQL Server Reporting Services. Caso um número excessivo de relatórios estejam sendo executados, ou caso eles sejam muito complexos, a CPU e os bytes particulares desse processo serão altos. |
Servidores de banco de dados
A tabela a seguir mostra contadores de desempenho e processos para o monitoramento de servidores de banco de dados no seu farm.
| Contador de desempenho | Aplicar ao objeto | Observações |
|---|---|---|
% Tempo de Processador |
Processor(_Total) |
Mostra a porcentagem do tempo decorrido em que este thread usou o processador para executar instruções. |
% Tempo de Processador |
Process(sqlservr) |
Valores médios superiores a 80% indicam que a capacidade do processador no servidor de banco de dados é insuficiente. |
Bytes particulares |
Process(sqlservr) |
Mostra a quantidade média de memória que está sendo consumida pelo SQL Server. |
Comprimento Médio da Fila de Disco |
PhysicalDisk(_Total) |
Mostra o comprimento médio da fila de disco; as solicitações de banco de dados aguardando para serem atribuídas ao disco. Com frequência, esse é um bom indicador de que a instância do SQL Server está se tornando sobrecarregada e que é possível que eixos de disco adicionais ajudem a distribuir a carga. |
Solução de problemas
A tabela a seguir lista alguns afunilamentos comuns e descreve suas causas e possíveis soluções.
| Afunilamento | Causa | Solução |
|---|---|---|
CPU de Serviços de Dados do Access |
Os Serviços do Access dependem de uma grande quantidade do processamento na camada do servidor de aplicativos. Caso seja usada uma configuração de 1x1, 1x2 ou 1x3, o primeiro afunilamento encontrado provavelmente será a CPU nos servidores de Serviços de Dados do Access. |
Aumente o número de CPUs e/ou núcleos nos computadores de Serviços de Dados do Access existentes. Adicione mais computadores servidor de Serviços de Dados do Access se possível. |
Uso da CPU do servidor Web |
Quando um servidor Web ficar sobrecarregado com solicitações do usuário, o uso médio da CPU se aproximará dos 100%. Isso impede que o servidor Web responda a solicitações rapidamente e pode resultar em tempos limites ou mensagens de erros em computadores cliente. |
Esse problema pode ser solucionado de duas formas. Você pode adicionar mais servidores Web ao farm para distribuir a carga do usuário ou pode ampliar um ou mais servidores Web adicionando processadores de alta velocidade. |
E/S do disco do servidor de banco de dados |
Quando o número de solicitações de E/S para um disco rígido excede a capacidade de E/S do disco, as solicitações são colocadas em filas. Consequentemente, o tempo de conclusão de cada solicitação aumentará. |
A distribuição de arquivos de dados entre várias unidades físicas permite a E/S em paralelo. O blog sobre alocação de disco e E/S de disco do SharePoint (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x416) contém informações úteis sobre a resolução de problemas de E/S de disco. |
Utilização da CPU do Reporting Services |
O processo do Reporting Services está usando uma grande parte dos recursos da CPU. |
Dedique um computador ao Reporting Services, retirando a carga da camada do servidor de aplicativos (Serviços de Dados do Access) (modo conectado) ou da camada do servidor Web front-end (modo local). |