Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

mémoire utilisée par le processus gnome-session

tusculan

Bonjour à tous 😉

J'ai remarqué (depuis quelques jours, mais cela ne signifie pas que cela ne se produisait pas avant) que gnome-session utilise de plus en plus en plus de mémoire au fur et à mesure de l'utilisation du PC : au début 75 Mo, jusqu'à plus d'un Go. C'est le bloc "heap" qui grossit.
Pour vider cette mémoire système, j'utilise la commande "r" (pour relancer le shell), et cela fonctionne (aucun dommage collatéral).
N'y aurait-il pas une autre solution plus propre ? 😉

Merci d'avance et bonne journée 🙂

Tusculan

MarbolanGos

Ça sent la fuite mémoire (memory leak) de gnome...
Peut-être tenter un :

strace -p `pidof gnome-session`

Et nous donner le résultat ([ctrl]+C pour arrêter le strace)

tusculan

Bonsoir MarbolanGos et merci de ta réponse 🙂

C'est bien un domaine dont j'ignore tout... 🙁

Voilà le résultat de la commande :

$ strace -p `pidof gnome-session`
Process 1512 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
recvmsg(10, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\0010\0\0\0\3D\0\0n\0\0\0\1\1o\0\27\0\0\0/org/fre"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 176
recvmsg(10, 0xbf87c1a8, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x8cfbca8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=12, events=POLLIN}, {fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=17, events=POLLIN}, {fd=30, events=POLLIN}, {fd=25, events=POLLIN}, {fd=24, events=POLLIN}, {fd=23, events=POLLIN}, {fd=28, events=POLLIN}, {fd=21, events=POLLIN}, {fd=27, events=POLLIN}, {fd=22, events=POLLIN}, {fd=19, events=POLLIN}, {fd=31, events=POLLIN}, {fd=26, events=POLLIN}, {fd=20, events=POLLIN}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN}], 20, 0) = 0 (Timeout)

Cela apporte-t-il des informations ?
Bonne nuit 🙂

Tusculan

MarbolanGos

Est-ce que gnome-session était dans un état où il « mangeait » la mémoire ?

À part que les lignes indiquent qu'il ne trouve pas quelques ressources (temporairement) ça me gêne pas...

tusculan

Bonjour MarbolanGos 🙂

En fait l'accroissement de la mémoire est progressif.

En observant les processus, j'ai découvert un 2e processus gnome-session :
- le 1er, pid 1512, dépend de gdm-session-wor, ne prend que 1 à 1,5 Mo, et c'est celui qu'a débogué mon strace (je ne l'avais pas vu avant ce matin, car mes processus n'étaient pas classés par ordre alphabétique, mais par occupation mémoire 🙁 ).
- le 2e, pid 16640, a pour "parent" le 1512, et c'est lui qui grossit : les fichiers concernés semblent être liés à l'affichage (/dev/nvidia0,
/usr/lib/nvidia/libnvidia-glcore.so.290.10, par exemple) et consomme de 3 à 6 % du CPU (quelques pics à 9 %, à 15 en regardant des vidéos). C'est effectivement en regardant des vidéos (qui saccadaient) que j'ai remarqué le souci. Mais en fait, en faisant le test, c'est non pas en regardant des vidéos, mais en ouvrant une image .jpg : l'ouverture de la 1re image a fait monter la mémoire de 100 Mo, mais c'est tout ; ensuite, impossible de reproduire la chose. 🙁

En tout cas j'ai fait un :

strace -p 16440

