 |
| Comando free assusta testadores do Debian 12 Bookworm RC, em Abril 2023 |
• Usuários que tentaram o comando free para medir o uso inicial de Memória RAM do Debian 12 Bookworm RC levaram um susto: — quase o dobro do que o free costumava indicar no Debian 11.
O Debian não está mudando tanto assim. — O que muda são as ferramentas free / top, do pacote procps 4.0 — mas isso já vinha ocorrendo com outras ferramentas, pelo menos, desde 2020.
Vale a pena registrar essas mudanças — bem como a dispersão de usuários e desenvolvedores, cada um com sua ferramenta predileta (bolhas), graças à liberdade do mundo GNU / Linux — e os inúmeros “erros de comparação” que se cometem a cada dia, pelo uso de ferramentas diferentes (ou em versões diferentes) entre duas distros ou dois ambientes de trabalho (DE).
Índice
- Agosto 2020
- Março 2021
- Maio 2021
- Outubro 2021
- Abril 2023
- Ferramentas e medições
- No Conky
- Em TXT
- Referências
- “Monitor do Sistema” e Terminais
Agosto 2020
 |
| Aumento aparente de uso de RAM, com o Conky 1.11.6 |
Desde Agosto 2020, o Conky 1.11.6 passou a mostrar valores bem mais altos de uso de Memória RAM — no openSUSE Tumbleweed, Debian testing, Fedora, Mageia 8 (beta), Void Linux. — Foi o “primeiro susto”, digamos assim.
 |
| Proposta do “novo cálculo”, em 2014 |
Não era bug. — Era uma “correção” do cálculo da “Memória RAM usada” — que foi proposta ou subscrita por Linus Torvalds desde Janeiro 2014 (Kernel 3.14), quando se introduziu em /proc/meminfo um campo “MemAvailable”, exatamente para tornar esse cálculo mais acurado:
Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo.
However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.
It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.
 |
| Aplicação do “novo cálculo” ao Conky, em 2019 |
A aplicação dessa mudança no Conky só foi pedida em Junho 2019; — efetuada em Outubro 2019 (acima); — e ainda demorou 10 meses, até o Conky 1.11.6 chegar às principais distros rolling-release (e ao Fedora).
Foi o marco inicial de um movimento (bem atrasado) para um cálculo tecnicamente mais correto — que aos poucos chega a outras ferramentas — e tempos depois, aos usuários de cada distro.
Naquele momento, a introdução desse “novo cálculo” quebrou a paridade entre os números do Conky e do htop — no que poderíamos chamar de “cálculo antigo”.
Março 2021
 |
| Situação após nova reviravolta do Conky |
Em Março 2021, o Conky 1.12.1 fez uma reviravolta, — passando a exibir valores muito baixos.
Foi uma resposta à grita de usuários, que pediam paridade do Conky com o free / top — no que poderíamos chamar de “cálculo muito antigo” (se os experts permitirem). — No fundo, o desejo de garantir o troféu de “mais leve” para suas distros e configurações.
Com o tempo, no entanto, foi-se delineando um movimento de outras ferramentas rumo ao “novo cálculo” proposto desde 2014 — com recuos aqui e ali:
Maio 2021
 |
| Versões do Conky e demais ferramentas em 2 Maio 2021 |
Em Maio 2021, tabulei esse registro (acima) do suposto uso inicial de Memória RAM das distros que eu tinha naquele momento (“cálculo novo”, “cálculo antigo”, e “cálculo muito antigo”), para formar um quadro do estado das ferramentas.
Era o auge das idas-e-vindas do Conky — que chegou a ter pelo menos 4 versões na praça, brigando umas com as outras:
Conky 1.10.8 = htop (htop) Neon, Mint 20, MX Linux 19
Conky 1.11.6 > htop (new calc) Arch, Debian testing, Mageia 8
Conky 1.12.1 < htop (free, top) Fedora 33, PCLinuxOS, Void
Conky 1.12.2 > htop (new calc) openSUSE Tumbleweed- O inxi já tinha adotado o “novo cálculo”, pelo menos desde sua versão 3.1.00 (2020-11-11) — mas ainda sobreviviam versões anteriores no KDE Neon, no Linux Mint 20 (ambos LTS “Focal Foss”), e no MX Linux 19 (Debian stable 10 ”Buster”).
- O screenfetch também já tinha adotado o “novo cálculo”, mas não consegui descobrir exatamente quando. — A versão 3.8.0 (MX Linux 19) ainda mostrava o mesmo valor indicado por free / top — mas o Changelog das versões seguintes (3.9.0, 3.9.1) simplesmente não registrou essa mudança. — As datas (2019-10-06 e 2019-11-12) talvez sejam bem anteriores à chegada dessas versões aos usuários das distros.
- O neofetch permanecia no “cálculo antigo” — exceto no Slackware, apesar de indicar a mesma versão (7.1.0) de outras distros. — Imagino que fosse uma personalização feita pela equipe do Slackware.
Outubro 2021
 |
