Ola pessoal. Conforme imagem a seguir, percebe-se que nos programas graficos o consumo de memoria ram fica em torno de 6GB e no terminal fica bem menor. Por que isso acontece?
Esse tema dai já deu o que falar uma vez, não necessariamente aqui no fórum, mas na gringa. Pelo que entendi, o KSysGuard eleva um pouco o consumo de memória, por isso mostra um consumo maior fora que, pelo terminal, mostra em Gigabit e na GUI mostra em Gibibyte.
Nota: 4.6 Gi = ~5.36 GiB
Não sei se você rodou primeiro o comando free -h e abriu o KSysGuard em seguida ou o caminho inverso, logo isso influência ao mostrar o consumo também.
Porém essa tá sendo uma diferença bem aguda mesmo assim…
2 curtidas
Como o @JG22 comentou, há uma certa variação entre a maneira que cada software trata a leitura que ele faz, o Dio até fez um video sobre isso:
3 curtidas
Cada programa vai ter seu método de mostrar a memória usada. Isso acontece porque o gerenciamento de memória é complexo e há várias situações específicas. Brevemente explicando:
- Uso de memória dos aplicativos: Efetivamente usada por cada processo de usuários.
- Uso de memória dos aplicativos e compartilhada: Usada por bibliotecas que são compartilhadas entre diversos programas (chamada por pgramas de usuários).
- Uso de memória do sistema: Efetivamente em uso pelo kernel e programas que rodam com id que não são de usuários.
- Uso de memória de sistema em cache: Em uso pelo kernel para acelerar o computador mas que pode ser descartada a qualquer momento para uso dos programas
- Uso de memória de buffers: Em uso pelo kernel para acelerar acesso a disco.
- Memória livre: Efetivamente sem estar em uso (tende a ficar próxima a zero)
Mas claro que se vc perceber, memória em cache e buffers podem ser contabilizadas como livre se vc imaginar que elas podem ser descartadas a qualquer momento.
4 curtidas
Só umas dicas sobre o comando free para complementar a resposta do @JG22:
É possível os valores serem exibidos em Gibibytes no terminal também rodando o comando free -g e para evitar que o comando free exiba valores desatualizados, caso você abra um software posteriormente, basta utilizar o comando free -s 1 que, nesse caso, os valores serão atualizados a cada 1 segundo, sempre lembrando de combinar os comandos free -hs 1, por exemplo, para que os valores sejam exibidos em Gigabytes e atualizados a cada 1 segundo, nesse caso.
1 curtida
Há a explicação disso no GitHub do neofetch.
Em resumo, a saída do free está errada, pois não leva em conta a memória compartilhada, arquivos temporários, entre outras coisas que consomem memória RAM, mas não são os aplicativos em si.
Apenas o free e o ksysguard ainda usam esse algoritmo incorreto, no entanto.
2 curtidas
Então acaba sendo até mais fidedigno verificar o consumo de memória RAM pelo neofetch?
Sim. Ou pelo Conky, pela Polybar, pelo novo monitor do sistema do KDE, etc.
Como o FAQ disse, em 2016-17 esse bug foi corrigido na maior parte dos apps, sendo o Ksysguard e o free os grandes “remanescentes”.
O próprio free meio que admite o erro, se você subtrair a coluna “Total” de “Disponível”, vai dar um valor diferente da coluna “Em uso” (e bem próximo do reportado pelas ferramentas com a fórmula corrigida).
1 curtida
Estranho pois o gerenciador que o OP está usando é o novo do KDE… Por isso minha dúvida.
O ksysguard é o antigo monitor de sistema, se eu entendi o motivo da confusão.
1 curtida
Pra saber qual e o certo tem que ver onde o sistema vai comecar a travar de fato, pois no windows quando bate os 100% de uso de RAM o computador fica super lento. Aqui n seria diferente
Nunca consegui entender os critérios do “Monitor do Sistema” do KDE (KSysguard). ─ Só sei que são totalmente diferentes dos critérios do “Monitor do Sistema” do Gnome, porque já abri os 2, lado a lado. ─ Não concordam, de jeito nenhum!
Pelo que vejo agora no Mageia (KDE 5.20.4), o KSysguard parece acompanhar os números do free e do top (ambos, ferramentas do procps) ─ o que dá números bastante pequenos:
(dividindo 2.735 MiB por 1.024 = 2,67 GiB)
Infelizmente, neste momento estou no Mageia, que ainda não tem esse novo recurso “SysMonTask”, por isso não posso comparar com o KSysguard agora.
Até meados de 2020, o htop e o Conky seguiam outro critério de cálculo, que era bem conhecido, embora antigo. ─ Isso ainda acontece no KDE Neon (abaixo):
Atualmente, várias ferramentas estão adotando um cálculo “novo”, proposto ou subscrito por Linus Torvalds em 2014, usando números disponíveis desde o Kernel 3.14. ─ Mas, neste momento, cada distro está usando versões diferentes dessas várias ferramentas, o que é extremamente confuso.
2 curtidas
3 curtidas
Nao tem certo e errado, são formas diferentes de fazer o cálculo. Vc mesmo pode fazer o calculo de acordo com as especificações no man. Aparentemente sua placa de video nao dever estar compartilhando a ram né…
O kernel linux oferece um arquivo com as variaveis sobre informações de memória :
$ less /proc/meminfo
Ps: atualizei o post minimamente
3 curtidas