Comment libérer la mémoire encore occupée par des processus terminés ?

Bonjour,

dans une machine virtuelle Debian 32 bits dotée de 1,5 Go de mémoire, le lancement d'un outil pour générer en utilisant make le compilateur Free Pascal (FPC) puis ensuite utiliser ce compilateur fraîchement créé pour créer le créateur de Lazarus (Lazbuild -- oui c'est compliqué :mrgreen:) me fait baisser la mémoire libre de la machine à moins de 100 ko par moments pendant l'exécution.

(Lorsque la MV n'avait que 1 Go ça plantait ! Y a pas de ceintures de sécurité dans Linux ? :aie:)

Le problème c'est qu'à la fin de ce processus, alors que tout s'est bien déroulé/bien terminé, la mémoire n'est pas libérée ; voilà ce que me dit cat proc/meminfo

Code:

---

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 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

MemTotal: 1554360 kB MemFree: 298584 kB Buffers: 43932 kB Cached: 1026068 kB SwapCached: 0 kB Active: 261548 kB Inactive: 929096 kB Active(anon): 7804 kB Inactive(anon): 117692 kB Active(file): 253744 kB Inactive(file): 811404 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 661448 kB HighFree: 106672 kB LowTotal: 892912 kB LowFree: 191912 kB SwapTotal: 477180 kB SwapFree: 477132 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 120700 kB Mapped: 46004 kB Shmem: 4852 kB Slab: 52412 kB SReclaimable: 44308 kB SUnreclaim: 8104 kB KernelStack: 1792 kB PageTables: 3184 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 1254360 kB Committed_AS: 516100 kB VmallocTotal: 122880 kB VmallocUsed: 23880 kB VmallocChunk: 98432 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 6136 kB DirectMap2M: 905216 kB

---

et la mémoire n'est pas récupérée par un logoff/logon... Obligé de rebooter, comme dans Windows !?

Quelqu'un connaîtrait un outil/une combine pour libérer cette mémoire ?
D'avance merci,

Bonjour,

As-tu vérifié les IPCs avant et après ta commande pour voir si les éventuels segments de mémoires, queues de message et sémaphores sont bien libérés ?
Je ne dis pas que c'est le problème car ta commande peut très bien ne pas utiliser d'ipc (man ipcs et man ipcrm.

Merci de te pencher sur mon souci.

Pour répondre à ta question, c'est facile, c'est "non" pour la bonne et simple raison que je ne connaissais pas l'existence de ces ipc's et des commandes (dont le résultat est, pour moi, totalement inexploitable) que tu cites...

salut,

quand un processus se termine il est détruit et la mémoire qu'il occupait est libérée, c'est garanti par le kernel

ce que tu prends pour de la mémoire non libérée à mon avis c'est les buffers/caches, elle n'est pas comptabilisée par free -m comme de la mémoire libre, mais elle est disponible, le kernel la transformera en mémoire libre (vide) au moment voulu (ou s'en servira telle quelle s'il peut, ce qui est censé lui faire gagner du temps et accélérer son fonctionnement)

si malgré tout tu tiens à vider les buffers/caches tu peux utiliser la commande classique :

Code:

---

sync && echo 3 > /proc/sys/vm/drop_caches

---

Salut,

Tu peux ausi vérifier si des process et/ou leurs enfants, censés être terminés, sont toujours présents (de type unix Zombie) et gardent des fichiers ouverts avec de la mémoire allouée par la commande lsof.

Salut salut,

Citation:

---

Envoyé par Escapetiger

Salut,

Tu peux aussi vérifier si des process et/ou leurs enfants, censés être terminés, gardent des fichiers ouverts avec de la mémoire allouée par la commande lsof.

---

Hey, les 3 process qui me concernent (le maître-lanceur et la création des deux compilateurs) sont supposés être terminés puisque je ne les vois pas avec ps ax à la fin du run. À partir de là, difficile (pour moi) de leur trouver des fichiers encore ouverts...

Une chose curieuse, cependant : dans un premier essai avec seulement 1 Go de mémoire vive, à un moment make pendant la phase de linking du second compilateur (celui pour Lazarus, 60 et quelques Mo l'exécutable, ouch !) n'a pas pu forker un process (voir l'image), et s'est arrêté en erreur (could not read symbols: Memory exhausted). Il restait 50 ko de libre.

Pièce jointe 191274

(Ne pas se fier au titre de la petite fenêtre du message d'erreur, qui fait référence à l'autre programme utilisé pour m'afficher l'espace disque et la mémoire libre [on se demande bien pourquoi la fenêtre d'erreur fait référence à ce programme {faudrait que je mettre ça dans Tchernobyl, :mrgreen:}, qui ne m'a jamais fait d'erreurs, depuis ses premiers développements il y a 20 ans sous W95 avec VB4 : c'est toujours le même algo qui tourne, :ccool: !])

Citation:

---

Envoyé par BufferBob

salut,

quand un processus se termine il est détruit et la mémoire qu'il occupait est libérée, c'est garanti par le kernel

ce que tu prends pour de la mémoire non libérée à mon avis c'est les buffers/caches, elle n'est pas comptabilisée par free -m comme de la mémoire libre, mais elle est disponible, le kernel la transformera en mémoire libre (vide) au moment voulu (ou s'en servira telle quelle s'il peut, ce qui est censé lui faire gagner du temps et accélérer son fonctionnement)

---

On dirait : en passant la mémoire à 1,5 Go, j'ai eu des descentes à seulement 95 ko libres mais ça n'a pas planté. Je n'ai cependant pas osé lancer un second run.
En passant la mémoire à 2 Go un premier run l'a fait descendre assez bas puis remonter à la fin à environ 300 Mo libres et j'ai osé lancer un second run qui n'a pas fait descendre plus bas qu'environ 200 Mo libres à la fin, comme si le second run avait beaucoup moins consommé que le premier, ou peut-être qu'une partie des ressources du premier a été attribuée au second ?

Au final et d'après ce que tu dis, tout cela est peut-être normal, alors...
Ce qui reste curieux, c'est cette erreur quand il n'y avait que 1 Go de mémoire : le mécanisme de swap n'aurait pas pu prendre le relais ?

Citation:

---

Envoyé par BufferBob

si malgré tout tu tiens à vider les buffers/caches tu peux utiliser la commande classique :

Code:

---

sync && echo 3 > /proc/sys/vm/drop_caches

---

---

Je note la commande dans un coin, je n'ai pas fini mes tests avec ces histoires de création de compilateurs.

Citation:

---

Envoyé par BufferBob

quand un processus se termine il est détruit et la mémoire qu'il occupait est libérée, c'est garanti par le kernel

---

Ceci n'est pas vrai concernant la shared memory que le dit processus a pu allouer par le mecanisme des IPCs: tous les processus attachés à cette shared memory doivent être détachés (donc au pire, quand ils meurent) mais il faut aussi que celle-ci soit marquée comme détruite.

Bon, après, en relisant le 1er post de plus près, la shared memory ne concerne pas le soi-disant problème. :oops:

Yop !

Des nouvelles...

Des nouvelles catastrophiques (j'aurais dû poster dans Tchernobyl) :

- d'abord, les mêmes paramètres de compilation que ces derniers jours font que ce matin l'animal a décidé de son plein gré d'utiliser le swap ! Résultat, un truc qui s'exécutait hier en 15 minutes n'est toujours pas terminé aujourd'hui au bout de deux heures... En plus ça me bouffe toute la mémoire ou presque de la machine hôte (4 Go, 380 ko dispo pendant que je pianote ça alors qu'il n'y a que la machine virtuelle d'ouverte, plus le navigateur et l'ide Lazarus, pas de quoi fouetter un chat).

- ensuite, merci pour la proposition d'utiliser lsof mais c'est pas le genre d'outil qui peut pointer les fichiers "user" qui consomment de la mémoire ; par exemple, pour éditer l'image ci-après j'ai lancé The Gimp puis ps ax pour trouver son pid puis lsof -p <pid> | wc -l m'a renvoyé environ 170 fichiers mais lsof -p <pid> | grep png ne m'a renvoyé que les librairies contenant "png" dans leur nom et mon fichier image, bernique !
J'avais fait la même manip avec geany et un fichier texte de 4 Mo en édition (une belle emprise mémoire, nan ?), non trouvé par lsof. Bref... On ne doit pas avoir la même définition de "fichiers ouverts", lsof et moi.

- enfin, pendant que ça moulinait, en fin de matinée, dans la machine virtuelle, mal m'en a pris de vouloir "remonter" (car déjà dans la barre de tâches) l'ami geany et vouloir le déplacer car là, tout s'est figé d'un point de vue graphique, sauf la fenêtre du terminal qui continuait à afficher ses lignes au fur et à mesure de l'avancement du boulot. Mais pour reprendre la main va te rouler ! J'ai fait une copie d'écran depuis l'hôte en demandant l'inclusion du curseur car j'aurais aimé vous le montrer, il s'agissait de la grosse croix de "déplacement" mais ça n'a pas été renvoyé à la copie d'écran qui affiche le pointeur classique en haut à gauche, dans le titre du terminal. Désolé...

Pièce jointe 191325

Il a fallu que je me connecte en ssh depuis l'hôte, j'ai essayé de tuer les fenêtres que je supposais plantées mais ça s'est terminé par un reboot à la Windows...


Tiens, à l'instant (14h32), la compilation vient d'avorter avec /usr/bin/ld: final link failed: Memory exhausted... Bien sûr ça a libéré la mémoire qui se retrouve à 95 % libre alors que pendant que ça compilait j'étais à 5 % et, tiens, 3 visions du swap : 2 pendant la compil, et 1 après :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

# cat /proc/meminfo | grep Swap SwapCached: 145916 kB SwapTotal: 477180 kB SwapFree: 8 kB <---- # cat /proc/meminfo | grep Swap SwapCached: 142492 kB SwapTotal: 477180 kB SwapFree: 12 kB # cat /proc/meminfo | grep Swap SwapCached: 14108 kB SwapTotal: 477180 kB SwapFree: 393616 kB <---- #

---

C'est désespérant, et je ne me sens pas de refaire un essai, d'autant plus que je ne sais pas quoi changer... Par contre, je suis désolé d'avoir dérangé la communauté avec mes questions décalées par rapport à la réalité qui est que l'ensemble machine virtuelle + Debian un peu vieux + Xfce écrit avec les pieds = n'importe quoi en terme de comportements :calim2:

Ah si, je sais quoi changer : la machine virtuelle ! J'en ai une autre avec Lxde ; la seule blague que je lui connaisse, pour le moment, c'est son explorateur (pcmanfm) qui crashe parfois, sans prévenir, particulièrement quand je lui demande un rafraîchissement (ou quand lui décide de le faire tout seul). Bah, je le relance et c'est bon -- mais c'est gonflant !

Citation:

---

Envoyé par Jipété

C'est désespérant (...) que je ne sais pas quoi changer...

---

d'après ce que tu expliques je dirai la toolchain, voire carrément le langage ^^'

sinon t'avais pas moyen de lancer un htop depuis ssh pendant la compilation pour voir quel processus exactement prend toute la mémoire ?
quand même... 1Go de RAM + 480Mo de swap (bon c'est peut-être un peu léger niveau swap quand même par rapport à la RAM disponible) c'est tout de même ahurissant, c'est à se demander ce que tu compiles 8O

Citation:

---

Envoyé par BufferBob

c'est tout de même ahurissant, c'est à se demander ce que tu compiles 8O

---

Juste le compilateur et les outils associés de FPC (Free Pascal Compiler) et le compilateur et les outils associés de Lazarus, l'IDE Pascal qui s'appuie sur.. FPC :P
Pas de quoi fouetter un chat, surtout que la machine virtuelle étant monoprocesseur, rien n'est parallélisé (ouf !)

Bon, là, je repars sur une autre plateforme Debian dans une autre VM, les soucis viennent des paquets manquants, et je hais ce système de paquets ! Pour une petite librairie ridicule (mais nécessaire :aie:) de quelques ko, le système est en train de supprimer pour mettre à jour tout LibreOffice ! J'ai le temps de te répondre, tu vois !

Et y a ces histoires de make, aussi, sans points de reprise, donc si ça plante à la fin suite à cette absence de paquets (tu crois pas que les installeurs pourraient le dire dès le début du process ???), lors de l'édition des liens, ben une fois les paquets manquants installés, faut relancer le make qui va se faire un plaisir de supprimer tous les petits .o qu'il a passé 30 minutes à créer. C'est nul je trouve...

Et alors, lors de l'édition des liens, justement, les messages qui "tombent" dans le terminal le mettent en vrac, c'est rigolo ! Ça génère plein plein plein de pages de terminal vides puis t'as la ligne "linking blabla..." tout en bas, j'avais pas ça dans l'autre machine.

Ah, pendant qu'on parle, une erreur pendant la màj de LO tombe :

Citation:

---

Une erreur s'est produite

Les détails suivants sont donnés :

E: /var/cache/apt/archives/python3-uno_1%3a5.0.3~rc1-2_i386.deb: tentative de remplacement de « /usr/lib/libreoffice/program/officehelper.py », qui appartient aussi au paquet libreoffice-emailmerge 1:3.5.4+dfsg-4

---

Super, oui, et alors, qu'est-ce que je suis censé faire, là ?, d'autant plus que je n'ai qu'un bouton "Fermer"... On verra bien... Si jamais les librairies sont passées, peut-être que le linker va s'en sortir ?

Il me semble que c'était plus fiable et plus rigoureux il y a 10-15 ans, tout ça...

Bonjour,

j'ai du mal a comprendre
puisque tu es en VM pourquoi ne pas allouer 2Go (ta machine en a 4!) et 2(ou +) cœurs (si le compilateur de lazarus utilise???) ? plus tu va allouer et plus vite sera fini la compilation; si elle dure 2 heures avec le swap c'est juste que tu es trop serré.

Il n'est pas possible de lancer la compilation sans xfce directement en tty ? tu vas gagner 200Mo ou +

Et si ton interface est figée il te reste l'accès à tty (touches Host + F2 avec virtualbox)

Citation:

---

Envoyé par Jipété

Il me semble que c'était plus fiable et plus rigoureux il y a 10-15 ans, tout ça...

---

ça fait 15 ans que j'ai abandonné delphi et je ne m'en porte que mieux ;) et linux ... depuis 10 ans il a très bien progressé ! on ne le trouve pas sur la majorité des serveurs pour rien

Citation:

---

Envoyé par papajoker

j'ai du mal a comprendre
puisque tu es en VM pourquoi ne pas allouer 2Go (ta machine en a 4!) et 2(ou +) cœurs (si le compilateur de lazarus utilise???) ? plus tu va allouer et plus vite sera fini la compilation; si elle dure 2 heures avec le swap c'est juste que tu es trop serré.

---

Message 6:

Citation:

---

On dirait : en passant la mémoire à 1,5 Go, j'ai eu des descentes à seulement 95 ko libres mais ça n'a pas planté. Je n'ai cependant pas osé lancer un second run.
En passant la mémoire à 2 Go un premier run l'a fait descendre assez bas puis remonter à la fin à environ 300 Mo libres et j'ai osé lancer un second run qui n'a pas fait descendre plus bas qu'environ 200 Mo libres à la fin, comme si le second run avait beaucoup moins consommé que le premier, ou peut-être qu'une partie des ressources du premier a été attribuée au second ?

---

Et j'en profite pour répondre: lorsque tu compiles, le compilateur va créer des fichiers temporaires (en C/ C++ on parle d'unités de compilation, des fichiers .o ou .obj et peut-être des dossiers ~)
C'est make/ gcc qui vérifie si le fichier a déjà été compilé et s'il y a eu des modifications depuis.

Et en théorie tu peux faire un make clean pour tout effacer.

Citation:

---

Envoyé par papajoker

Bonjour,

j'ai du mal a comprendre
puisque tu es en VM pourquoi ne pas allouer 2Go (ta machine en a 4!) et 2(ou +) cœurs (si le compilateur de lazarus utilise???) ? plus tu va allouer et plus vite sera fini la compilation; si elle dure 2 heures avec le swap c'est juste que tu es trop serré.

---

Je pense que tu n'as pas bien lu mon petit laïus : hier avec la même config il n'y a pas eu d'accès au swap et la compilation était torchée en 15 minutes par compilo (oui, j'ai 2 cibles : FPC et Lazarus).
Quant aux cœurs multiples, je ne sais pas si c'est géré/supporté/possible sous VirtualBox, mais vu la pagaille en monocœur, je n'ose imaginer ce que ça serait en multi ! Laisse tomber !

Citation:

---

Envoyé par papajoker

Il n'est pas possible de lancer la compilation sans xfce directement en tty ? tu vas gagner 200Mo ou +

---

J'avoue ne pas y avoir pensé, car je ne sais même pas si c'est possible de démarrer en mode console. Je tenterai, à l'occasion...
EDIT : bon, ça me démangeait alors je viens d'essayer. Résultats : en runlevel 1 (passé au kernel au boot) on ne fait quasiment rien mais on y accède, et dès le runlevel 2 demandé la machine continue jusqu'à entrer le runlevel 5 et l'interface graphique, je ne sais pas pourquoi. /EDIT

Citation:

---

Envoyé par papajoker

Et si ton interface est figée il te reste l'accès à tty (touches Host + F2 avec virtualbox)

---

EDIT Mais tu penses bien que j'ai essayé, mais plus rien ne répondait, hélas... J'ai répondu un peu vite, là, et me suis embrouillé : ce que j'ai essayé (et qui ne fonctionnait pas), c'est les touches classiques (CTRL ALT F2...6), je ne savais pas qu'il fallait passer par la touche Host : je note l'info, ça servira un jour :ccool: /EDIT

Citation:

---

Envoyé par papajoker

ça fait 15 ans que j'ai abandonné delphi et je ne m'en porte que mieux ;) et linux ... depuis 10 ans il a très bien progressé ! on ne le trouve pas sur la majorité des serveurs pour rien

---

Le jour où tu vas (essayer d') utiliser intensément l'aide de Lazarus, tu vas voir comme tu vas pleurer et comme tu vas regretter l'aide de D7.
Oui, les serveurs, je sais... Mais je ne me vois pas faire du traitement d'images ou de son, ou du montage vidéo ou de la PAO en console, tu vois :ptdr:

Citation:

---

Envoyé par foetus

Et j'en profite pour répondre: lorsque tu compiles, le compilateur va créer des fichiers temporaires (en C/ C++ on parle d'unités de compilation, des fichiers .o ou .obj et peut-être des dossiers ~)
C'est make/ gcc qui vérifie si le fichier a déjà été compilé et s'il y a eu des modifications depuis.

Et en théorie tu peux faire un make clean pour tout effacer.

---

Oui, mais ce n'est pas cette place qui m'a posé problème mais vraiment la mémoire vive. Bon, en fin d'aprème j'ai réussi à générer sous Lxde mes deux compilos (@BufferBob : j'ai trouvé dans les logs la commande pour relancer juste le make qui m'intéressait, après avoir réussi à régler les soucis de dépendances, de paquets cassés [tu connais Murphy, je suppose :mouarf:]) et avec seulement 1,5 Go de mémoire.

Content, le monsieur, ce soir :mrgreen:

Citation:

---

Envoyé par Jipété

j'ai trouvé dans les logs la commande pour relancer juste le make qui m'intéressait, après avoir réussi à régler les soucis de dépendances, de paquets cassés [tu connais Murphy, je suppose :mouarf:]) et avec seulement 1,5 Go de mémoire.

---

à l'arrivée on sait pas si c'est la VM qu'est trop petite ou le combo FPC/Lazarus qui met la machine à genoux ou l'interface graphique+serveur X qui est de trop ou autre, mais ça a l'air d'être un sacré brol en effet :mouarf:

Citation:

---

Envoyé par BufferBob

à l'arrivée on sait pas si c'est la VM qu'est trop petite ou le combo FPC/Lazarus qui met la machine à genoux ou l'interface graphique+serveur X qui est de trop ou autre, mais ça a l'air d'être un sacré brol en effet :mouarf:

---

Ex-ac-te-ment ! :ptdr:

Allez, je ne résiste pas au plaisir d'illustrer mon propos avec une copie d'écran satisfaisante puisque, dans la nouvelle MV à base de Lxde et 1,5 Go de mémoire seulement, l'opération se déroule bien et aboutit en 12 minutes ! :ccool:
Je parle au singulier, car l'installation de FPC se déroulant toujours bien, je ne la relance plus

Je vais donc, à partir de maintenant, jouer à installer des composants dans ce Lazarus, faire des upgrades et voir comment tout ça se comporte (l'idée de base vient de là, fatigué d'être obligé, à chaque nouvelle version, de réinstaller tout le fourbi des compos tierces parties)

Si je m'en sors, je peux supposer que ce sacré brol disparaîtra une fois la procédure mise en prod dans la machine physique.

Alors ci-dessous en haut en blanc le fichier de log qui faisait 11200 lignes quand je l'ai ouvert (j'ai dit hier que la commande /usr/bin/ld me floodait la console de lignes vides) et que j'ai ramené à 8700, différence = 4500 lignes !, et en bas, la sortie de la console, justement, à la fin de l'exécution, où l'on voit bien le vide au dessus de la ligne d'avertissement du linker. À un moment il a fallu que j'appuie 24 fois sur <page suivante> tout en sélectionnant, pour supprimer ces vides déments qui n'existaient pas dans les fichiers de log générés par la MV précédente !

