Precisamos trocar a partição em um servidor LAMP?


14

Nós realmente precisamos trocar partição no servidor ubuntu com LAMP? Acho que não preciso disso, mas é melhor ter certeza se isso não causará algum comportamento imprevisível.
Na verdade, meus pensamentos foram:

  • O servidor nunca hiberna
  • Se estiver trocando, é preciso pensar em balanceamento de carga / modelagem de tráfego, etc.

Estou certo, posso desativar a troca pelo servidor de produção?

Obrigado!

Respostas:


14

Estou certo, posso desativar a troca pelo servidor de produção?

Não. Sempre tenha algum espaço de troca.

Tentei rodar um servidor de produção sem troca uma vez e cerca de uma semana depois, após uma atualização do Wordpress, o PHP começou a consumir muito mais RAM do que tínhamos contabilizado. Quando você fica sem RAM e habilita a troca, as coisas ficam mais lentas (às vezes muito, às vezes apenas um pouco, dependendo do que é empurrado para lá), mas você pode fazer login, encontrar o problema e tentar corrigir isto.

Quando você fica sem memória RAM e não tem troca, os processos morrem, as coisas param e a maior parte do tempo sua única opção é uma reinicialização. Mas até que você reinicie, as coisas provavelmente vão quebrar.

No meu mundo, quebrar é muito pior que lento.

Obviamente, se você achar que seu sistema está constantemente usando grandes porções de swap (ele geralmente usa alguns apenas como uma maneira de remover coisas armazenadas em cache antigas), obviamente você tem um problema ("insira RAM por favor"), mas tê-lo como uma rede de segurança é definitivamente recomendada.


Em resposta ao comentário do SpamapS:

No mundo dos "sites bem-sucedidos", você possui failovers quentes, balanceamento de carga e outras ferramentas que permitem que uma máquina exploda e tenham efeito nulo no restante do site. Mas isso exige muito dinheiro. Ter hardware redundante não é econômico para a maioria dos sites, mesmo que eles recebam dinheiro.

Discordo completamente do seu comentário sobre o tempo de atividade. Em uma configuração tradicional de comércio eletrônico, se as pessoas não podem ver seu site, elas não podem comprar de você. Não se trata apenas de comércio eletrônico, todos os interesses comerciais on-line são muito mais criticados se você estiver deprimido por qualquer período. Eu sei porque hospedo sites e serviços para empresas e administro meus próprios sites. Lento = mal-humorado, mas Baixo = fúria. Mesmo se você ficar inativo por um minuto por vez, se um usuário receber um aviso de "manutenção em manutenção" mais de duas vezes, eles presumem que você não pode manter o site ativo.

Um servidor lento é menos do que o ideal, mas a troca não existe para ser executada o tempo todo, é o último recurso para permitir que as coisas continuem sendo executadas enquanto você as corrige.

Você também supõe que há apenas um serviço em execução na máquina. Novamente, isso pode ser verdade se você tiver megabucks para dividir tudo, mas no mundo real, as coisas ficam acumuladas. Vários sites, daemon ssh, servidores ftp, servidores de email etc. Um processo que entra no swap pode até afetar outro serviço. Sem troca, tudo tem uma chance igual de término instantâneo e aleatório. Você não tem controle sobre isso.

Claro que a troca não é a única resposta. Você precisa de monitoramento para alertá-lo quando estiver sem memória RAM, mas apenas desligar e reiniciar não é a resposta para a maioria das pessoas. Tenho certeza de que isso funciona para qualquer site multinacional pelo qual você seja responsável, mas para nós, meros mortais (que compõem a maioria da internet), isso é suicídio comercial.


As mesmas experiências aqui, meio que ... foi um erro do meu lado, não uma decisão deliberada. Um servidor sem swap é um inferno para reparar, especialmente se decidir matar o sshd.
Javier Rivera

Eu tenho cerca de 16Gb de RAM, a metade é armazenada em cache para E / S rápida, o resto é para LAMP, a troca é sempre gratuita ou algumas vezes há poucos megas, mas acho que está sempre desligada ...
Arman

3
No mundo dos sites de sucesso, a falta de resposta é pior do que falha. Os usuários realmente apreciarão uma falha FAST (que, seu código de front-end javascript deve lidar com btw), mas eles o odiarão por serem lentos. Abandone a troca, apenas atrasa o inevitável. -1
SpamapS

1
@Oli: A execução do N + 1 não leva mais megabucks nem muito dinheiro. De fato, dificilmente são necessárias habilidades especiais. É inevitável que um servidor seja desativado por várias razões, e não é difícil impedir que isso não seja um problema. Se você tem um servidor LAMP independente fazendo tudo, então o que custa mais; Configurar mais dois e um balanceador de carga (no EC2 com snapshots t1.micros e EBS, isso pode ser MUITO barato) ou o site está ficando inusitavelmente lento no maior dia? Verifique os dados do google ... eu acho que é bit.ly/hB1AD1
#

1
Ótima resposta, cobrindo casos de servidores do mundo real. Adicionar hardware redundante, LB, monitoramento, caches de RAM, etc, é incrivelmente importante, e você terá tempo para configurá-los e depurá-los se não estiver zanzando porque gastou pouco com o espaço de troca.
ImaginaryRobots

