Como crescer a partir da configuração de um único servidor

Question

Estou à procura de recursos para aumentar a configuração do nosso servidor.

Atualmente, temos um servidor dedicado com a Rackspace no Reino Unido com as seguintes especificações:

HPDL385_G2_PrevGen
HP Single Dual Core Opteron 2214 (2,2 GHz)
4GB RAM
2x 10.000 unidades SCSI no RAID 1

Nosso tráfego é de até 550.000 UVs por mês.

O site é executado em uma configuração PHP e MySQL. O banco de dados recebe um golpe absoluto, nós temos muitas consultas complexas unindo tabelas multilaterais.

Estamos usando o APC para cache do PHP.

Estou chegando ao estágio em que fiz o máximo possível de DB e otimização de consultas e me pergunto qual deve ser o próximo passo ......

Eu olhei para memcache, mas tenho a impressão de que ele requer uma grande quantidade de RAM e, idealmente, uma caixa dedicada ....

Então, o próximo passo é ter duas caixas; um para banco de dados, um para o Apache? Ou há um passo que eu ignorei?

Nossa carga é geralmente em torno da marca de 2, mas agora é de 20!

Alguns gráficos de Munin:

    

Answer 1

Compre algum hardware, mas coloque-o no seu laboratório de teste, não no data center. Em seguida, enfatize sua aplicação em várias combinações de hardware / software até encontrar uma razoável que faça o que você deseja.

É claro que você precisará projetar algo que possa criar tráfego falso contra um banco de dados semelhante a uma produção executando uma cópia de teste do seu aplicativo. Mas quem disse que seria fácil.

Se você não fizer isso e simplesmente fizer alguma coisa na produção, você não tem idéia se vai funcionar ou não, e você pode ter gasto muito esforço de engenharia implementando coisas como caches (que virão com seu quinhão de bugs!) em algo que não ajuda.

Teste, teste e teste mais. Não lance mudanças de hardware / software em produção até obter bons dados de desempenho, mostrando que é provável que melhore significativamente os problemas. O esforço de engenharia é caro, o hardware de teste não é (particularmente).

Memcached é apenas uma opção, e você provavelmente não a considera até ter o cache do banco de dados funcionando de maneira ideal. Isso significa colocá-lo em uma caixa dedicada (64 bits, é claro) com uma quantidade razoável de RAM (não 4G - laptops têm isso hoje em dia; 32G é definitivamente acessível) e ajustá-lo apropriadamente.

Você não mencionou quão grande é o seu banco de dados, mas se for de todo possível, você vai querer tentar obtê-lo totalmente em memória RAM (ou pelo menos os bits quentes). Colocar seu banco de dados inteiramente no ram fará com que as operações de leitura e leitura desapareçam completamente e, portanto, deixem de ser um gargalo.

Faça o perfil de suas consultas ao banco de dados. Existem ferramentas para fazer isso - você deve ser capaz de simular a carga de produção em seu ambiente de teste. O truque é evitar consultas lentas e garantir que as executadas com frequência sejam rápidas.

Se seus problemas de desempenho estiverem relacionados a sincronizações de ES, porque você está fazendo muitas transações para o banco de dados, verifique se está usando um controlador de RAID com bateria que está se comportando corretamente (fale com o fornecedor sobre eles). Eles fornecem muito mais operações de gravação de E / S do que uma de backup sem bateria (porque os dados só precisam chegar ao cache antes que o sistema operacional receba a confirmação). Alternativamente, se seus dados não importam muito, considere relaxar os parâmetros de durabilidade do banco de dados (innodb sync on commit).

    

Answer 2

Ao analisar as soluções de cache, como muitas outras sugeriram aqui, você pode esperar acabar com cerca de 10% da carga que tem hoje, talvez menos.

No entanto, isso depende do tipo de serviço que você executa na sua máquina. Você pode fazer muito com o memcached sem muita memória RAM.

Você deve tentar definir quais consultas de banco de dados levam mais tempo, usando o log de consultas lentas do MySQL (ou o equivalente para seu banco de dados), ou usando uma ferramenta como mytop . Além disso, a sintaxe EXPLAIN SELECT do MySQL pode ser útil.

O armazenamento em cache dos resultados de algumas consultas do MySQL selecionadas (mesmo por um curto período de tempo) pode realmente melhorar muito o seu desempenho.

    

Answer 3

Eu faço muito trabalho de desempenho e expansão e o que descobri é que:

Todo carregamento de aplicativos é exclusivo

Respostas genéricas como adicionar mais RAM, obter outro servidor, sim, tentar x são, muitas vezes, lições de frustração e deixam as configurações complicadas.

Avalie as coisas certas

