Alguém mais está vendo isso? É um fórum bastante modesto em termos de tamanho e tráfego. Há quatro processos de worker do pitchfork, e parece que um deles está processando a grande maioria das requisições recebidas e usando mais memória do que os outros. Há bastante swap em uso, e ao reiniciar o pitchfork deliberadamente, isso diminui consideravelmente. Portanto, concluo que os processos do pitchfork têm muitas páginas frias atualmente trocadas para o swap.
Isso ocorreu após 20 dias de operação, em uma máquina com 4 GB de RAM e 4 GB de swap.
Não seria bom ficar sem espaço no swap. Também não seria bom ver todo esse swap sendo trazido de volta para a memória, o que poderia acontecer quando o pitchfork eventualmente fizer uma coleta de lixo (garbage collect).
Alguém mais está vendo algo parecido? Por favor, compartilhem a configuração da máquina!
A saída do vmstat mostra que não há pressão de memória no momento - não há atividade de paginação. Minha preocupação é que existe um perigo, não que minha instalação esteja funcionando mal no momento.
Eu ficaria interessado em ver as estatísticas de um fórum mais movimentado. Parece que o número cumulativo de requisições é importante, e o meu, de forma alguma, é muito movimentado.
Sim, as diferenças de RSS são relativamente modestas, mas, variando de 300M para 500M, há uma diferença considerável em termos proporcionais.
Mais impressionante é o uso de swap. Antes de reciclar, antes de sacar as forquilhas, eu vejo:
# free
total used free shared buff/cache available
Mem: 3904968 1888140 77308 679004 1939520 1147220
Swap: 4194288 1226344 2967944
e depois:
# free
total used free shared buff/cache available
Mem: 3904968 1486412 1422380 640744 996176 1587908
Swap: 4194288 309892 3884396
Parece-me que 1300M foram liberados pela reciclagem (diferença de used+swap)
Não acredito que tenha visto a necessidade de tanto swap ao usar o unicorn: por isso o título.
Como disse, ficaria interessado em ver números de outras instâncias.
É normal que um único processo do Pitchfork assuma a maior parte da carga — os outros processos só são acionados quando o primeiro está ocupado. Também é normal que o uso de memória aumente com o tempo. Embora ele deva eventualmente atingir um estado estável, uma vez que tudo, como caches e o ruby-JIT, esteja aquecido.
Aqui está um gráfico de um dos nossos clusters de produção, cobrindo um período de 7 dias. Ele rastreia o processo com o maior uso de memória. As linhas tracejadas em verde indicam deploys (ou seja, inicializações novas do Pitchfork):
Portanto, você pode ver que a memória cresce após a inicialização, mas depois se estabiliza em pouco menos de 1,4 GB. Este cluster atende a centenas de sites, então talvez não seja a melhor comparação em termos de números… mas, espero que a visualização do crescimento seja útil.
Olhar apenas os números de RSS por processo não conta a história completa. O Pitchfork é um “servidor web de forking”. Ele inicia o processo "molde
Visualização útil, obrigado. Eu não diria que isso se estabilizou, mas a taxa de crescimento não é tão alta quanto antes.
O reforking periódico parece ser uma ótima coisa para trazer — se você puder, por favor, registre aqui quando isso for implementado.
Você pode dizer algo sobre as linhas verdes? Estou interessado em saber quando (se é que alguma vez) as pitchforks fazem uma coleta de lixo, o que a causa e qual é o efeito enquanto ela está sendo executada.
As linhas verdes indicam quando fazemos o deploy de atualizações. Basicamente: ./launcher rebuild app.
Ruby (e JS, que executamos dentro dos processos Ruby via MiniRacer/v8) estão constantemente fazendo coleta de lixo durante a execução e em resposta a sinais do sistema operacional. Portanto, acho que não há nenhum grande benefício em fazer algo manualmente.
Obrigado. Eu ficaria interessado em ver como as coisas funcionam a longo prazo, o que não fica evidente em um servidor que é atualizado com relativa frequência. No meu caso, eu tinha 20 dias, depois escolhi usar o pitchfork para reiniciar, o que me deu alguma informação, mas também reiniciou o cronômetro.