qui m'a donné quelques centaines de lignes dont voici quelques extraits qui m'ont paru significatifs (j'ai coupé des éléments similaires avant et après, puis au milieu)

poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\2\10\266\0\0\0\0\0\215A\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1329990496, 963722}, NULL) = 0
getpid()                                = 16440
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\212\f\34\0\0\0\0\0\7\327\1\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 112}, {NULL, 0}, {"", 0}], 3) = 112
poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\t\266\0\0\0\0\0\0\0\0x/H\16\0\0\0\0p\0\0\0)\230\10\1`\242,\1", 4096) = 32
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
munmap(0x9363d000, 3403776)             = 0
getpid()                                = 16440
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\212\f\34\0\0\0\0\0\7\327\1\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 112}, {NULL, 0}, {"", 0}], 3) = 112
poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\n\266\0\0\0\0\0\0\0\0x/H\16\0\0\0\0p\0\0\0)\230\10\1`\242,\1", 4096) = 32
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
mmap2(NULL, 3403776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9363d000
getpid()                                = 16440
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\212\f\34\0\0\0\0\0%\326\1\0\0\0\0\0@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 112}, {NULL, 0}, {"", 0}], 3) = 112
poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\v\266\0\0\0\0\0\0\0\0x/H\16\0\0\0\0p\0\0\0)\230\10\1`\242,\1", 4096) = 32
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
getpid()                                = 16440
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\212\f\34\0\0\0\0\0%\326\1\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 112}, {NULL, 0}, {"", 0}], 3) = 112
poll([{fd=6, events=POLLIN}], 1, -1)    = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\f\266\0\0\0\0\0\0\0\0x/H\16\0\0\0\0p\0\0\0)\230\10\1`\242,\1", 4096) = 32
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
read(6, 0x9afd9d8, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1329990496, 968690}, NULL) = 0
sched_yield()                           = 0
clock_gettime(CLOCK_MONOTONIC, {3337850, 759382995}) = 0
clock_gettime(CLOCK_MONOTONIC, {3337850, 759425653}) = 0
sched_yield()                           = 0

[...]

clock_gettime(CLOCK_MONOTONIC, {3337850, 790331905}) = 0
clock_gettime(CLOCK_MONOTONIC, {3337850, 790362868}) = 0
clock_gettime(CLOCK_MONOTONIC, {3337850, 790385314}) = 0
ioctl(8, 0xc020462a, 0xbfdecc48)        = 0
ioctl(8, 0xc020462a, 0xbfdecc28)        = 0
poll([{fd=12, events=POLLIN|POLLPRI}], 1, 1000) = 1 ([{fd=12, revents=POLLIN|POLLPRI}])
ioctl(12, 0xc0104652, 0xbfdecbe8)       = 0
sched_yield()                           = 0
sched_yield()                           = 0

Voilà ce que je peux dire.

Bonne journée 🙂

Tusculan

MarbolanGos

Le strace ne me semble pas suspect. Est-ce que ça ne serait pas simplement du cache qui est mis en RAM ?
Essaye pour voir si la taille de la mémoire utilisée ne change pas avec :

echo 3 > /proc/sys/vm/drop_caches

tusculan

Bonjour MarbolanGos 🙂

Effectivement, en lançant

echo 3 > /proc/sys/vm/drop_caches

la mémoire a progressivement pris 50 Mo (par paliers de 6 ou 8 Mo) avant de se stabiliser - sans que je ne fasse tourner d'autres programmes que ceux précédemment démarrés. J'avais auparavant relancé le shell. 🙂

Que ce soit ou non la source du phénomène (qui n'est pas un problème en soi), y a-t-il une solution pour remédier à cela ou est-ce inéluctable ? Après tout, les autres processus "en activité" (firefox, thunderbird...) voient aussi leur occupation mémoire augmenter, mais cela s'explique par l'ouverture d'un message, d'un onglet, etc...).
Tant que cela ne m'empêche pas de faire tourner le PC ou tels programmes, ce n'est pas gênant. C'est entre autres une des différences que j'avais noté dans le passage à Gnome 3 que cette importante occupation mémoire dont je n'avais observé les variations (quand je pense à mon vieux IBM X24 où Fedora tourne avec seulement 640 Mo - sous XFCE, il est vrai, qui se contente de quelques dizaines de Mo !).

Bonne journée 🙂

Tusculan