Um dos maiores desafios é determinar quais benchmarks são importantes. Isso geralmente exige um recuo e você precisa se colocar no lugar do seu cliente. Às vezes, mudanças simplistas no design do site significam enormes benefícios para o visitante da web. É por isso que gosto de ferramentas como o YSlow! que se concentram mais na experiência do usuário final do que no nível do servidor. Depois de decidir qual é a referência certa para o seu site, você pode começar a ajustar. Os benchmarks podem ser o tempo total de carregamento da página, o tamanho total da página, a eficácia do cache, a latência do site, etc. Você precisa escolher aquele que faz sentido para o seu aplicativo.

Porcas e parafusos

Você está rastreando os benchmarks certos, começando em um nível muito baixo. Eu gosto de usar o sysstat. Você pode obter uma grande quantidade de informações do sysstat e ajudá-lo a separar o sistema que pode estar limitando o desempenho geral do aplicativo. Geralmente, eu simplifico os problemas de desempenho em:

• pilha de rede
• pilha de memória
• disco io
• camada de aplicação
• camada os

Usando o sysstat e outras ferramentas, você pode começar a dividir os cabelos e encontrar o sistema que está limitando o desempenho.

Por exemplo, eu vi servidores altamente carregados falharem devido a como seu aplicativo foi configurado. O mau armazenamento em cache, a falta de expiração dos cabeçalhos no conteúdo estático, o uso de HTTP versus inclusão de arquivos, etc., contribuíram para o desempenho insatisfatório do aplicativo. Corrigir esses problemas de aplicativos não exigia alterações de hardware. Em outros casos, eu vi os discos no máximo, apesar de toneladas de cache. Mudar para discos mais rápidos resolveu o problema.

Enxaguar e repetir

Frequentemente, durante o ajuste do aplicativo, você irá abrir um gargalo para encontrar apenas outro. É por isso que recomendo tentar monitorar o que você está ajustando.

Por exemplo, digamos que você corrija um problema de IO no disco, mas seu aplicativo ainda está lento. Você pode pensar que você desperdiçou seus esforços, mas o que aconteceu é que você simplesmente acertou outro gargalo. Ao monitorar o IO do disco com cuidado, você pode ter certeza de que está aprimorando o IO do disco, mesmo que seus monitores de desempenho de aplicativos importantes não estejam mudando.

Obtenha as ferramentas certas

Verifique se você está usando as ferramentas certas para o trabalho. Monitoramento, teste, benchmarking, criação de perfil e outras técnicas de otimização têm uma variedade de ferramentas. Encontre a ferramenta que melhor corresponde à sua situação.

Regras de prática

Embora cada app seja único, eu acho alguns pontos de partida padrão:

• bancos de dados de memória adoram memória
• disco io, mas invasão 10 pode matar o desempenho do banco de dados
• otimizações incorretas - grandes valores não se traduzem em grande desempenho
• aplicativo - culpando o servidor pelo design inadequado do aplicativo

Seus próximos passos

Se você não encontrar o seu gargalo, adicionar um servidor pode não ajudar muito. Para resolver o disco IO você pode precisar de outro servidor ou SAN. Se você tiver um afunilamento de RAM, outro servidor resolverá o problema apenas por adicionar mais RAM. Movimento bastante caro comparado a apenas adicionar mais RAM ao seu servidor existente.

Correção rápida

Mais de implantar. Eu tive que fazer isso quando parece que a pilha de aplicativos é o problema. Basicamente carregar na CPU, RAM e disco IO (RAID 10, 15K SCSI ou SSD). Vá em frente no hardware e comece a sintonizar. Isso mantém você à tona até resolver os problemas.

    

Answer 4

Eu diria que o próximo passo deve ser o armazenamento em cache (caching de dados e / ou cache de páginas, dependendo da sua funcionalidade). Se memcached parecer muito complexo, você pode começar com soluções simples de cache de dados como Cache PEAR Lite , que requer apenas algumas linhas de código, mas poderia fazer enorme diferença. O cache de páginas (ou partes de páginas) é suportado pelo Smarty mecanismo de modelos, por exemplo.

Uma vez que o cache não funciona mais, você pode aumentar a quantidade de servidores, pois não resta mais nada.

    

Answer 5

Se você tiver memória RAM suficiente, o memcached ajudará você mesmo na mesma caixa. Tente armazenar em cache várias consultas mais pesadas e ver o que acontecerá. Além disso, o Apache é muito pesado, use nginx ou lighttpd (com o aplicativo PHP trabalhando através do FastCGI, consulte php-fpm ).

    

Answer 6

Inicie o cache, mas ignore o MySQL no momento. Seriouosly.

A regra deve ser - interromper um pedido O MAIS ANTECIPADO. Então, um proxy reverso ou um cache de nível apropriado do Apache vai te dar os melhores resultados, então o cache de resultados do nível SQL dentro do aplicativo, em seguida, o cache de nível sql;)

Quanto mais cedo você interromper uma solicitação, menos sobrecarga você terá. Nível de cache de saída - nem mesmo o PHP precisa ser executado, por assim dizer.