[Resolvido] Aumento de uso de Memória RAM em 4 distros

[frc_kde]

Uso o KDE desde 2007 (Kurumin) e comecei a monitorar minhas distros pelo Conky desde 2016, quando desativei / removi os serviços PIM-Baloo-Akonadi pela primeira vez.

Ao longo de 2016-2019, vi diferentes usos de RAM na inicialização ─ de 332 MiB (Devuan) a 565 MiB (Fedora), conforme a quantidade de serviços de cada distro, em meu antigo hardware de 4 GB de RAM, ─ e esses números apresentavam apenas um leve aumento residual, de um semestre para outro.

Todas, sempre com KDE.

Este ano, com um novo hardware de 16 GB, instalei quase todas as mesmas distros que tinha antes, e o uso de RAM foi um pouco maior, de 480 a 650 MiB na inicialização, de acordo com os serviços de cada distro. ─ Talvez, devido a novos Kernels, novas versões do KDE, ou maior exigência do próprio hardware, ─ ou talvez porque, havendo folga de RAM, as distros tendam a usar um pouco mais (cache), para agilizar.

Até aí, me pareceu tudo normal ─ com um leve aumento residual ao longo dos meses.

Houve um aumento moderado, no PCLinuxOS, quando alterei uma configuração para UXA (ou algo assim), em Março. ─ Em Agosto, fiz upgrade do KDE Neon, e ele também passou a usar um pouco mais de Memória RAM ─ mas ainda ficou abaixo do Mint 20 com KDE.

Isso também me parece coisa normal.

O que me espantou é que, de Julho para Agosto, o uso de RAM deu um pulo enorme, no openSUSE Tumbleweed, Fedora, Mageia, Debian testing, e por fim também no Void ─ enquanto as outras distros mantêm quase os mesmos valores.

Alguém entende o que pode estar acontecendo?

Algum palpite, que seja?

[Natanael.755]

Pode ser coincidência mas todas que tiveram esse salto usam GNOME Shell by default

[anon58028541]

Adora o gnomao hein @Natanael.755, não perde uma.

@frc_kde

Todas, sempre com KDE.

Acho que não se atentou ao texto.

@frc_kde no fedora você está utilizando a loja de aplicativos do KDE? Se sim dê uma olhada no processo packagekitd ele consome bastante.

[Natanael.755]

@anon58028541

Adora o gnomao hein @Natanael.755, não perde uma.

Mas tá errado? Kkkkkk

@anon58028541

Acho que não se atentou ao texto.

Verdade, mas tem coisa errada, pelo menos com o Debian, o KDE mesmo com o PIM-Baloo-Akonadi fica abaixo de 700 MB

[anon58028541]

@Natanael.755

Mas tá errado? Kkkkkk

Não está, porém o consumo do GNOME padrão tem uma causa packagekitd+gnome-sofware, pode ser utilizado sem caso queira, dá pra deixar o consumo em 600mb só desabilitando.

[Natanael.755]

Não, é bem verdade, nos meus testes mesmo sem a gnome-software e o pakagekit o consumo é bem fora da curva, o principal problema (que eu notei pelo menos) é o evolution-data-server, o problema é que removendo ele metade do ecossistema útil do GNOME para de funcionar, só faltou testar o 3.38 mas creio que não mudou

[Natanael.755]

No debian verifique os processos que estão engolindo sua RAM, porque aparentemente não é o KDE

[Capezotte]

Meio difícil investigar as causas desse aumento sabendo só o nome sem outras informações do seu setup. Eu olharia ferramentas específicas de cada distro com mais suspeita, mas uma investigada com htop (com root se necessário) ainda parece ser a melhor opção.

[anon58028541]

Apesar do tópico se tratar do kde então não quero entrar em offtopic, se eu fosse medir o consumo do GNOME como o ksysguard mede o do kde eu teria isso, sem o packagekitd e a gnome-software, aí está o monitor do sistema e o ksysguard lado a lado, só para mostrar para os garotos que se assustam com o consumo do GNOME.

[frc_kde]

@Natanael.755

Pode ser coincidência mas todas que tiveram esse salto usam GNOME Shell by default

Não tinha pensado nisso.

De fato, Debian e Fedora privilegiam o Gnome ─ e o Fedora até “esconde” um pouco os outros “spin’s”…

Mas o Mageia e o openSUSE, não. ─ KDE e Gnome são apresentados em igualdade de condições ─ e ambas têm longa com o KDE.

No caso do Void, nem existe versão Gnome (nem KDE, aliás).

void-live-x86_64-musl-20191109-cinnamon.iso
void-live-x86_64-musl-20191109-enlightenment.iso
void-live-x86_64-musl-20191109-lxde.iso
void-live-x86_64-musl-20191109-lxqt.iso
void-live-x86_64-musl-20191109-mate.iso
void-live-x86_64-musl-20191109-xfce.iso
void-live-x86_64-musl-20191109.iso