| Conky, htop, inxi e Screenfetch com o “cálculo novo”, Outubro 2021 |
Até Outubro 2021, outra mudança:
- O htop (3.1.0) adotou o “novo cálculo” em 2021-09-21 — e cheguei a ver isso no Arch, no Manjaro, no openSUSE Tumbleweed, no Void Linux — mas parece ter sido um fenômeno de curta duração.
Abril 2023
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Em Abril 2023 (acima), continuamos longe de uma padronização das ferramentas para o cálculo da Memória RAM usada — e ainda mais longe de um esclarecimento geral dos usuários (e até dos desenvolvedores!) sobre o assunto:
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Acima - O uso de Memória RAM por diferentes ferramentas — como percentuais dos números do “cálculo novo” — ajuda a tornar o quadro mais nítido.
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Acima - A partir da versão 3.1.1 (2021-10-14), o htop parece ter cedido à grita dos usuários e retrocedido para o “cálculo muito antigo” — mas em algumas distros (KDE Neon, Mageia 8, MX Linux 21) ainda sobrevive o htop 3.0.5, com o “cálculo antigo”.
 |
| openSUSE alterou o free / top 3.3.17, sem esperar a versão 4.0 |
O interesse despertado pela aproximação do Debian 12 Bookworm causou mais alguns sustos — pois o pré-lançamento já veio com o procps 4.0 — e muita gente achou que essa próxima versão de Debian viesse dobrar o uso de Memória RAM.
- Na verdade, o procps 4.0 adotou o “cálculo novo” em 2022-06-24 — e essa mudança já tinha chegado ao Debian testing por volta do Natal:
procps (2:4.0.2-1) unstable; urgency=medium
* free: Used memory is Total - Available
This means versions of free after 4.0.0 will show different Used
values for older frees and some other system utilities.
-- Craig Small [csmall@debian.org] Mon, 05 Dec 2022 21:34:57 +1100
Portanto — depois que o htop adotou o “cálculo muito antigo” — o free / top já começava a se movimentar para o “cálculo novo”.
Enfim, desde Junho 2022 (imagem acima), o openSUSE Tumbleweed já tinha alterado o htop 3.3.17 para o “cálculo novo” — sem esperar a versão 4.0.
Ferramentas e medições
 |