4

Eu tenho que discordar de ter trocado em servidores de produção.

Na minha experiência, a troca de disco rotacional torna seu sistema menos previsível e mais propenso a frustrar falhas de todo o sistema. Um servidor popular e de alta carga que está fazendo qualquer coisa com um disco lento local rapidamente se transforma em algo muito pior do que um estado de falha. O tempo de resposta aumentará para 100x o nível normal, e coisas simples, como fazer login via console ou ssh, podem levar alguns minutos.

A troca de SSD é um caso especial e removeria pelo menos o tempo de busca mais lento que normalmente mata o sistema. No entanto, as gravações ainda são lentas, então você ainda vai esperar muito, muito tempo para se recuperar de um processo fora de controle.

Sem troca, seu servidor LAMP simplesmente interrompe os processos para liberar RAM. O monitoramento adequado deve alertá-lo e remover servidores da produção se processos críticos forem mortos. O pior caso aqui é que seus métodos de login são todos eliminados e você precisa fazer um ciclo de redefinição / energia. Esse pior caso ainda é tão provável com uma máquina de troca fora de controle, mas muito mais difícil de detectar.

Se você estiver usando PHP, ative os limites de memória e monitore seus logs quanto a falhas. Aqui está um truque: defina o limite mais baixo no servidor de desenvolvimento do que na produção. Se você estiver usando o mod_php no apache, defina MaxRequestsPerChild para alguns milhares, para que o httpd morra antes de crescer muito com o tempo. Acima de tudo, monitore o uso da memória! Muitas vezes, a memória aumenta com o tempo e você só precisa reiniciar um serviço com vazamento periodicamente enquanto depura o problema.


1
Obrigado por compartilhar sua experiência. Eu estava contando com problemas semelhantes, quando o ssh estava tomando Inf. Eu apenas forcei os processos a terem memória limitada, o que me permitiu executar o ssh e corrigir scripts de buggy.
Arman

Uma das discussões mais interessantes sobre troca de espaço na produção que eu já vi na internet. (toda a linha, pro & contras)
dpb

3

O espaço de troca é usado quando o sistema decide que precisa de memória física para processos ativos e há memória física não utilizada suficiente disponível. Se o sistema precisar de mais recursos de memória ou espaço, as páginas inativas na memória física serão movidas para o espaço de troca, liberando a memória física para outros usos.

Esta situação acontecerá muitas vezes no servidor.

uma). Um script não otimizado pode consumir grande quantidade de memória
b). Scripts como backup sempre consomem muita memória
c). trafégo pesado

Portanto, é uma boa prática ter algum espaço de troca.

Mais detalhes: https://help.ubuntu.com/community/SwapFaq


Obrigado pela explicação. Se alguém tiver um script de buggy, em qualquer caso, você travará o servidor, os limites do sistema devem controlar seus scripts, não é?
Arman #

aneeshep, se você estiver trocando durante tráfego intenso, seu sistema será 100x mais lento do que deveria normalmente. Isso geralmente não é aceitável.
SpamapS

2

O uso de swap fornecerá uma proteção adicional contra a instabilidade do servidor. Pode haver momentos em que a RAM esteja acabando e no servidor sem troca que pode resultar em uma falha suave.

Provavelmente estou na minoria agora, quando digo que ainda faz sentido, como costumavam recomendar, ter o dobro da troca que a memória principal. Mesmo em um sistema com 96GB de RAM.

Não custa muito e, se você precisar um dia, ficará feliz por ter conseguido. A razão para ativar a troca é apenas uma análise de custo-benefício muito direta. Faça! :-)


0

Gostaria de agradecer a Oli pela bela - eu sei antiga - resposta. Acho que o particionamento é um tópico sempre verde! Eu concordo totalmente com a linha do post de Oli e gostaria de compartilhar esse script - é claro, improvável - que eu uso para monitorar o uso de swap dos meus servidores.

Eu sempre configuro servidores e serviços para operar sem ocorrência de troca. Quando isso acontecer, verifique se algo está dando errado ou, na melhor das hipóteses, que algo está superando seus planos iniciais.

Cronto esse script a cada meia hora no ambiente de produção. Ele me enviará uma notificação se Trocar uso! = 0k. Serei capaz de investigar / tomar ações prontamente sobre o problema, na maioria das vezes, antes que tudo dê errado .

Espera que você tenha: comando bash, top, echo, awk e um email de trabalho, sem executar nenhuma verificação.

Espero que ajude.

#!/bin/bash
CURRSWAP=$(top -b -n1 |grep Swap |awk '{print $4}')
ECOMM="echo $CURRSWAP means healthy, I wont take any action."
CURRDATE=$(date)
MAILDST="your@email.addr"

case $CURRSWAP in
  [0]k) $ECOMM
        exit 0
        ;;
  *)    echo -e "Server: $HOSTNAME \n Date: $CURRDATE \n Current Swap partition usage: $CURRSWAP" | mail -s "Warning from $HOSTNAME" -- $MAILDST
        exit 0
        ;;
esac
exit 0
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.