Acabei de fazer uma série de atualizações e decidi que a maneira mais fácil de resolver os erros de memória era simplesmente dobrar o swap para 4 GB. A desvantagem é que em um droplet de 1 GB há apenas 25 GB de SSD, então perder 4 GB para swap é uma quantidade significativa de espaço, e já está um pouco apertado com apenas 25 GB.
Então, devemos alterar o discourse-setup para que o padrão seja 3 GB?
O que você acha, @Falco?
Se isso resolver o problema, sou totalmente a favor.
Posso sugerir fortemente que o script de instalação também defina os dois ajustáveis do kernel que afetam o gerenciamento de memória? Seria bom saber que todos que aparentemente têm um problema têm pelo menos um ponto de partida de uma boa configuração do kernel.
Esta me parece uma ideia sensata. Não consigo imaginar onde os THPs seriam valiosos em uma instância dedicada de discourse, e o overcommit pode ajudar a evitar OOM.
Poderia considerar oferecer cada um desses separadamente, definindo-os como a resposta padrão, com a opção não padrão de desativar?
Além disso, o script pode usar sysctl para descobrir se as configurações precisam ser alteradas em primeiro lugar antes de fazer uma alteração. Se alguém já fez essas alterações com arquivos diferentes, seria potencialmente confuso criar substituições duplicadas. Acho que nem todas as distribuições Linux vêm com o overcommit de memória desativado em primeiro lugar.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
Com o risco de diluir a importante mensagem sobre os ajustáveis do kernel, há uma segunda consideração: o script atual cria swap apenas em uma máquina com pouca RAM. Acho que isso é um erro, tanto porque o swap ainda é útil para maximizar a utilidade da RAM, mas mais importante porque causará problemas se alguém criar seu Discourse em uma máquina com muita RAM, por velocidade ou conveniência, e depois reduzi-la para pouca RAM.
A configuração deve criar swap em todos os casos (a menos que já haja o suficiente). É válido e às vezes útil ter vários arquivos de swap.
Eu não sou quem decide, e eu defino isso em máquinas que configuro, mas este é um script shell que é executado pela (maioria) de todos que instalam o Discourse. Ele precisa ser o mais simples possível, e temos certeza de que essas configurações funcionam em Raspberry Pi e Mac e qualquer outra coisa que as pessoas tentem fazer? E qualquer método que você use para testar se já está definido funciona em todas essas plataformas? Parece difícil.
Eu escrevi discourse-setup e acho que fazer alterações nele é um pouco assustador.
Oferecer sempre a criação de swap não é uma má ideia. Talvez oferecer sempre a configuração de 3 ou 4 GB de swap? Mas então, quanto? Uma regra geral que eu conhecia era ter swap do mesmo tamanho da RAM. E agora, se você não criar swap, sua única opção é sair com control-c. Então, ou vamos forçar as pessoas a criar swap ou adicionar outra pergunta Sim/Não (o que me fará modificar meus scripts que executam discourse-setup 
) Ah! Ou podemos ter isso controlado por um switch --skip-swap. Isso parece bom para mim. Se você for inteligente o suficiente para saber sobre swap, poderá encontrar o switch para ignorá-lo; podemos adicionar uma nota sobre o switch nessa mensagem de AVISO.
E talvez também adicionar uma nota sobre --skip-connection-test quando falhar.
Eu acho que se eles já têm swap configurado, é seguro assumir que eles sabem o que estão fazendo.
Obrigado! E sim, entendi perfeitamente, eu sentiria o mesmo. Precisa de pensamento cuidadoso e testes, com certeza. E isso seria em pelo menos alguns provedores de hospedagem com máquinas baratas, e também em Raspberry Pi. Não tenho certeza sobre Windows ou Mac - se eles devem ser suportados, então suponho que sim. Eu esperaria que eles fossem mais prováveis de serem usados como máquinas de desenvolvimento, o que é uma história diferente.
De fato. O que parecer ser necessário no momento, talvez. Parece ter dado um passo adiante. Mas me entristece muito não saber se esses relatórios incluem ou não o ajuste de overcommit. Tenho quase certeza de que sabemos por discussões anteriores que o overcommit faz a diferença.
E sabemos que em uma instância de 25G e ainda mais em uma instância de 20G o espaço em disco é limitado. Estou rodando em tais máquinas: disco de 25G e 1G de RAM, que já precisa de 2G de swap e provavelmente mais hoje em dia; e disco de 20G com 2G de RAM onde atualmente tenho 1G de swap.
Eu não recomendaria mais perguntas Sim/Não. Opções de linha de comando parecem um caminho melhor.
Se vamos mudar este script, acho que recomendaria vários swapfiles de 1G, porque isso maximiza a flexibilidade, não desperdiça nada e é o momento mais fácil para tomar essa decisão.
Não tenho tanta certeza sobre isso. Se a menor instância com Ubuntu ou Debian puro já tiver algum swap - isso precisaria ser verificado - então começamos a ter problemas se não for suficiente. Muito melhor medir RAM + swap usando free, ajustar como de costume para as configurações abaixo de 1G existentes (AWS, acho, talvez Oracle) e, em seguida, adicionar swapfiles de 1G até um número acordado, o que quer que seja no momento. Espero que um total de 4G seja suficiente, com o overcommit do kernel configurado apropriadamente.
Estou feliz em ajudar.
Hmm. Sim. Gostaria de ter pensado em verificar isso nos que acabei de ajustar.
Hmm. Sou da opinião que um é melhor, mas múltiplos adicionam flexibilidade e seria possível fazer o discourse-setup adicionar outro arquivo de swap se mais swap for necessário, o que significa que poderíamos dizer a todos para executar o discourse-setup para “corrigir” seu problema de swap. E talvez também a questão do overcommit também - talvez tentar explicitamente fazer isso apenas para Linux, já que é tudo o que nos importa.
Discordo. Swap não é um bem universal. Costumava ser importante para tornar o código da VM mais uniforme quando não estava trocando em certas circunstâncias, mas os algoritmos da VM mudaram.
Isso se baseava em heurísticas de código de kernel muito antigas que não se aplicam mais.
Além disso, ao considerar a medição: eu nem sei o que você gostaria de fazer para medir swap e memória quando o zswap está em uso. Este é provavelmente um caso de “primeiro, não cause danos”, no entanto.
Tenho quase certeza de que a única desvantagem de “muito swap” é usar mais espaço em disco do que o absolutamente necessário. É uma razão pela qual seria preferível ter vários arquivos de swap de tamanho modesto - pode-se desativar e remover progressivamente, se houver necessidade de recuperar o espaço em disco. Além disso, acho que o Linux faz um bom trabalho em usá-los progressivamente:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
A situação em que nos encontramos é que instâncias baratas são bastante limitadas em RAM e espaço em disco, e o Discourse usa cada vez mais, à medida que os muitos pacotes dentro dele evoluem. Mas, ainda assim, acho que há maneiras de navegar nisso com sabedoria, para ajudar aqueles que não estão em posição de simplesmente desistir e dobrar ou quadruplicar sua conta mensal.
A troca é lenta o suficiente para que eu não consideraria “quase sem espaço agora” como um motivo para adicionar mais de 1 GB à sugestão padrão neste momento. Cada 1 GB é muita troca, como experimentado em uma instância dedicada do Discourse.
Sim, por padrão, o Linux usa a troca em ordem de prioridade, e é possível usar a mesma prioridade em vários dispositivos para explicitamente distribuir a troca. Mas adicionar muita troca para sites pequenos não é particularmente valioso, eu sugeriria.
Portanto, se após cerca de uma década as pessoas ocasionalmente esbarram em 2 GB, eu sugeriria mudar para 3 GB em vez de 4 GB como padrão. E a quantidade necessária de troca para uma instância dedicada do Discourse não deve aumentar particularmente com a memória, porque o conteúdo que seria realmente trocado não muda particularmente muito.
A ideia de aumentar a troca com mais memória vem principalmente da computação de propósito geral, baseada em uma suposição generalizada de que quanto mais RAM você precisa, maior a demanda provável. Mas a pressão de troca em uma instância especializada do Discourse não deve seguir esse padrão, eu acho.
THP são específicos para plataformas que suportam páginas grandes, o que não são todas as plataformas. A maneira genérica de lidar com isso é verificar se ele existe. Em um Raspberry Pi que tenho:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
Em contraste, o overcommit é um parâmetro geral de VM para Linux nas últimas décadas. No mesmo Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Analisar a saída do free no shell é meio chato. Falando como o autor original do procps, para isso eu apenas procuraria por SwapFree em /proc/meminfo. 
Concordo que em nossos mundos com custos restritos, dimensionar o swap pelo tamanho da RAM não é mais um bom plano. A próxima ideia historicamente parece ter sido que a RAM é enorme e você não precisa de swap. Depois disso vem a sabedoria de que algum swap é útil porque permite um melhor uso da RAM. (Em um mundo sem restrições, teríamos enormes quantidades de RAM, mas isso é um nicho.)
O que estamos vendo nestes últimos dois meses é mais gente tendo problemas de falta de memória e falhas na reconstrução. Mais gente descobrindo que atualizações pela web falham, mas pela linha de comando funcionam. De uma perspectiva simples de suporte, e da perspectiva da reputação do produto, acho que precisamos de uma mudança no conselho usual e na configuração usual. Acho que 3G de swap é a mudança mais simples e menor, e deveríamos fazer isso se não fizermos mais nada.
Mas ainda acho que múltiplos arquivos de swap menores são uma escolha mais sábia - e vimos tópicos de suporte aqui que apontam para isso. E ainda acho que seria melhor tentar dimensionar RAM+swap porque esse é o fator limitante, a coisa que causa problemas às pessoas. Pode ser que existam maneiras diferentes de fazer esse cálculo. As ressalvas usuais se aplicam sobre quais táticas são sustentáveis, compreensíveis e terão longevidade.
Quanto às páginas enormes transparentes (transparent huge pages), meu entendimento é que o “transparente” é o que causa problemas: o kernel pode se debater, mesclando e desmesclando, para um impacto no desempenho e nenhum grande benefício. Tenho quase certeza de que hugepages são desaconselhadas para sistemas menores.
É mais sobre as características da carga de trabalho do que o tamanho do sistema. Em um sistema com 1 GB de RAM e processos razoavelmente estáveis com blocos de RAM, as hugepages padrão de 2 MB podem reduzir o thrashing do TLB e melhorar o desempenho; o TLB não começa a cobrir os mapeamentos para 1 GB de RAM. É geralmente apenas uma troca entre a CPU gasta procurando memória para coalescer e as falhas de cache do TLB, e existem muitas cargas de trabalho em máquinas de 1 GB que podem se beneficiar consideravelmente do THP. (Muitas recomendações para desativá-lo vêm do início de sua implementação; ele foi substancialmente aprimorado desde então.) A recomendação para desativar o THP para Discourse não é por causa do tamanho de 1 GB de RAM, mas é específica para o uso do redis com persistência em disco, que é algo que o Discourse usa:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
Infelizmente, quando um kernel Linux tem páginas enormes transparentes habilitadas, o Redis incorre em uma grande penalidade de latência após a chamada
forkser usada para persistir em disco. Páginas enormes são a causa do seguinte problema:
…