Utilisation mémoire

[VincentAntoine]

@louptheron Suite à nos inquiétudes sur l'utilisation de la mémoire, dont la consommation affichée dans htop a encore augmenté ce matin 4 mars depuis hier, j'ai enquêté sur notre intégration, et j'en conclue qu'en réalité il n'y a pas de problème (en tout cas il n'y en a plus depuis la résolution des problèmes de zombies de Prefect et depuis que j'ai sorti l'agent Prefect de son container!), mais je garde ici les résultats pour référence ultérieure en cas de besoin.

Vendredi 4 mars

>>> htop

La mémoire utilisée est montée à 11.5 - 12 Gb, vs 8-9 Gb observé les semaines précédentes quand j'y jetais un oeil.

---

Inspection des process :

>>> ps ax -o ppid -o ,%p, -o %mem -o ,%C, -o lstart -o ,%C, -o rss -o ,%C, -o command

Top 15 par RSS décroissant:

ppid	pid	started	rss	mem	cpu	command
124132	124162	Mon Feb 28 09:11:17 2022	1890.9	11.7	0.4	/docker-java-home/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -server -Xms2G -Xmx4G -XX:PerfDataSamplingInterval=500 -Dorg.geotools.referencing.forceXY=true -XX:SoftRefLRUPolicyMSPerMB=36000 -XX:NewRatio=2 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=20 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70 -XX:+CMSClassUnloadingEnabled -Dfile.encoding=UTF8 -Duser.timezone=GMT -Djavax.servlet.request.encoding=UTF-8 -Djavax.servlet.response.encoding=UTF-8 -DCLUSTER_CONFIG_DIR=/opt/geoserver/data_dir/cluster/instance_23bd87cfa327d47e -DGEOSERVER_DATA_DIR=/opt/geoserver/data_dir -Dorg.geotools.shapefile.datetime=true -Ds3.properties.location=/opt/geoserver/data_dir/s3.properties -Dsun.java2d.renderer.useThreadLocal=false -Dsun.java2d.renderer.pixelsize=8192 -server -XX:NewSize=300m -Dlog4j.configuration=/usr/local/tomcat/log4j.properties --patch-module java.desktop=/usr/local/tomcat/marlin-0.9.4.2-Unsafe-OpenJDK9.jar -Dsun.java2d.renderer=org.marlin.pisces.PiscesRenderingEngine -Dgeoserver.login.autocomplete=on -DGEOSERVER_CONSOLE_DISABLED=false -Dgeoserver.xframe.shouldSetPolicy=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= -classpath /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/tomcat -Dcatalina.home=/usr/local/tomcat -Djava.io.tmpdir=/usr/local/tomcat/temp org.apache.catalina.startup.Bootstrap start
44985	45035	Mon Feb 28 04:55:05 2022	1608.9	9.9	1.6	java -Dspring.config.additional-location=/home/monitorfish/configurations/ -jar monitorfish-v1.6.4_snapshot-exec.jar
94540	27357	Fri Mar 4 11:22:51 2022	1563.1	9.6	6.3	postgres: postgres monitorfishdb 10.10.3.3(33372) idle
94540	124507	Mon Feb 28 09:11:26 2022	509.7	3.1	0	postgres: checkpointer
95418	95419	Thu Mar 3 16:19:13 2022	219.9	1.3	2.9	node dist/index.js
94540	75684	Mon Feb 28 10:23:24 2022	178.2	1.1	0	postgres: postgres monitorfishdb 10.10.3.4(47680) idle
94540	76219	Mon Feb 28 10:23:36 2022	162.2	1	0	postgres: postgres monitorfishdb 10.10.3.4(47892) idle
94540	75682	Mon Feb 28 10:23:24 2022	142.3	0.8	0	postgres: postgres monitorfishdb 10.10.3.4(47676) idle
94540	75687	Mon Feb 28 10:23:24 2022	138.6	0.8	0	postgres: postgres monitorfishdb 10.10.3.4(47686) idle
29364	29810	Tue Mar 1 12:29:20 2022	138.4	0.8	0	postgres: checkpointer
120770	120789	Fri Mar 4 08:30:10 2022	136.8	0.8	3.5	graphql-engine serve
29364	29811	Tue Mar 1 12:29:20 2022	135.8	0.8	0	postgres: background writer
94540	75686	Mon Feb 28 10:23:24 2022	133.8	0.8	0	postgres: postgres monitorfishdb 10.10.3.4(47684) idle
94540	124509	Mon Feb 28 09:11:26 2022	128.5	0.7	0	postgres: background writer
94540	75683	Mon Feb 28 10:23:24 2022	126.9	0.7	0	postgres: postgres monitorfishdb 10.10.3.4(47678) idle

