Debian consommation mémoire

Debian consommation mémoire

Notes

Pour identifier ce qui consomme la RAM sur Debian, commencez par :

1
2

free -h
ps aux --sort=-%mem | head -n 15

La ligne available de free -h est le meilleur indicateur : une partie de la RAM utilisée par le cache est récupérable et n’est pas un problème en soi.

Voir les plus gros consommateurs

1

ps aux --sort=-%mem | head -n 15

Ou, plus confortablement :

1
2

sudo apt install htop
htop

Dans htop, triez avec F6 puis choisissez RES (mémoire réellement utilisée par le processus)

Interpréter free -h

1
2
3

              total   used   free   shared  buff/cache  available
Mem:           7.6Gi  3.1Gi  1.2Gi   250Mi       3.3Gi      4.1Gi
Swap:          2.0Gi    0B  2.0Gi
  • used : mémoire utilisée par les processus et le noyau.
  • buff/cache : cache disque, normalement libérable automatiquement.
  • available : mémoire réellement disponible pour de nouveaux programmes ; c’est la valeur à surveiller.
  • Swap élevé ou en croissance continue : la machine manque probablement de RAM

Diagnostiquer une fuite

Si la consommation monte progressivement :

1
2
3
4

watch -n 5 free -h
vmstat 2
dmesg -T | grep -i "out of memory"
journalctl -k -b | grep -i "out of memory"

Des colonnes si/so non nulles en continu dans vmstat indiquent un swapping permanent ; des messages Out of memory: Killed process montrent que le noyau a dû tuer un processus faute de mémoire

Causes fréquentes

  • Navigateur avec beaucoup d’onglets ou extensions.
  • Environnement de bureau lourd : GNOME et KDE Plasma consomment davantage que XFCE, LXQt ou LXDE
  • Services inutiles activés au démarrage.
  • Base de données, conteneurs Docker/Podman, JVM, Node.js ou serveur web mal dimensionnés.
  • Fuite mémoire dans une application : son usage RAM augmente sans jamais redescendre.

Libérer de la mémoire sans redémarrer

1
2

systemctl --user list-units --state=running
systemctl list-units --state=running

Arrêtez uniquement un service que vous reconnaissez, par exemple :

1
2

sudo systemctl stop nom_du_service
sudo systemctl disable nom_du_service

Pour un processus précis :

1

kill <PID>

Évitez de vider manuellement les caches avec echo 3 > /proc/sys/vm/drop_caches : cela ne règle généralement pas la cause et peut dégrader temporairement les performances.

Sortie de free -h

1
2
3

total        used        free      shared  buff/cache   available
Mem:            15Gi        10Gi       830Mi        20Mi       4.1Gi       4.6Gi
Swap:          8.0Gi       2.1Gi       5.9Gi

Votre système n’est pas encore en saturation immédiate : il reste 4,6 GiB disponibles, mais 2,1 GiB de swap sont utilisés, ce qui indique que la pression mémoire a déjà été importante

Lecture de vos chiffres

Valeur Interprétation
used: 10Gi Les processus et le noyau utilisent environ 10 GiB sur 15 GiB.
buff/cache: 4.1Gi Cache disque ; normal et récupérable automatiquement.
available: 4.6Gi Il reste de la marge pour lancer des programmes.
Swap used: 2.1Gi Le noyau a déjà déplacé de la mémoire vers le disque : signe d’une pression mémoire passée ou actuelle.

Le point important n’est donc pas used, mais le swap utilisé. S’il reste stable, ce n’est pas forcément grave ; s’il augmente, ou si le système devient lent, un processus consomme trop de RAM.

Prochaine étape

Lancez ceci et envoyez-moi le résultat :

1

ps aux --sort=-rss | head -n 20

Cette commande affichera les 20 processus qui occupent le plus de mémoire résidente.

Vous pouvez aussi vérifier si le swap continue d’augmenter :

1

watch -n 5 free -h

À surveiller

  • Si available descend sous environ 1 GiB, ou si le swap dépasse 3–4 GiB, il faut agir.
  • Si vmstat 2 montre des valeurs si et so régulièrement non nulles, le système swappe activement
  • Les suspects classiques sont le navigateur, une JVM, Docker/Podman, une base de données, ou un service qui fuit progressivement.

