Performance Manager - o que contadores?

Question

Atualmente, estamos pensando em mudar de um ambiente tradicional de servidor para um ambiente SAN / VMWare.

Recebi uma solicitação para reunir estatísticas de desempenho de nossos principais servidores - DCs, servidores de arquivos, Exchange para ver se é viável para nosso ambiente ou se vamos nos deparar com problemas de desempenho de SAN.

Eu tenho executado algumas linhas de base agendadas por 8 horas e incluindo muitos contadores, mas os logs resultantes são muito grandes para serem úteis - leva cerca de três minutos para que o perfmon os abra ou permita que visualizemos contadores diferentes. / p>

Embora eu saiba, em geral, que são úteis ver o desempenho, o que seria uma lista adequada a ser monitorada que nos daria um ponto de partida útil, e também quais contadores seriam úteis para isso.

Estou pensando

• Desempenho da CPU
• Disco / Arquivo
• Uso de rede
• Diretório ativo (GPOs, logons, etc.)

Mas quais contadores seriam os mais úteis, também existem áreas que devíamos visar especificamente para preocupação?

    

Answer 1

Após um pouco mais de pesquisa, acho que esta é uma boa lista genérica de contadores:

Disco Lógico

• Disco médio por segundo / leitura
• Disco médio por segundo / gravação
• % de tempo ocioso

Memória

• % de bytes organizados em uso
• MBytes disponíveis
• Entradas gratuitas das tabelas de páginas do sistema
• Páginas / seg
• Bytes não combinados de pool
• Bytes Paginados do Conjunto

Rede

• Total de bytes / seg
• Comprimento da fila de saída

Disco físico

• % de tempo ocioso
• Disco médio por segundo / leitura
• Disco médio por segundo / gravação
• Comprimento médio da fila de disco
• Bytes médios de disco / s

Processo

• Contagem de identificadores
• Bytes particulares
• Contagem de tópicos

Processador

• % de tempo de interrupção
• % de tempo do processador
• % de tempo do usuário

Sistema

• Comprimento da fila do processador
• Terminal Server (opcional)
• Sessões ativas
• Sessões inativas
• Total de sessões

Answer 2

O maior que provavelmente matará você é o disco IO. Coletar as transações por segundo e os setores lidos / gravados por segundo darão a você um começo para determinar o que você precisará na SAN. Fique de olho na memória e no uso do arquivo de paginação, o que pode fazer coisas ruins para as estatísticas de E / S de disco, e provisionar suas VMs com alguma memória extra é simples.

A rede é provavelmente a próxima mais importante, mas isso é muito simples - transferência agregada e pacotes por segundo, certifique-se de que não seja muito ridículo.

A CPU é o gargalo menos provável em um sistema moderno, na minha experiência. Eu estaria inclinado a não se preocupar com isso, a menos que você tenha várias máquinas que estão atrelando sua CPU consistentemente. Provisionar um servidor de VM extra se você estiver ficando sem CPU é simples.

    

Answer 3

Para disco ligado, eu gosto de monitorar '\ PhysicalDisk (...) \ Current Queue Length da Fila' para cada disco físico.

Para o seu problema visualizando as coisas com perfmon: Embora isso possa estar fora do escopo do que você está fazendo, monitore os contadores do Windows com o Nagios usando o plug-in check_nt e o nsclient ++ instalado no cliente. Eu posso então representar graficamente tudo usando n2rrd , eu também posso usar o rrdtool para criar gráficos personalizados.

Todas as coisas que você listou geralmente são executadas em um ambiente vmware / san. É realmente apenas uma questão de quão poderosa a SAN e o servidor virtual precisarão ser e a arquitetura correta. Se você está disposto a gastar o dinheiro para um san caro, os fornecedores devem ser capazes de lhe dizer o que você precisa.

    

Answer 4

Dependendo do seu uso, o disco IO e as redes são o maior motivo de preocupação na mudança para uma infra-estrutura do tipo VMWare, especialmente se as VMs estão sendo armazenadas na SAN, você deve definitivamente avaliar o uso da rede e disco IO para todas as máquinas que você migraria. A maioria dos servidores para uso do tipo VMWare deve vir com um bom número de NICs, mas vale a pena ter em mente quantos deles você poderá usar, bem como a velocidade dos discos na SAN. O VMWare ESX suporta a capacidade de não gravar todas as alterações de disco na VM imediatamente e, portanto, você pode economizar em algum desempenho dessa maneira.

Medindo o desempenho que usamos RRDTool para acessar o desempenho como Kyle disse, isso é realmente útil.

    

Answer 5

Máquinas virtuais não são como servidores típicos, pois você tem problemas em diferentes áreas. Na maioria das vezes, a CPU não é o recurso de gargalos, mas a RAM é. As coisas que você realmente precisa saber antes de entrar:

• Taxa de transferência de disco Com que rapidez você libera seu armazenamento? MB / read, MB / write média e pico (como mencionado em outra parte deste tópico, o RRDTool é bom para isso). Você sabe quando seus picos são e se eles coincidirão ou não com picos de E / S em outras VMs armazenadas no mesmo cluster ESX. Em nosso ambiente, os backups são o tempo máximo de E / S, mas recebemos explosões durante o dia. A resposta para isso dirá se você pode ou não usar discos com backup de arquivos ou se você precisa direcionar os LUNs presentes para as VMs.
• Rendimento da rede Saiba com que rapidez você precisa estar. Como acima, os backups são a área quando começamos a tentar saturar nossos NICs. Saiba quantos dados você está gastando. Tenho certeza de que existem NICs que podem fazer a marcação de VLAN, o que pode facilitar os problemas de balanceamento de carga se a sua infraestrutura de rede oferecer suporte a ela.
• RAM creep Conhece os seus programas. Nós temos um que consumirá todo o bit de memória dado a ele, o que faz com que o console VMWare gagueje e reclame sobre o uso e recomende mais. Se você não for tão desastrosamente subfinanciado quanto nós, esperamos que seus servidores ESX sejam provisionados com muita memória RAM. Em nosso ambiente, consideramos uma VM 'piggy' se precisar acima de 1GB de RAM. Você pode ser diferente.

Determinar se você pode ou não usar discos suportados por arquivos ou se você precisa de LUNs de apresentação direta pode ser um pouco conhecedor. Os LUNs apresentados diretamente são onde sua matriz de armazenamento apresenta LUNs diretamente para VMs, o que é facilitado usando NPIV . Você pode fazê-lo sem o NPIV, mas pode ser muito perigoso para o seu sangue, todo o novo hardware Fibre Channel deve suportá-lo e o ESX 3.5 certamente funciona. O Direct apresentado remove uma camada de abstração entre o storage array e a E / S de compactação da máquina virtual e, nesse sentido, pode fornecer melhor desempenho. No entanto, a apresentação direta é mais difícil de configurar e tem um tempo de inicialização maior no estágio "envolva sua cabeça em torno dela".

Arquivos com backup de arquivos são simplesmente mais fáceis. Além disso, eles podem ser movidos entre as matrizes de armazenamento de forma bastante simples (para certos valores simples, em que arquivos multi-GB são copiados), algo que a apresentação direta requer (geralmente muito caro) software de replicação em nível de array para realizar. Baixo carregamento de I / O, as coisas funcionam apenas como peachy no arquivo, e até algumas coisas de I / O mais altas também. Estamos executando uma instalação completa do Exchange 2007 para mais de 3.000 usuários em discos suportados por arquivos. Os backups podem ser mais rápidos, mas durante o dia os usuários não notam lentidão.