| Calculando o uso de RAM para monitorar as ferramentas |
Testei o “cálculo antigo” a partir da descrição textual de Linus Torvalds (excluindo as “marcas d'água”) — e o resultado se mostrou sempre muito próximo do indicado pelas versões do Conky e do htop anteriores a Agosto 2020:
/proc/meminfo --> (Old calc):
Mem used = MemTotal - [MemFree + Active(file) + Inactive(file) + SReclaimable]Quanto ao que chamo (talvez injustamente!) de “cálculo muito antigo” — usado pelo free / top nas versões anteriores ao procps 4.0 (e agora pelo htop) — confesso que não cheguei a verificar, pois nunca usei, portanto não afetava meu dia-a-dia.
O “cálculo novo” é bem mais simples e claro — e principalmente, mais correto:
/proc/meminfo --> (New calc):
Mem used = MemTotal - MemAvailable No Conky
 |
| Calculando o uso de RAM para monitorar as ferramentas |
Optei por exibir esse “cálculo novo” no meu Conky2 (que se atualiza a cada 10 segundos) encabeçando os números das demais ferramentas — para monitorá-las:
conky.config = {
(...)
update_interval = 10,
(...)
}
conky.text = [[
Mem: ${alignr 100}up ${uptime}
Total - Available ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem) ${alignr 100}${mem}
free ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top ${alignr 100}${exec top -E m -b -n 1 | grep buff | cut -c 41-50} MiB
neofetch ${alignr 100}${exec neofetch --stdout | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
htop ${alignr 100}${exec export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
screenfetch ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}
(...)
${alignr}${cat done.txt} ${execi 600 echo $XDG_SESSION_TYPE}
(...)
]]
Na linha “Total - Available” (acima), o Conky executa um script “MemInfo.sh” — que efetua o “cálculo novo” — e salva o resultado em um arquivo “MemInfo.txt:
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt
O ciclo de 10 segundos evita oscilações súbitas nesses indicadores, — de modo que o gnome-screenshot ou o KDE Spectacle não capturem um valor já afetado por seu próprio acionamento (+ 25 ~ 40 MiB durante uns 25 segundos).
Em TXT
Também criei um script “RAM.sh” — que cria um arquivo “RAM_00-Distro.txt” com essas informações, 10 minutos após o boot. — Quando quero guardar um registro, basta iniciar / reiniciar o computador e ir tomar um café:
echo "------------------------------------------------------------------" > RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo "-------------------- uptime ----------------------------------" >> RAM_02-Arch.txt
uptime -p >> RAM_02-Arch.txt
uptime -s >> RAM_02-Arch.txt
echo "----------------- MemTotal - MemAvailable --------------------" >> RAM_02-Arch.txt
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo);\
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo);\
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))";\
MEM_USED_BYTES_X_1000="$(($MEM_USED_KILO*1000))";\
echo "$(($MEM_USED_KILO/1024))" MiB >> RAM_02-Arch.txt
echo "$(($MEM_USED_BYTES_X_1000/1048576))" MiB, exactly >> RAM_02-Arch.txt
echo "-------------------- Conky ----------------------------------" >> RAM_02-Arch.txt
conky -c ~/.config/conky/conky3.conf
cat Conky.txt >> RAM_02-Arch.txt
echo "--------------------- free -----------------------------------" >> RAM_02-Arch.txt
free -m >> RAM_02-Arch.txt
echo "--------------------- top -----------------------------------" >> RAM_02-Arch.txt
top -E m -b -n 1 | grep buff >> RAM_02-Arch.txt
echo "--------------------- neofetch -----------------------------------" >> RAM_02-Arch.txt
neofetch --stdout | grep "Memory" >> RAM_02-Arch.txt
echo "--------------------- htop -----------------------------------" >> RAM_02-Arch.txt
export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep "/15" >> RAM_02-Arch.txt
# export TERM=xterm; echo q | htop >> RAM_02-Arch.txt
echo "--------------------- inxi -----------------------------------" >> RAM_02-Arch.txt
inxi -m >> RAM_02-Arch.txt
echo "------------------- screenfetch ----------------------------------" >> RAM_02-Arch.txt
screenfetch -n -N -E | grep "RAM" >> RAM_02-Arch.txt
echo "------------------------------------------------------------------" >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo "------------------------------------------------------------------" >> RAM_02-Arch.txt
echo '•' > done.txt
Acima - Para salvar em arquivo a variável mem do Conky, o script executa o Conky3 — apenas 1 vez (total_run_times = 1). — Encontrei essa dica de 2011 no Linux Questions e fiz alguns testes, adaptando a sintaxe para as versões atuais (out_to_x = false):
conky.config = {
out_to_x = false,
out_to_console = false,
out_to_stderr = false,
own_window = no,
extra_newline = false,
uppercase = no,
overwrite_file = 'Conky.txt',
no_buffers = yes,
double_buffer = false,
total_run_times = 1,
}
conky.text = [[
Conky (Mem) ${mem}
]]
No caso do htop, quando não tenho o aha ou o html2text, não consigo usar o grep para salvar uma linha enxuta — então, o jeito é salvar toda a maçaroca de caracteres esquisitos — e depois procurar “/15.5G” pelo CTRL+F do Kate ou do KWrite, para encontrar o valor da Memória RAM usada:
 |
| Procurando o uso de Memória RAM do htop no KWrite (CTRL+F) = “539M” |
No final, o bash script cria um arquivo “done.txt” com um bullet “•”, que o Conky2 exibe à esquerda do indicador X11 / Wayland — e depois disso, já posso começar a usar o computador.
 |
