Temos um servidor dedicado que usamos para preparar sites (nosso servidor de teste). O desempenho do servidor ficou muito ruim e precisamos reiniciá-lo regularmente. Quando o desempenho é ruim, verifiquei o gerenciador de tarefas em busca de processos e memória, mas tudo parece OK.
Usamos um sistema de gerenciamento de conteúdo e é sempre ao usar a seção de administração deste CMS que notamos a degradação do desempenho, o que me faz pensar que pode ter algo a ver com as chamadas de banco de dados que o CMS está fazendo.
Isso parece viável? Alguma outra sugestão de como posso testar isso?
Desde já, obrigado...
Responder1
Isso parece viável?
Sim.
Alguma outra sugestão de como posso testar isso?
Verificação de desempenho. Observe que o desempenho não é apenas da CPU. Se você acha que o banco de dados é o problema, pode ser um limite de IO - a latência do disco/percentagem de atividade disparará neste caso. Verifique os contadores de desempenho do disco. Especialmente se você estiver com IO cheio, a CPU estará baixa, pois a CPU basicamente não atende aos processos porque está esperando a conclusão do IO.
Ficando mais ocupados, normalmente, os bancos de dados exigem orçamentos de IO significativos, o que significa alguns discos. Eu tenho um banco de dados aqui que agora usa 6 discos de 10k RPM e logo será atualizado para 8 - SOMENTE para os dados. Um típico servidor dedicado barato geralmente tem orçamentos de IO realmente ruins - discos lentos e grandes para usuários finais, poucos deles, não formam um subsistema rápido. Isso funciona muito bem em alguns cenários, mas no final pode ficar sobrecarregado.
Responder2
Como a TomTom disse, isso é quase certamente uma indicação de que o seu sistema está vinculado à E / S e não à CPU. A causa raiz pode ser apenas o aumento da carga do banco de dados por trás do seu CMS ou pode ser outra coisa, mas em qualquer caso, o PerfMon tem alguns contadores úteis para examinar que podem dizer com certeza se o subsistema do disco é a causa.
\LogicalDisk\Avg. Disco Sec/Leitura e \LogicalDisk\Avg. Segundo disco/gravação
Estes são os números básicos de latência para operações de E/S de leitura e gravação. Quanto menor, melhor. Sempre que esses números excederem cerca de 15 ms, o desempenho do servidor será visivelmente ruim.
\LogicalDisk\Disk Bytes/Sec e \LogicalDisk\Disk Reads/Sec e Isso informará o rendimento geral do disco. Essas taxas podem estar saturando a capacidade máxima do subsistema de disco devido apenas à taxa de transferência ou porque você atingiu um limite de IOPs para seu padrão de leitura/gravação. Pode ser difícil deduzir algo significativo a partir disso, a menos que você esteja 100% confiante de que possui um padrão de IO previsível. Não há uma maneira realmente útil de fornecer um número específico a ser observado aqui, mas se você estiver vendo 50-100 MBytes/seg ou mais em um único disco SATA, isso seria tão bom quanto você poderia esperar. Discos de servidor mais rápidos (10k, 15K, SSD) podem exceder isso e o armazenamento conectado à SAN pode fornecer praticamente tudo o que você deseja, desde que você pague o suficiente. Com pequenos IO aleatórios (típicos de operações de banco de dados), esse número sempre será baixo e não diz muito.
\LogicalDisk\Gravações de disco/seg, \LogicalDisk\Leituras de disco/seg e \LogicalDisk\Transferências de disco/seg Eles informarão o número de operações de E/S discretas por segundo e a proporção de leitura/gravação. Os discos giratórios são bastante limitados nesse aspecto - os discos SATA de 7,2K podem sustentar cerca de 70-80 IO por segundo, os discos de 10K aumentam para a faixa de 100-150, 15K serão 200+. Os SSDs serão uma ou duas ordens de magnitude maiores. Os grupos RAID aumentam isso de forma bastante linear para leituras, mas as gravações incorrerão em uma penalidade entre 2 e 5. Um pacote RAID 5 de 3 unidades (com uma penalidade de gravação de 4) suporta cerca de 25% menos E/S de gravação do que uma única unidade, por exemplo.
Se esse número tende a aumentar enquanto a latência aumenta para um território perigoso (ou seja, > 15 ms), é uma forte indicação de que seus discos estão atingindo um limite de IOPs, independentemente dos números específicos relatados.
\LogicalDisk\Split IO/s Isso lhe dirá quantas solicitações de E/S resultam em múltiplas operações e lhe dará uma noção de quanto a fragmentação está impactando a atividade de E/S.
PhysicalDisk: Comprimento atual da fila do disco e PhysicalDisk: Avg. Comprimento da fila de disco. Isso informa quantas E/S pendentes estão aguardando para serem concluídas no nível do disco físico. Se for 2 ou superior em um único disco ou exceder o número de discos no grupo RAID a partir do qual o disco foi criado, você poderá estar enviando mais E/S para o disco do que ele pode concluir em tempo hábil. Existem cenários em que isso não importa muito, mas será um verdadeiro assassino para sistemas que exigem E/S de disco de baixa latência (bancos de dados onde o cache de memória não consegue cobrir a fraqueza dos discos). A primeira é uma leitura instantânea, portanto, só se preocupe se ela estiver consistentemente alta ou se mudar de acordo com o contador de% de tempo em disco. Se a média. O comprimento da fila de disco é muito alto, então você definitivamente tem um problema.
Disco Físico: % Tempo em Disco % de tempo em disco informa o quão ocupado o disco está. À medida que se aproxima de 100%, você terá dificuldade para fazer com que o sistema faça qualquer outra coisa que dependa desse disco, pois todas as E/S adicionais tenderão a ficar na fila. Mesmo números significativamente abaixo de 100% podem indicar um problema e, se for alto ou crescente, e o comprimento da fila de disco atual for alto, isso é uma indicação clara de uma carga de E/S que excede a capacidade dos discos. Na verdade, esse número é calculado de uma maneira estranha e, como resultado, pode não ser tão útil na análise do desempenho do RAID.
Este artigo do blog Technetse aprofunda em alguns desses contadores e em alguns cenários onde você pode usá-los para identificar o problema e estabelecer como corrigi-lo.
Responder3
Vale a pena considerar configurar seu pool de aplicativos web para reciclar processos de trabalho com frequência?