Collez la sortie de ps aux --sort=-rss | head -n 20 et je vous dirai précisément quel processus est responsable.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        1457  7.0 22.2 5178064 3603184 ?     Sl   Oct03 992:25 /usr/bin/kvm -id 103 -name pvm-alpine02,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/103.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect-ms=5000 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/103.pid -daemonize -smbios type=1,uuid=1d18ee02-7abe-4070-93ec-db5e03ed7cf0 -smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/103.vnc,password=on -cpu qemu64,+aes,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+pni,+popcnt,+sse4.1,+sse4.2,+ssse3 -m 4096 -object iothread,id=iothread-virtioscsi0 -object {"id":"throttle-drive-scsi0","limits":{},"qom-type":"throttle-group"} -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.3,chassis_nr=3,bus=pci.0,addr=0x5 -device vmgenid,guid=5d6085ee-86b4-4566-8747-a8791728bfb5 -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device VGA,id=vga,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on -iscsi initiator-name=iqn.1993-08.org.debian:01:2d1a4db119bf -device virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0 -blockdev {"detect-zeroes":"on","discard":"ignore","driver":"throttle","file":{"cache":{"direct":true,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"raw","file":{"aio":"io_uring","cache":{"direct":true,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"host_device","filename":"/dev/pve/vm-103-disk-0","node-name":"ef67a8d7bc57df99fb5dddbf8ce2790","read-only":false},"node-name":"ff67a8d7bc57df99fb5dddbf8ce2790","read-only":false},"node-name":"drive-scsi0","read-only":false,"throttle-group":"throttle-drive-scsi0"} -device scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,device_id=drive-scsi0,bootindex=100,write-cache=on -netdev type=tap,id=net0,ifname=tap103i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=BC:24:11:89:F9:0A,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=256,bootindex=101,host_mtu=1500 -machine hpet=off,type=pc+pve0
root        1390  6.4 20.3 4950528 3295620 ?     Sl   Oct03 897:57 /usr/bin/kvm -id 101 -name pvm-alpine03,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect-ms=5000 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/101.pid -daemonize -smbios type=1,uuid=260f0c1d-e2c2-4464-9705-2ae0c124844d -smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/101.vnc,password=on -cpu host,+kvm_pv_eoi,+kvm_pv_unhalt -m 4096 -object {"id":"throttle-drive-virtio0","limits":{},"qom-type":"throttle-group"} -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device vmgenid,guid=eb767cf9-5ca1-4007-b78c-1e89815c837f -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device VGA,id=vga,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on -iscsi initiator-name=iqn.1993-08.org.debian:01:2d1a4db119bf -blockdev {"detect-zeroes":"on","discard":"ignore","driver":"throttle","file":{"cache":{"direct":true,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"raw","file":{"aio":"io_uring","cache":{"direct":true,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"host_device","filename":"/dev/pve/vm-101-disk-0","node-name":"e66df16af6b9d48f28618c1010a143e","read-only":false},"node-name":"f66df16af6b9d48f28618c1010a143e","read-only":false},"node-name":"drive-virtio0","read-only":false,"throttle-group":"throttle-drive-virtio0"} -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100,write-cache=on -netdev type=tap,id=net0,ifname=tap101i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=BC:24:11:60:35:7B,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=256,host_mtu=1500 -machine type=pc+pve0
root     2505461  6.2 18.8 3845448 3052376 ?     Sl   07:08   1:06 /usr/bin/kvm -id 105 -name jekyll-chirpy,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/105.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chardev socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect-ms=5000 -mon chardev=qmp-event,mode=control -pidfile /var/run/qemu-server/105.pid -daemonize -smbios type=1,uuid=5bd14cda-214b-4d91-995b-94d6203eca96 -object {"id":"throttle-drive-efidisk0","limits":{},"qom-type":"throttle-group"} -blockdev {"driver":"raw","file":{"driver":"file","filename":"/usr/share/pve-edk2-firmware//OVMF_CODE_4M.secboot.fd"},"node-name":"pflash0","read-only":true} -blockdev {"detect-zeroes":"on","discard":"ignore","driver":"throttle","file":{"cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"raw","file":{"aio":"io_uring","cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"host_device","filename":"/dev/pve/vm-105-disk-0","node-name":"e3916c8b3c4107485f86c6f169c83c3","read-only":false},"node-name":"f3916c8b3c4107485f86c6f169c83c3","read-only":false,"size":540672},"node-name":"drive-efidisk0","read-only":false,"throttle-group":"throttle-drive-efidisk0"} -smp 2,sockets=1,cores=2,maxcpus=2 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vnc unix:/var/run/qemu-server/105.vnc,password=on -cpu host,+kvm_pv_eoi,+kvm_pv_unhalt -m 3072 -object iothread,id=iothread-virtioscsi0 -object {"id":"throttle-drive-scsi0","limits":{},"qom-type":"throttle-group"} -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -readconfig /usr/share/qemu-server/pve-q35-4.0.cfg -device vmgenid,guid=923ed8f6-b6b3-4553-adb1-982ddbfff257 -device usb-tablet,id=tablet,bus=ehci.0,port=1 -device VGA,id=vga,bus=pcie.0,addr=0x1 -chardev socket,path=/var/run/qemu-server/105.qga,server=on,wait=off,id=qga0 -device virtio-serial,id=qga0,bus=pci.0,addr=0x8 -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on -iscsi initiator-name=iqn.1993-08.org.debian:01:2d1a4db119bf -device ide-cd,bus=ide.1,unit=0,id=ide2,bootindex=101 -device virtio-scsi-pci,id=virtioscsi0,bus=pci.3,addr=0x1,iothread=iothread-virtioscsi0 -blockdev {"detect-zeroes":"unmap","discard":"unmap","driver":"throttle","file":{"cache":{"direct":false,"no-flush":false},"detect-zeroes":"unmap","discard":"unmap","driver":"raw","file":{"aio":"io_uring","cache":{"direct":false,"no-flush":false},"detect-zeroes":"unmap","discard":"unmap","driver":"host_device","filename":"/dev/pve/vm-105-disk-1","node-name":"eb182240be5a7bfef6aa647901b6cac","read-only":false},"node-name":"fb182240be5a7bfef6aa647901b6cac","read-only":false},"node-name":"drive-scsi0","read-only":false,"throttle-group":"throttle-drive-scsi0"} -device scsi-hd,bus=virtioscsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,device_id=drive-scsi0,bootindex=100,write-cache=on -netdev type=tap,id=net0,ifname=tap105i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=BC:24:11:C2:41:20,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=256,host_mtu=1500 -machine pflash0=pflash0,pflash1=drive-efidisk0,hpet=off,type=q35+pve0
www-data  633340  0.0  0.3 250088 59328 ?        S    Oct06   0:12 pveproxy worker
root        1229  0.3  0.3 191500 53700 ?        Ss   Oct03  55:26 pvestatd
www-data  633339  0.0  0.2 243060 45772 ?        S    Oct06   0:12 pveproxy worker
www-data  633338  0.0  0.2 240752 43656 ?        S    Oct06   0:13 pveproxy worker
root        1222  0.2  0.2 186844 39176 ?        Ss   Oct03  31:18 pve-firewall
root        1250  0.0  0.2 238112 38112 ?        S    Oct03   0:17 pvedaemon worker
root        1248  0.0  0.2 238140 34304 ?        S    Oct03   0:19 pvedaemon worker
root        1299  0.0  0.2 213196 33772 ?        Ss   Oct03   1:40 pve-ha-lrm
root        1249  0.0  0.1 238124 30880 ?        S    Oct03   0:19 pvedaemon worker
root        1037  0.0  0.1 559872 27412 ?        Ssl  Oct03   7:13 /usr/bin/pmxcfs
www-data    1296  0.0  0.1  99172 27000 ?        Ss   Oct03   0:07 spiceproxy
www-data    1285  0.0  0.1 230320 25636 ?        Ss   Oct03   0:09 pveproxy
root         376  0.0  0.1  59424 25432 ?        Ss   Oct03   0:02 /usr/lib/systemd/systemd-journald
root         396  0.0  0.1  77300 21728 ?        SLsl Oct03   0:25 /usr/sbin/dmeventd -f
root        1664  0.0  0.1 209772 20408 ?        Ss   Oct03   1:06 pvescheduler
root     1361249  0.0  0.1 1290620 19288 ?       Ssl  Oct08   2:23 /usr/sbin/tailscaled --state=/var/lib/tailscale/tailscaled.state --socket=/run/tailscale/tailscaled.sock --port=41641

Ce sont vos trois machines virtuelles Proxmox/KVM qui consomment la mémoire, pas un processus Debian anormal :

VM RAM allouée RSS observée Part de la RAM hôte
pvm-alpine02 (ID 103) 4 GiB 3,6 GiB 22,2%
pvm-alpine03 (ID 101) 4 GiB 3,3 GiB 20,3%
jekyll-chirpy (ID 105) 3 GiB 3,05 GiB 18,8%
Total VM 11 GiB ~9,9 GiB ~61%

Avec 15 GiB sur l’hôte, ces trois VM laissent peu de marge pour Proxmox, le cache disque et les autres services ; cela explique les 2,1 GiB de swap utilisés. Les services Proxmox eux-mêmes (pveproxy, pvestatd, etc.) sont négligeables ici.

Pourquoi le swap est utilisé

Vous avez alloué 11 GiB aux VM sur un hôte de 15 GiB. Le noyau a donc déplacé des pages vers le swap, probablement lors d’un pic d’activité ou de démarrage des VM. Le balloon driver est présent, mais la mémoire réellement utilisée par chaque QEMU reste proche de la RAM configurée.

Solutions

Réduire la RAM des VM

Si les VM sont légères, réduisez leur allocation dans Proxmox :

1
2
3

qm set 103 --memory 2048
qm set 101 --memory 2048
qm set 105 --memory 2048

Un redémarrage de la VM est généralement nécessaire pour que la réduction soit pleinement effective. Cela libérerait environ 5 GiB pour l’hôte.

Utiliser le ballooning dynamiquement

Vos VM ont déjà virtio-balloon. Vous pouvez définir une plage :

1
2
3

qm set 103 --memory 4096 --balloon 2048
qm set 101 --memory 4096 --balloon 2048
qm set 105 --memory 3072 --balloon 1536

Le balloon permet à l’hôte de récupérer de la mémoire si les invités en utilisent peu, mais il ne remplace pas un dimensionnement réaliste : si les VM ont réellement besoin de leur RAM, l’hôte swappera quand même.

Ajouter de la RAM

Si les trois VM ont réellement besoin de 4/4/3 GiB, 15 GiB est insuffisant pour les faire tourner confortablement en même temps. Visez au minimum 24 GiB sur l’hôte pour garder une marge saine.

Vérification après changement

1
2
3
4

free -h
qm status 103 --verbose | grep -E 'mem|maxmem|balloon'
qm status 101 --verbose | grep -E 'mem|maxmem|balloon'
qm status 105 --verbose | grep -E 'mem|maxmem|balloon'

En pratique : réduisez d’abord pvm-alpine02 et pvm-alpine03 à 2 GiB si elles n’ont pas besoin de 4 GiB, puis observez free -h et l’usage swap. Si le swap reste utilisé mais n’augmente plus, la situation est stabilisée ; s’il continue de monter, réduisez encore la RAM ou ajoutez de la mémoire physique.

Le besoin réel en RAM des VM, un moyen de le déterminer?

Oui : la méthode fiable consiste à mesurer la mémoire à l’intérieur de chaque VM pendant plusieurs jours, puis à dimensionner sur le pic réel, pas sur la valeur used affichée par Proxmox. Le pilote ballooning permet justement à Proxmox de connaître la mémoire réellement utilisée par l’invité

Mesure dans chaque VM

Connectez-vous à chaque Alpine VM et lancez :

1

free -h

Regardez surtout available, pas free : le cache disque est réutilisable et ne compte pas comme un besoin durable

Ensuite, identifiez les processus les plus gourmands :

1

ps aux --sort=-rss | head -n 15

Et vérifiez la pression mémoire :

1

vmstat 2 10

Si les colonnes si et so restent à zéro ou quasi zéro, la VM ne swappe pas ; si elles sont régulièrement non nulles, elle manque de RAM

Suivre dans le temps

Un instantané ne suffit pas : mesurez le pic lors des tâches réelles (build Jekyll, mises à jour, services, redémarrages).

Dans chaque VM :

1

vmstat 60 | tee -a ~/mem-$(hostname)-$(date +%F).log

Ou un échantillon toutes les 5 minutes :

1
2
3
4

while true; do
  echo "$(date +%F_%T) $(free -m | awk '/^Mem:/ {print "used="$3" available="$7}')"
  sleep 300
done | tee -a ~/mem-history.log

Après quelques jours, prenez le maximum de used, ajoutez une marge d’environ 20 à 30%, et arrondissez au palier supérieur.

Vérifier depuis Proxmox

Sur l’hôte Proxmox, consultez la valeur rapportée par le balloon driver :

1
2
3

qm monitor 103
info balloon
quit

Répétez pour les VM 101 et 105. La commande info balloon affiche la mémoire courante et maximale vue par QEMU ; c’est une bonne indication de la consommation réelle de l’invité

Vous pouvez aussi vérifier que l’agent invité répond :

1
2
3

qm agent 103 ping
qm agent 101 ping
qm agent 105 ping

Règle de dimensionnement

Observation dans la VM RAM conseillée
Pic used ≈ 1,2 GiB, swap inactif 2 GiB
Pic used ≈ 2,2 GiB, swap inactif 3 GiB
Pic used ≈ 3 GiB ou swap occasionnel 4 GiB
Swap actif fréquent Augmenter la RAM ou optimiser la charge

Pour vos trois VM, si pvm-alpine02 et pvm-alpine03 montrent un pic réel autour de 1 à 1,5 GiB, les passer de 4 à 2 GiB est probablement raisonnable. Si elles approchent régulièrement de 3 GiB ou swapent, gardez 4 GiB et ajoutez plutôt de la RAM à l’hôte.

Cas particulier : Jekyll

La VM jekyll-chirpy fait probablement des builds. Mesurez-la pendant un bundle exec jekyll build :

1
2

free -h
/usr/bin/time -v bundle exec jekyll build 2>&1 | grep -E 'Maximum resident|Elapsed'

La ligne Maximum resident set size donne la mémoire maximale utilisée par le processus de build. Si elle dépasse largement 2 GiB, conservez 3 GiB pour cette VM ; sinon, 2 GiB peuvent suffire.

Le ballooning dynamique peut aider : par exemple qm set 103 --memory 4096 --balloon 2048 garantit 2 GiB minimum tout en permettant jusqu’à 4 GiB quand l’hôte a de la marge. Proxmox ajuste alors la mémoire selon la pression sur l’hôte.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Alipine Linux 
pvm-alpine02:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8G      611.8M        1.1G      170.2M        2.1G        2.8G
Swap:        421.0M           0      421.0M
pvm-alpine02:~$ ps aux --sort=-rss | head -n 15
ps: unrecognized option: sort=-rss
BusyBox v1.37.0 (2025-11-21 22:40:56 UTC) multi-call binary.

Usage: ps [-o COL1,COL2=HEADER] [-T]

Show list of processes

-o COL1,COL2=HEADERSelect columns for display
-TShow threads
pvm-alpine02:~$ vmstat 2 10
-sh: vmstat: not found
pvm-alpine02:~$

Votre VM pvm-alpine02 n’a pas besoin de 4 GiB en usage courant : elle utilise seulement 611,8 MiB, avec 2,8 GiB disponibles et aucun swap utilisé. Une réduction à 2 GiB serait très probablement confortable ; vous pourriez même tester 1,5 GiB si ses tâches restent légères.

Commandes compatibles Alpine

Alpine utilise BusyBox, donc ps --sort et vmstat ne sont pas disponibles par défaut. Utilisez plutôt :

1

ps -o pid,user,vsz,rss,comm

Pour trier par mémoire, BusyBox ps ne trie pas directement ; utilisez top :

1

top

Dans top, appuyez sur M pour trier par mémoire, puis q pour quitter.

Vous pouvez aussi installer les outils procps :

1
2

apk add procps
ps aux --sort=-rss | head -n 15

Et pour vmstat :

1
2

apk add procps
vmstat 2 10

Lecture de votre résultat

Valeur Interprétation
used: 611.8M Charge mémoire réelle actuelle faible.
buff/cache: 2.1G Cache disque ; récupérable, pas un besoin permanent.
available: 2.8G Large marge disponible.
Swap used: 0 Aucune pression mémoire actuellement.

Le point important est que cette VM a été configurée avec 4 GiB, mais son usage réel observé est d’environ 0,6 GiB. Même en conservant une marge généreuse, 2 GiB suffisent dans la plupart des cas.

Action recommandée

Depuis l’hôte Proxmox :

1
2

qm set 103 --memory 2048
qm reboot 103

Après redémarrage, vérifiez :

1

qm status 103 --verbose | grep -E 'mem|maxmem|balloon'

Puis, dans la VM :

1

free -h

Faites ensuite fonctionner vos services habituels quelques jours. Si available reste supérieur à environ 500 MiB et que le swap reste à 0, la réduction est validée. Si vous préférez une approche progressive, utilisez le ballooning :

1

qm set 103 --memory 4096 --balloon 2048

Ainsi la VM peut utiliser jusqu’à 4 GiB si nécessaire, mais Proxmox pourra récupérer la mémoire inutilisée.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

pvm-alpine03:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.6Gi       140Mi       3.9Mi       2.3Gi       2.2Gi
Swap:          1.2Gi          0B       1.2Gi
pvm-alpine03:~$ ps aux --sort=-rss | head -n 15
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
alpi      1470  1.1 23.1 3929120 927396 ?      Sl   Oct06 120:37 java -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/tmp/stirling-pdf -cp /app/app.jar:/app/lib/* stirling.software.SPDF.SPDFApplication
root      2363  0.0  2.6 1308968 106180 ?      Ssl  Oct03   9:09 /usr/bin/dockerd
root     31218  0.0  2.1 1373268 85152 ?       Ssl  Oct08   1:15 ./agent
alpi      5960  0.0  1.7 160148 70452 ?        S    00:02   0:03 /usr/local/bin/python3.14 /usr/local/bin/gunicorn -c /opt/apprise/webapp/gunicorn.conf.py --worker-tmp-dir /dev/shm core.wsgi
root      2531  0.0  1.3 1274624 53372 ?       Ssl  Oct03   6:23 containerd --config /var/run/docker/containerd/containerd.toml
root     26787  0.0  1.2 1385188 52036 ?       Ssl  Oct09   0:46 /watchtower
alpi      8292  0.0  1.0 123804 41904 ?        Sl   Oct04   0:57 /usr/local/bin/python3.14 /usr/local/bin/gunicorn -c /opt/apprise/webapp/gunicorn.conf.py --worker-tmp-dir /dev/shm core.wsgi
alpi      8195  0.0  0.8  40108 33764 ?        Ss   Oct04   1:15 /usr/local/bin/python3.14 /usr/local/bin/supervisord -c /tmp/apprise/supervisord.conf
ntfy      2597  0.0  0.7 1261136 30456 ?       Ssl  Oct03   0:57 /usr/bin/ntfy serve
root      3369  0.0  0.5 1270612 20484 ?       Ssl  Oct03   1:14 /agent
nobody    3736  0.0  0.4 153364 16860 ?        Ss   Oct03   0:15 php-fpm: master process (/etc/php8/php-fpm.conf)
root      1129  0.0  0.4 1237224 16404 ?       Sl   Oct06   2:07 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 60a7a11d67911d98285af5f603be3e0530b62a476aedcec6fa013cc3bee05d5f -address /var/run/docker/containerd/containerd.sock
root     26762  0.0  0.4 1237224 16184 ?       Sl   Oct09   1:07 /usr/bin/containerd-shim-runc-v2 -namespace moby -id cfb8057f5c347824c6e5d82b22661c190d49800314726dec7983e2b2a9dc28b3 -address /var/run/docker/containerd/containerd.sock
root     31193  0.0  0.3 1237224 14964 ?       Sl   Oct08   0:30 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 716f9d2f5ccecd80b126292d27d77a9f398027e7e35ec4b702d55fd733dc94b2 -address /var/run/docker/containerd/containerd.sock
pvm-alpine03:~$ vmstat 2 10
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  0      0 167796  94368 2364472    0    0     2     7  289    1  1  0 99  0  0  0
 0  0      0 167796  94368 2364472    0    0     0     6  448  294  0  0 100  0  0  0
 0  0      0 167796  94368 2364472    0    0     0    10  348  304  0  0 100  0  0  0

pvm-alpine03 utilise réellement environ 1,6 GiB, sans aucun swap actif. Le principal consommateur est Stirling-PDF, un processus Java qui occupe à lui seul environ 907 MiB de RSS.

Lecture

Élément Valeur Interprétation
used 1,6 GiB Charge réelle actuelle.
available 2,2 GiB Marge confortable.
Swap 0 B utilisé Aucune pression mémoire au repos.
java / Stirling-PDF ~907 MiB Principal consommateur.
Docker + containerd ~160 MiB Overhead des conteneurs.
Apprise, ntfy, PHP-FPM, agents ~200 MiB cumulés environ Charge secondaire.

vmstat confirme que la VM est saine : swpd est à 0 et les colonnes si/so sont à 0, donc elle ne swappe pas