Pièce jointe 191444

J'en conclus que les environnements de bureau sous Linux ont des vies autonomes et parallèles, :mouarf:

Parce que par exemple, dans la MV Xfce je faisais un peu ce que je voulais (examen des vieux logs, des inis pour futurs runs, etc.) pendant que ça compilait (jusqu'à hier où j'ai eu ce blocage total puis ce passage en mode "swap" au reboot), chose impossible à faire dans la MV Lxde car il suffit de bouger un peu les fenêtres pour se retrouver avec le script bloqué sur une instruction svn export --blabla que je kille depuis un autre terminal pour que ça continue mais bon, ça fait chaud aux fesses et du coup on arrête de tripoter les autres fenêtres...

Bon, allez, on papote on papote, mais j'ai des compos à installer, moi :P

Yop !

Citation:

---

Envoyé par Jipété

Bon, allez, on papote on papote, mais j'ai des compos à installer, moi :P

---

Les dernières nouvelles là où les choses ont commencé, dans le post d'origine, yaka suivre le lien 8-)

Allez, écran noir pour le dernier post ici, et après je clique sur :resolu:

Pièce jointe 191968

Et donc j'en avais un peu parlé car ce fut très surprenant pour moi, d'autant plus que je n'ai pas eu ce comportement dans la première VM, celle qui s'est mise à swapper comme une folle et que j'ai abandonnée à cause de ça.

J'ai choisi cette copie d'écran car on peut y voir en haut les dernières commandes affichées, et en bas une information en provenance du programme en cours d'exécution, le linker GNU en train de... linker :D.
J'ai mis "et" en gras parce que d'habitude il y avait tellement de flood à la console que les textes du haut disparaissaient, ne laissant que l'info du bas, très très curieux et stressant à vivre...

Merci de m'avoir lu et soutenu :coucou:.