Onde eu trabalho, temos inúmeros servidores "big iron" que são usados para hospedar muitas máquinas virtuais usando um Xen Hypervisor. Normalmente, eles são configurados com 32 GB de RAM, processos de núcleo Dual Quad e discos rápidos com lotes de capacidade de E / S.
Estamos no ponto no tempo em que a configuração de hardware existente está ficando um pouco extensa e é hora de sair e adquirir um novo hardware maior, mais rápido e mais brilhante.
Como mencionado acima, o kit existente foi implantado com 32 GB de RAM e limitou efetivamente o número de VMs que podemos implantar em um host.
Na investigação de hardware mais novo, é evidente que você pode obter mais e mais RAM dentro de uma única máquina com 64, 72 ou até 96GB em um único chassi. Evidentemente, isso nos permitirá obter mais máquinas para um determinado host que é sempre uma vitória. A análise concluída até agora sugere que o fator limitante será agora deslocado para o subsistema de disco.
O problema é agora, tentando ter uma idéia de onde estamos ... Em virtude do uso, sabemos que não estamos limitados em termos de largura de banda de E / S, mais ainda, o número de operações de E / S aleatórias que podem ser concluídas. Sabemos que quando atingimos esse ponto, o iowait está indo para o foguete do céu e todo o desempenho da máquina vai para os cães.
Agora, este é o ponto crucial da pergunta que estou fazendo: alguém está ciente de uma maneira de rastrear / melhorar com precisão o desempenho de E / S existente especificamente em relação ao número de operações de E / S aleatórias que estão sendo concluídas?
O que estou realmente tentando obter uma métrica é "esta configuração pode manipular com sucesso o número X de pedidos aleatórios de I / O, e estamos atualmente (em média) fazendo Y operações com um pico de Z ops".
Obrigado antecipadamente!
sar faz o trabalho bem aqui; ele coletará o número de transações, bem como setores lidos / gravados por segundo, que podem ser usados para reproduzir sua carga de trabalho de IO com precisão relativamente decente (em termos de taxas de leitura / gravação, bem como tamanho de transação, que é o fator determinante em como "aleatório" seu IO é). Não é perfeito, mas na minha experiência faz um bom trabalho para fazer o tipo de estimativa que você está olhando.
Então, isso parece um problema de relatórios de monitoramento e capacidade. Se você vai começar a medir as estatísticas de tendências, eu vou em frente, para que você possa comparar, correlacionar, etc.
Em termos de ferramentas, você tem gânglios, zenoss, nagios, etc. no mundo opensource e vários outros produtos de fornecedores.
Você pode configurá-los para rastrear, medir e armazenar os KPIs nos quais está interessado e, em seguida, informar sobre eles periodicamente.
Devido a suas consultas sobre o uso de RAM, faria sentido incluir também as estatísticas de memória, uso de troca e CPU, para que você possa compará-las no mesmo período de tempo e ver quais estão sendo limitadas etc.
Uma vez que você está capturando dados, você pode armazená-los todos em um grande banco de dados para relatórios, possivelmente rarificando dados históricos, por exemplo. armazene cada métrica de 5 segundos durante 6 meses, depois por minuto, depois 5, depois por hora, à medida que avança. Esse tipo de coisa pode ser roteirizada e executada através do cron, autosys etc.
Esses relatórios lhe darão o que a gerência deseja - por exemplo. algo com gráficos bonitos.
E para o gerenciamento diário, você pode ver informações em tempo real em um gráfico / figuras no console para ver como está se saindo em determinado momento.
Nós usamos collectl , já que podemos reunir todas as informações necessárias em um único arquivo e reproduzir as estatísticas que precisam. Isso permitirá que você veja o número de IOPS por intervalo de gravação, comutadores de contexto, estatísticas de memória. Você pode dividir isso por disco ou apenas ter uma visão geral do sistema. Collectl também suporta brilho.
Esta é uma ótima ferramenta para obter uma visão geral do desempenho total do sistema. Boa sorte, a partir de observações, os discos SATA normalmente atingem 200-300 IOPS ao fazer acesso aleatório.
Registramos e fazemos o gráfico de E / S de disco da mesma maneira que fazemos todas as outras métricas:
Os dados são extraídos dos hosts usando o SNMP. Nossas caixas NAS / SAN fazem isso nativamente. Nós usamos net-snmp em todos os hosts Linux, que fornecem essas informações de USB-DISKIO-MIB .
Os dados são armazenados (no formato RRD) e representados graficamente com Cactos . Alguns modelos de E / S de disco nos fornecem uma contagem e um tamanho de transação, exibidos no formato atual, médio e de pico normal .
Essas métricas não são necessariamente tão finitas quanto o uso de iostat / dstat / sar em um host. Mas é o fogo e o esquecimento, que é configurado automaticamente quando uma nova máquina é comissionada, armazenada centralmente e permanece disponível para referência futura.
Usamos esses dados para nos alertar sobre tendências incomuns em uma base operacional e sempre fazemos uma retrospectiva sempre que realizamos o planejamento da capacidade.
What I am really trying to get a metric on is "this configuration can successfully handle X number of random I/O requests [..]".
Há alguns problemas com isso:
É muito difícil separar e quantificar a E / S aleatória da E / S sequencial. Desde que a diferença fundamental entre os dois é a localização física dos blocos armazenados no disco platter. Você pode adivinhar o tamanho das transações, considerando que muitas pequenas transações provavelmente se relacionam com pequenos arquivos espalhados pelo disco. Mas não há garantia. Ele pode estar lendo pequenas quantidades de dados seqüencialmente de um único arquivo ou blocos adjacentes no disco.
Gravar as métricas lhe dará uma boa ideia de quais são seus compromissos hoje, como eles mudam com o tempo e, portanto, como eles mudarão no futuro. O que não vai dizer é o que é o teto. Pelo menos não antes que seja tarde demais. Para determinar isso, você precisa fazer algumas contas (a partir de suas especificações de hardware), benchmarking (Eu gosto de bonnie++ eu mesmo) e é útil ter alguma idéia logística do que esses domus estão fazendo / sendo usados.
Dependendo do seu back-end de armazenamento (IBM SVC / DS8000), você poderá extrair diretamente estatísticas relacionadas a IOPS aleatórios.
Para extrair estatísticas do servidor, você pode usar nmon . É grátis (como na cerveja). Originalmente desenvolvido pela IBM para AIX, também é executado no Linux.
Se as pessoas usam SAR, pelo menos espero que você esteja amostrando seus dados em poucos segundos. Quando uso collectl, eu faço uma amostra / segundo. Quanto a medir o quão bem você está fazendo aleatoriamente I / O, use uma ferramenta como o dt de Robin Miller (google it) e você pode facilmente gerar um monte de I / Os aleatórios e, em seguida, apenas medir com collectl para ver quantos você pode fazer por segundo. Um disco típico geralmente faz um máximo de 200-300 I / Os / seg, baseado basicamente em latência rotacional. O tamanho do bloco teve um efeito mínimo, já que aguardar 1/2 revolução para o disco estar no local certo sobrecarrega todo o resto.
btw - iowait é uma das medições mais incompreendidas. Não tem nada a ver com a carga da CPU, apenas significa que a CPU não estava fazendo nada enquanto a E / S estava ocorrendo. Na verdade, se você estiver em 100% iowait, isso significa basicamente 100% de ociosidade!
-mark