| Calculando o uso de RAM para monitorar as ferramentas |
O bullet “•” permanece à esquerda do indicador X11 / Wayland por 3 minutos (até 13 minutos uptime) — quando é apagado por outro script: — “VERSIONS.sh”.
Este segundo script apenas adiciona ao arquivo “RAM_00-Distro.txt” as versões da distro, do Kernel, do init, do KDE e das ferramentas. — Em seguida, move o arquivo para uma pasta provisória — e por fim, torna a esvaziar o arquivo “done.txt”, eliminando assim o bullet “•”:
echo '------- Versions -----------' >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
uname -n >> RAM_02-Arch.txt
lsb_release -ds >> RAM_02-Arch.txt
uname -sr >> RAM_02-Arch.txt
strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }'\
>> RAM_02-Arch.txt
systemctl --version | grep systemd | cut -c 9-11 >> RAM_02-Arch.txt
#rc-service -V >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
plasmashell --version >> RAM_02-Arch.txt
neofetch --de_version on --stdout | grep "DE:" >> RAM_02-Arch.txt
kf5-config --version | grep 'Qt\|KDE' >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
konsole -v >> RAM_02-Arch.txt
kate -v >> RAM_02-Arch.txt
dolphin -v >> RAM_02-Arch.txt
gwenview -v >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
gimp --version >> RAM_02-Arch.txt
google-chrome-stable --version >> RAM_02-Arch.txt
libreoffice --version >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
conky -v | grep compiled >> RAM_02-Arch.txt
free -V >> RAM_02-Arch.txt
top -v | grep procps >> RAM_02-Arch.txt
neofetch --version >> RAM_02-Arch.txt
htop --version >> RAM_02-Arch.txt
inxi -V | grep inxi >> RAM_02-Arch.txt
screenfetch -V | grep Version >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
mv RAM_02-Arch.txt /run/media/flavio/Warehouse/Byteria/Conky/Conky-RAM-New/
echo ' ' > done.txt
Uso um comando padronizado para detectar o software init — e comandos diferentes para obter a versão de cada init: — apenas no Void, ainda não descobrir como exibir a versão do runit:
[PATH]/Conky/backup/2022-07-18
$ grep -R -A 2 sysname
openSUSE ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Arch ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Debian ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Fedora ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
KDE Neon ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
PCLinuxOS Kernel ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Mageia ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Slackware ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Void ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')}
Manjaro ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Redcore ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 rc-service -V | cut -c 21-26}
MX Linux ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
É comum eu atualizar algumas distros em 10 minutos, e reiniciar o computador antes da eliminação do bullet. — Para evitar que ele apareça em uma próxima sessão, ele é eliminado logo após um novo boot:
$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
Naturalmente, só 2 ou 3 vezes por ano eu me preocupo em esperar 10 minutos após o boot, com o computador “em repouso”, em 12 distros seguidas, para cumprir todos esses passos. — Isso exige pelo menos 3 horas — e não é frequente eu ver motivo para tanto trabalho.
Nos outros casos, os arquivos abandonados são sobrescritos, e não se acumulam.
Referências:
- htop output to human readable file
- htop and crontab
- Is it correct to set the $TERM variable manually?
- Kilobyte
“Monitor do Sistema” e Terminais
 |
| KSysguard |
O nome genérico “Monitor do Sistema” tem induzido a muitos enganos e falsas comparações — pelo menos desde 2016, quando tive o KSysguard e o Gnome-System-Monitor lado a lado, em uma instalação do Debian com vários ambientes.
Desde aquela época, verifiquei que o KSysguard indicava uso de Memória bem inferior ao indicado pelo Conky — que na época se alinhava ao htop — ambos ainda com o “cálculo antigo”.
Me parece que o KSysguard busca utilizar o mesmo cálculo do free (o “muito antigo”) — porém “descontando” seu próprio uso de Memória. — Acontece que o free não “desconta” o peso do KSysguard, e por isso tende a indicar um número maior do que ele.
Aliás, o “peso” de qualquer aplicação GUI sempre interfere naquilo que pretende medir — uso de Memória RAM, uso de CPU etc. — por isso desde 2016 optei por usar o Conky, que tem baixíssimo uso de recursos.
- Em tese, o Conky deveria ter igual uso de recursos em todas as distros — mas na prática, em algumas delas ainda não incluí aha, html2text, ou alguma das outras ferramentas — por isso, o Conky apresenta alguma diferença de consumo entre elas.
Mesmo a abertura de um emulador de Terminal já altera significativamente o uso de Memória RAM. — Além disso, diferentes DEs usam emuladores de Terminal mais “leves” ou mais “pesados” — o que também torna enganosas comparações entre diferentes distros e DEs, mesmo quando pensamos estar usando “apenas uma ferramenta CLI”, como free, htop, neofetch etc.
- Para realmente usar “só a ferramenta CLI”, deixe o DE em repouso — e use a ferramenta CLI em um “terminal tty” — tty2, por exemplo.
Acima - A simples abertura do KSysguard elevou o uso de Memória RAM de 865 MiB para 1046 MiB (+181 MiB), segundo o cálculo “novo” — ou de 428 MiB para 531 MiB (+103 MiB), segundo o free.
O valor de 0,48 GiB indicado pelo KSysguard equivale a 492 MiB — menos que os 531 MiB indicados pelo free (-39 MiB), mas dentro da faixa de oscilação aceitável.
 |