Instalei o Void sem DE ─ e adicionei o KDE em seguida.

[ruanelivelton18]

O mais certo a se dizer e que estamos em 2020…
A Otimização de caches das DE estão melhores que antes(exceto no debian… ate pq qualquer DE nele fica instavel com surtos de consumo), vc nem precisa se preocupar desde que funcione com fluidez kkkkkkkk
No futuro talvez fique tão bem otimizado quanto no Mac e Windows

[frc_kde]

@anon58028541

@frc_kde no fedora você está utilizando a loja de aplicativos do KDE? Se sim dê uma olhada no processo packagekitd ele consome bastante.

Na verdade, eu desabilito ─ ou até mesmo removo ─ Discover, PackageKit etc., para não haver nem mesmo verificação ou notificação de atualizações.

Sempre verifico manualmente, por comandos.

Só no Debian, Mint, KDE Neon, PCLinuxOS, rodo manualmente o Synaptic, para “aplicar” as atualizações. ─ No Fedora, openSUSE, Void, Mageia, faço tudo por comandos.

Também não uso Flatpak, nem Snapd, nem AppImage…

[anon58028541]

Aí fica mais complicado, porém o consumo que você colocou pelo menos no fedora tem sido a média aqui com packagekit + ou - 800MB ao iniciar, teria que verificar quais outros processos estariam consumindo.
Seria interessante você descer ao init 3 e verificar o consumo, aqui sem interface dá em média + ou - 200MB, se ficar muito além disso é algum processo da interface gráfica.

[frc_kde]

@anon58028541

aí está o monitor do sistema e o ksysguard lado a lado

KSysguard e Gnome System Monitor usam critérios totalmente diferentes.

Eu considero só o Conky, ─ sempre ─ pois assim não preciso abrir nada, nem mesmo um terminal… pois isto já causaria uma alteração no uso inicial de RAM.

Mas agora que você chamou atenção para “a(s) ferramenta(s)”… Acho que você deu uma boa ideia: ─ Verificar se há alguma falha no Conky, ou na ferramenta de baixo nível onde ele vai pegar a informação sobre o uso da RAM.

[anon58028541]

É uma coisa interessante a se observar pois de repente o método mudou nas distros mais atualizadas que você citou, até entre o screenfetch, neofetch e inxi você observa essas diferenças na leitura da memória.

[frc_kde]

@ruanelivelton18

No futuro talvez fique tão bem otimizado quanto no (…) Windows

T’esconjuro!!!

@ruanelivelton18

(exceto no debian… ate pq qualquer DE nele fica instavel com surtos de consumo)

Uso o Debian testing desde Outubro 2016, e nunca vi variações bruscas no uso inicial de RAM.

Aliás, variações como essas de agora, nunca vi em nenhuma distro.

[frc_kde]

Sim, vou fazer uns testes comparando top, htop, free, inxi…

O que você disse sobre KSysguard X Gnome System Monitor me fez lembrar um bug que apareceu no Conky, em meados de 2019. ─ De repente, enchia o gráfico e dava um número “negativo”:

Que eu me lembre, PCLinuxOS foi a única distro cuja equipe se movimentou para corrigir o problema, na época.

Não lembro exatamente em quais distros o problema apareceu no ano passado. ─ Hoje eu renomeio as capturas de tela com a terminação “Minus”, o que facilita pesquisar rapidamente ─ mas no ano passado eu não tinha padronizado isso.

E pelo que acabo de verificar, isso parou de acontecer ─ desde quando essas distros começaram a apresentar uso de quase 1 GIB RAM no início da sessão.

Desde o dia 2 de Agosto, esse gráfico cheio + RAM negativa só continua aparecendo no Arch Linux.

[frc_kde]

Confirmado ─ é bug do Conky, mesmo.

1. Negative RAM Usage #877
2. Negative / too low memory reading #886

E ao consertarem, inverteram o bug:

3. High CPU usage (…) #876

Para confirmar:

a) Reiniciei o Debian
b) Printei o Conky indicando 952 MiB
c) Alternei para o Console tty2:
c.1) # free -m ----> 529 used
c.2) # inxi -m ----> 611 used
c.3) # top -E m —> 524 used
c.4) # free -m -----> 523 used
c.5) # inxi -m ------> 603 used
d) Alternei de volta para o KDE, no tty7
d.1) Conky indica 945 MiB

[frc_kde]

Só para não deixar ponta solta…

@frc_kde

é bug do Conky

Não é realmente um “bug”, mas uma “correção de metodologia” do Conky, que por enquanto só apareceu nas distros com versões mais recentes do Conky:

Conky altera o cálculo do uso de Memória RAM