Há um tempo li nesse mesmo fórum um comentário de um usuário que afirmou veementemente que o Linux travaria caso a RAM ficasse muito cheia ou próxima disso. Na época lembro de afirmar que isso não ocorreria justamente pelo recurso de Swap (paginação). Já que no meu Notebook de uso diário só tenho 4Gb de RAM decidi printar como é seu uso de memória basicamente todo o tempo em que estou utilizando o mesmo. E como uma imagem “vale mais que mil palavras” rs segue o print do sistema funcionando com seu uso quase total da RAM física.
De toda forma não recomendo comprar de computadores com 4Gb hj em dia, pois já se mostram bastante insuficientes para um uso mais hard e confortável.
Então NÃO, não é verdade que seu Linux irá simplesmente congelar do nada quando estiver usando muita RAM. Isso depende de muitos outros fatores extras.
Cara, eu vou te dizer que sim, porque aconteceu comigo.
Um tempo atrás estava com um PC de 5 GB de RAM (na verdade, 6 GB, mas 1 GB é para o vídeo) e usava a metade disso de Swap (cálculo da zRAM).
Nisso, ao jogar Rocket League e tendo feito umas 5-10 partidas, ele travava, e daí só resetando o PC! Isso porque a memória e Swap enchiam conforme o jogo demandava a cada nova partida.
Era nítido, pois quando iniciava o jogo estava usando 4 GB de RAM e 1 GB de Swap, e, conforme eu ia jogando partidas, começava a dar umas travadas quando atingia ~4,7 GB de RAM e ~2,3 de Swap.
Vale ressaltar que, diferente de uma partição Swap ou arquivo de Swap, a zRAM usa a própria RAM como área de troca, sendo mais rápido, mas demanda um certo uso de CPU, que também não era muito potente.
Não durou muito e eu aumentei a zRAM, o que deu uma solucionada, mas, ainda assim, esperava antes que o sistema fechasse o jogo ou algo do tipo.
Então… já aconteceu comigo, o gnome dava umas congeladas muito esquisitas no meu notebook do trabalho, porém eu acredito que era alguma configuração incorreta, não lembro se na época eu utilizava o zram, porém hoje em dia não sofri mais com algo do tipo. A minha experiência ultimamente está bem solida e estável, estou utilizando zram.
Em situações normais, sistemas baseados em Linux assim como qualquer outro sistema moderno, consegue gerenciar o uso de recursos até o seu limite sem travar. Mas, existem várias variáveis aqui que nem sempre estão relacionadas com o sistema operacional:
Alto consumo de RAM pode indicar alta dissipação de calor, o que pode travar sistemas com baixa capacidade de arrefecimento.
Configurações não otimizadas de RAM, podem forçar o controlador de memória do processador, gerando aquecimento e instabilidade, o que pode levar a um congelamento.
Vazamentos de memória nos programas utilizados, pode também, inibir a capacidade do sistema operacional gerenciar os recursos e causar congelamentos.
Estes são apenas alguns dos cenários mais comuns que consigo lembrar, então, em uma situação normal nenhum sistema operacional deveria travar quando qualquer recurso é utilizado em sua capacidade máxima. Porém, existem muitos outros fatores para serem considerados em cada caso.
Minha resposta para se trava ou não, seria algo como: não deveria travar, mas se travou é preciso olhar com atenção todo o contexto do setup.
Taxa de uso da RAM: Se um programa dispara a a consumir memória, é possível que não haja recursos do computador para transferir a memória “antiga” para swap, causando lentidão no computador como um todo, no limite chegando ao travamento total de fim de memória (OOM).
Necessidade de RAM: Se é necessário mais memória do que disponível fisicamente e swap, não tem milagre. A corda vai arrebentar em algum lado. Quando o programa é bem feito, causa erro no próprio programa como “não há memória para um novo arquivo” antes mesmo de detonar o computador. Programas pesados como os navegadores costumam monitorar a memória disponível e ir liberando ram para evitar o travamento, geralmente liberando abas já carregas.
Travamento OOM (sem memória disponível): Quando não há mais nenhuma memória disponível e mesmo assim programas continuam pedindo, o kernel vai entrar em um modo de sobrevivência no qual ele para de executar comandos dos programas e passa somente a resolver o problema da falta de RAM. Nesse ponto o computador trava completamente mesmo, porém o kernel está trabalhando e matando processos que tenham maior uso de RAM. É comum que dentro de 10 segundos a 2 minutos o computador volte a funcionar (demora mais se for hdd com swap). Porém a maioria dos usuários não vai ficar esperando mais do que 10 segundos com um computador travado e já vai reiniciá-lo forçosamente.
Vazamento de memória em programas: As vezes o vilão não é o sistema e nem a quantidade de memória do computador. É possível que algum programa tenha bug em gerenciamento de memória e passe a usar cada vez mais memória, chegando ao limite do computador. Quando taxa de consumo é lenta, é comum o computador começar a engasgar como uso do swap. Mas se for uma taxa rápida, pode chegar a travar completamente mesmo. É fácil detectar isso acompanhando o uso de memória dos programas e também pelo fato de ter os sintomas sempre quando o mesmo programa é usado. Nesse caso se possível tente atualizar o programa ou usar uma versão anterior.
Conclusão:
Não depende apenas do gerenciamento de memória do kernel, mas também é responsabilidade dos programas serem bem-feitos evitando situações limites.
Em geral, sem nenhum software extra, como earlyoom e afins, sistemas Linux tendem a congelar quando tentam usar memória não residente em uma quantia maior do que o que está disponível em RAM + Swap, mesmo que você tenha SSDs.
Esse comportamento costuma ser o que as pessoas esperam para servidores, onde você quer tentar ao máximo evitar um desastre onde não ha alguém para perguntar “o que devo descartar?”. A pessoa pode preferir esperar N minutos do que perder algo importante em execução, devido ao peso que esse “importante” costuma ter em servidores.
Em desktops e afins, eu sou da opinião que soluções automáticas como o OOM killer, não fazem muito sentido e acho que esta seria a melhor solução:
Com swap sobrando ainda…
Quero ver no colapso dos 90% tanto na RAM quanto swap pra ver se não entra no hardfreeze
Até hj forço o Windows no ponto de colapso sem medo de ter um problema do gênero, agora no Linux fico no receio de abrir mais de 3 apps por causa desse bendito problema, o earlyoom já ajuda mas no colapso extremo não vai ter como… O dedo já vai tá no botão de desligar pq esperar horas pra ver se sai do hardfreeze não e a minha praia
Bom o “ponto” foi sobre a RAM física e não a Swap rs. Justamente o que não fez meu computador “travar” ao quase chegar no limite da RAM física foi o uso em conjunto com a Swap.
Existe uma forma de fazer vc sentir travada so do sistema precisar fazer swap, é so mudar para swappiness=0. é por isso que o meu fica 100, coloca ai e dps coloca para fazer swap.
Dps para voltar o default do Linux é =60.
Até 10 Janeiro 2020, eu tinha 4 GB RAM DDR2, num 2 x Core2 Duo, com apenas iGPU Intel (onboard).
Alguns anos antes, eu verifiquei que 32 “tabs” abertas no Chromium / Chrome eram o limite. – Além disso, o bicho pegava. – Então, me acostumei a manter apenas 4 “tabs” abertas, no máximo 6 em caso de necessidade (e mantenho esse hábito até hoje, com 16 GB RAM, i5-9400, 6 núcleos).
Mas naquela época (2019-2020), eu usava compositor XRender (em vez de OpenGL2.0; pois o hardware não permitia 3.1). – Hoje, minhas distros com KDE parecem não oferecer essas opções.
Naquela época, eu também desabilitava “Hardware acceleration” do Chromium / Chrome na maior parte das minhas distros – e uBlock Origin, para enfrentar a maior parte dos “portais”, que usavam e abusavam de tralhas paralisantes.
E assim por diante. – Eu precisava adotar várias opções (como essas), para conseguir trabalhar sem sofrer “congelamentos” e outros problemas similares.
Com essas providências, eu não tinha congelamentos, nem travamentos.
Eu não podia usar Google Earth. – Isso estava fora das possibilidades do meu hardware, até 10 Janeiro 2020.
Quando “montei” meu hardware atual – i5-9400 etc. – meu objetivo era, justamente, superar aquelas limitações.
Quando eu usava um laptop de 2007, com um Core 2 Duo + 2GB de memória, tinha o costume de deixar apenas duas abas, e, dependendo do navegador, até isso era demais
Fui perdendo o costume de monotarefa com o tempo, conforme fui adquirindo hardware melhor, e, hoje em dia, às vezes me pego com 30, 40 abas abertas no Chrome. Eu ainda não adquiri o costume de manter vários programas abertos ao mesmo tempo, no entanto.
Para completar a resposta do Eddie, e mostrar na prática o sistema com alta carga de estresse e numa situação atípica de vazamento de RAM - com uso intenso da mesma, tendo que recorrer a swap - veja um vídeo antigo que gravei (pré-histórico kkk) num cenário que ilustra bem o gerenciamento de memória RAM do kernel Linux em momentos cruciais.
Isso demonstra a capacidade de lidar com a situação, e se não tiver outro impedimento - além do aspecto uso de RAM - dificilmente o sistema vai congelar (pode ficar mais lento, no entanto travar tudo puramente por falta de RAM é bem mais complicado).
O meu sistema Debian 12 tem 20GB ram , 1 GB de swap criado por padrão.
O swappness tá setado como 5, pra só usar swap depois de 95% da ram ocupada. Ele usa swap em transferência de arquivos grandes (de 4gb , 10 gb) e deixa grande parte da ram em cache , cerca de 15GB.Até agora, funciona normal, sem travamentos.
Poisé, não quis criar partição swap no SSD, pq li em algum lugar que diminuiria o tempo de vida dele. Mas falha minha. Agora estou criando um swap file pra ver se resolvo o problema. Vou criar num HD mecânico…
ja aconteceu comigo tambem, tenho um samsung book e estava jogando com o firefox minimizado tocando o youtube, congelou diversas vezes ja que tenho pouca memoria ram.