| Plasma System Monitor |
Ao fechar o KSysguard, o uso de Memória RAM caiu para 962 MiB, segundo o “cálculo novo” — cerca de 100 MiB acima dos 865 MiB iniciais.
Portanto, quando abri o Plasma System Monitor, já parti de um patamar um pouco mais elevado.
Acima - O novo Plasma System Monitor indicava uso de 1,1 GiB de Memória RAM — valor exato dos 1128 MiB indicados pelo “cálculo novo” (1,102 GiB).
 |
| Gnome System Monitor |
Ao fechar o Plasma System Monitor, o uso de Memória RAM também não volta ao que era logo no início da sessão. — Mesmo assim, o Gnome System Monitor parece “pesar” menos do que as 2 ferramentas do KDE.
Acima - O Gnome System Monitor indica uso de 1,0 GiB — valor muito próximo aos 1000 MiB indicados pelo “cálculo novo” (0,98 GiB).
Um minuto após fechar o Gnome System Monitor, o uso de Memória RAM baixou para 974 MiB, segundo o “cálculo novo” — cerca de 110 MiB acima dos 865 MiB logo após a inicialização. — Este foi o “saldo” de abrir e fechar as 3 ferramentas GUI, uma após outra.
_______________________
• Publicado em 20 Outubro 2020 e atualizado até 4 Outubro 2021 (histórico).
• Reescrito em Abril 2023.
— … ≠ • ≠ … —
Ferramentas &tc.
- Conky altera o cálculo da Memória RAM usada
- Transição para hardware UEFI-GPT
- Speedtest de banda larga de “200 megas”
- Conky - monitor do sistema
- Consertando pequenos problemas do Gimp 2.10
- Pré-visualização de arquivos no Dolphin
- Limpeza do Cooler da CPU
- Escolhendo Grub entre vários Linux
- Teste de memória com o Memtest86
- De volta ao Gnome-screenshot
- Konqueror como gerenciador de arquivos
- Substituição da fonte de energia do computador
- Facebook sobrecarrega visitar e compartilhar “Páginas”
- Corrigindo pontos de montagem no Linux Mint 18 KDE
- Política de Kernel do Linux Mint vs. Kubuntu, KDE Neon & Debian
- KDE “light” eliminando o PIM
- Conky - configuração em andamento
- Google Earth sem placa 3D no Xenial
- Linux ficou sem Administrador. Que fazer?
- Particionamento de disco para vários Linux
- Padronizando PrintScreen no Linux (com Shutter) e no Windows
- Montagem automática de partições adicionais (Cinnamon e Gnome)
- Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
- Repositórios de software Linux e gerenciador de pacotes Synaptic
- Monitorando a temperatura da CPU no Linux e Windows
- Conversão em massa de TIFF em JPEG
- Meu Wi-Fi parou de funcionar. E agora?
- Cópia de artigos da mídia para citação
- Lua, Júpiter e Vênus em ISO 1600
- Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
- Quantas pessoas cabem na Avenida Paulista?
- A batalha da Comunicação no Facebook
- O Aeroporto de Cláudio documentado no Google Earth
- O apagão do Facebook não será noticiado
- Blog, microblog e redes sociais
- Adeus ao Orkut
- Bookmark para encontrar um post “favorito” no Facebook
- Sincronização do Google Chrome
- Fotos em alta resolução no Facebook
- Sincronizando pastas de documentos entre Linux e Windows
- Dual-boot, Linux, Windows e Grub-customizer
- Listas, Grupos, Fóruns, Comunidades
- Mandar fotos por email para Grupos do Facebook
- Limitando emails de notificação do Facebook
- Conexão 3G pelo “chaveirinho” da TIM
