Como posso medir com precisão os recursos consumidos por cada site no meu servidor?

Question

Estamos tendo problemas de desempenho em nosso servidor, que podem ou não ser o resultado inevitável do alto tráfego para nossos sites. Gostaríamos de otimizar cada site quanto ao desempenho, para que possamos ter certeza de que estamos obtendo o maior "retorno possível" antes de comprar hardware adicional.

Eu queria saber se alguém sabia de algumas maneiras criativas de medir os recursos (memória, largura de banda, tempo de CPU, etc) consumidos por cada site. Isso poderia nos permitir detectar os maiores "criminosos" e começar a trabalhar naqueles primeiros.

Estamos rodando o servidor Red Hat Enterprise Linux 5.6 (Tikanga)

    

Answer 1

Eu começaria com mod_log_config . Defina um ou mais LogFormat / CustomLog setups em httpd.conf apenas com as estatísticas que você está interessado e quaisquer metadados sobre as solicitações que você deseja filtrar e, em seguida, você pode gerar rapidamente estatísticas comparativas desses arquivos de log. Por exemplo:

LogFormat "%t %v %B %D %h %r" statlog
CustomLog "|/usr/bin/cronolog logs/stat.log.%Y-%m-%d" statlog

%t é o registro de data e hora, %v é o nome do host do servidor virtual, %B é bytes enviados (excluindo cabeçalhos), %D é gasto em microssegundos, %h é o endereço IP do cliente e %r é a primeira linha da solicitação HTTP real enviada pelo cliente. Assim, você pode deixar qualquer outra informação, dependendo do que está procurando, ou ter um registro para cada estatística, ou o que você quiser. (Eu gosto de usar cronolog para girar logs em uma base diária. Tack em -%H se você quiser rotação horária.)

Depois, você pode executar as colunas apropriadas por meio de qualquer processamento de números que você queira para obter totais, médias, identificar páginas particularmente lentas ou abusivas ou o que você tiver.

Além disso, se você tiver mod_logio ativado, poderá obter exatidão contagens de bytes (após criptografia / compactação / tudo) para largura de banda de entrada e saída para cada solicitação usando %I e %O , respectivamente, na sua string LogFormat .

    

Answer 2

A execução do suexec facilitaria a visualização de quais usuários estão usando mais recursos, pois seus processos php parecem estar sendo executados como usuários, e não como o usuário do sistema executando o apache, como www-data ou nobody.

Na minha experiência, o magento é um enorme hog de recursos, especialmente se você está apenas executando-o como ele sai da caixa. Costumávamos colocar alguns sites moderadamente ocupados em uma única caixa. Com o magento nos encontramos colocando um site em várias caixas.

Você certamente não deseja executar o magento sem tentar fazer alguns ajustes no desempenho. Eu recomendo strongmente que você configure o memcached como um cache para magento (instruções aqui ). e armazene suas sessões no memcache e ative o cache de blocos. (Isso levará o html gerado por blocos individuais e armazená-lo no memcache, para que da próxima vez que o mesmo bloco for acessado, os arquivos phtml não precisem ser executados novamente).

Você pode querer executar um acelerador de opcode como o APC para armazenar opcodes PHP em cache.

Atualização:

Você definitivamente quer ter certeza de que o mysql está ajustado, especialmente se você tiver o suficiente no buffer pool innodb. (as mesas de magento são todas innodb). Acho que um bom lugar para ler sobre o ajuste do desempenho do mysql é o blog de ajuste de desempenho do mysql . Eu começaria com sintonizando o innodb_buffer_pool_size . Note que eles estão tipicamente falando sobre rodar o mysql em um servidor que não faz nada além de rodar o mysql, então quando eles dizem "dedicar 12 gigs em uma caixa de 16 gig a innodb_buffer_pool" você deve se ajustar assim, pois sua caixa está fazendo mais do que apenas mysql.

    

Answer 3

Você está começando do lado errado.

Tradicionalmente (e também de forma simples!), você começa identificando um problema real; então você progride para diagnosticar suas causas, e somente ENTÃO você adiciona hardware ou altera configurações de software.

Se houver um problema real e observável ocorrendo agora, este é o lugar para começar: tente identificar exatamente sob quais circunstâncias ele ocorre, se é precisamente reproduzível e adivinhe qual é o impacto sobre o negócio.

Em seguida, comece a coletar dados de desempenho de sua pilha de aplicativos; isso pode envolver, mas provavelmente não está limitado a: utilização de recursos do sistema operacional, métricas do servidor da web, cache do PHP, bancos de dados, E / S de disco e latência.

Sinto muito se a resposta parece vaga ou genérica - assim foi a pergunta.

    

Answer 4

Use um sistema de coleta de métricas como Cactos ou Munin .

    

Answer 5

Eu sempre executo o collectl em todos os servidores. Ele faz uma amostragem de toneladas de métricas a cada 10 segundos e slab / processa dados a cada minuto e grava tudo em um arquivo que você pode reproduzir OU plotar com o colplot (parte do collectl-utils). Você também pode executá-lo em tempo real em qualquer intervalo de amostragem de sua escolha.

Com base no que você vê durante várias horas ou mesmo dias, você pode começar a tomar a abordagem muito claramente declarada pelo apaptr, de primeiro descobrir se existe um problema e, em seguida, tomar medidas para corrigi-lo. A coleta de dados em cada etapa do processo torna muito fácil saber se as coisas melhoraram ou pioraram.

-mark