/!\ en sommant la mémoire allouée aux process, on peut compter plusieurs fois la même mémoire (si des pages mémoire sont utilisées par plusieurs process) et on peut aussi en rater - ça donne simplement une idée des process gourmands. On voit notamment que :

• les principaux consommateurs sont le geoserver, l'app et la BDD de l'app
• l'agent prefect (plus bas dans la liste) consomme 75Mb de RAM
• il n'y a pas de process zombie

---

>>> docker stats

Cohérent avec l'analyse de ps ci-dessus. On voit aussi qu'au total, les 6 services qui composent Prefect server consomment 800Mb. On a donc :

• Dans docker :
  • 1.9 Gb pour le geoserver
  • 2.2 Gb pour la BDD
  • 1.6 Gb pour l'app
  • 0.8 Gb pour Prefect server
  • Quelques centaines de Mb pour les flows (quand il y en a qui tournent)
• Hors docker :
  • 0.075 Gb pour l'agent Prefect
  • L'utilisation par l'OS

On voit qu'on utilise beaucoup moins que les 11.5 Gb affichés comme "utilisés" dans htop - où est la RAM manquante ?

---

Autre analyse de la mémoire utilisée avec free:

>>> free -m
              total        used        free      shared  buff/cache   available
Mem:          16147        9235        1716        2269        5195        4359
Swap:          4095         572        3523

--> On retrouve la même quantité de RAM disponible que dans htop, 4.3Gb, soit 11.5Gb utilisés...

D'après https://www.linuxatemyram.com/:

A healthy Linux system with more than enough memory will, after running for a while, show the following expected and harmless behavior:

• free memory is close to 0
• used memory is close to total
• available memory (or "free + buffers/cache") has enough room (let's say, 20%+ of total)
• swap used does not change

Ce serait donc normal que la mémoire "utilisée" augmente avec le temps, Linux utilisant la mémoire pour améliorer les performances.

Pour vérifier qu'il s'agit bien d'un phénomène normal de cache de Linux, j'ai réinitialisé les caches (cf https://www.linuxatemyram.com/play.html)

>>> echo 3 | sudo tee /proc/sys/vm/drop_caches 
>>> free -m
              total        used        free      shared  buff/cache   available
Mem:          16147        7056        6474        2268        2616        6542
Swap:          4095         574        3521

>>> htop

On voit que le "cached" et le "used" ont diminué et que "free" et le "available" ont augmenté. La mémoire consommée redescend à 9Gb. C'est donc bien l'OS qui utilise l'espace pour optimiser les perfs, tout va bien :)

Enfin pour comprendre ce que raconte free (schema d'après http://manpages.ubuntu.com/manpages/focal/en/man1/free.1.html):

• total = free + buff/cache + used
• available = free + une partie de used + une partie de buff/cache

Tant qu'il y a de la mémoire disponible en abondance, l'OS va faire gonfler le buff/cache et le used et faire diminuer le free pour optimiser les perfs mais ça ne veut pas dire que c'est nos process qui sont gourmands ni qu'on risque de manquer de RAM :)