Depuis que j'ai installé Debian GNU/Linux 3.1 sur mon PC, je suis au prise
avec un problème de consommation de mémoire. En effet, tous les jours,
alors que je vais me coucher avec 96mb (sur 394) d'occupation de mémoire,
je me réveille avec une occupation supérieure à 200mb. J'ai d'abord
soupconné le driver graphique NVidia puisque j'ai trouvé quelqu'un y
soulevant la possibilité d'un leak sur Internet.
Récemment, j'ai cependant découvert que le driver NVidia n'avait sans doute
rien à y avoir. Avec le programme "atop", j'ai obversé que c'est la
mémoire "slab" qui occupait une grande partie de ma mémoire (~140mb) au
moment ou l'on se parle, et que cette grande occupation arrivait la matin à
la suite de la mise à jour de la base de donnée updatedb. En effet, le
démontage de mes partitions NTFS libère beaucoup de cette espace. Mais il
y a quelques minutes, je me suis rendu compte que le cataloguage des
partition ext3 faisait le même effet.
Je ne sais pas trop ce qu'est la mémoire "slab" et quelle rôle elle joue.
Ce que j'aimerais surtout savoir, c'est si ce comportement est normal et
que la mémoire allouée au slab peut être restitué par le système. Si ce
n'est pas normale, j'aimerais qu'on me donne des pistes de solution, ou
qu'on me redirige vers des gens pouvant m'en donner.
** free.post-run.2.log (après updatedb de mes 2 parititions NTFS)
-/+ buffers/cache: 186944 199888
On constate rien d'anormal.
Si, tu lis mal.
en particulier ici lors du 'updatedb' qui fait appel à de nombreux accès aux données des disques.
Ce n'était pas _lors du_ updatedb, mais _après_ l'updatedb.
Quand la mémoire semble être très occupée, une grande partie est en fait en cache
Ce n'est _pas_ ce qu'indique free : il indique effectivement près de 160 Mo occupés en plus après l'updatedb qu'avant, _sans compter le cache_.
En l'occurence, /proc/slabinfo indiquerait probablement que c'est quand même du cache, mais ça n'avait rien d'évident, et ça mériterait par ailleurs un bug-report aux auteurs de free.
"TiChou" wrote in message <pwet.20040916140348@florizarre.tichou.org>:
** free.post-run.2.log (après updatedb de mes 2 parititions NTFS)
-/+ buffers/cache: 186944 199888
On constate rien d'anormal.
Si, tu lis mal.
en particulier ici lors du
'updatedb' qui fait appel à de nombreux accès aux données des disques.
Ce n'était pas _lors du_ updatedb, mais _après_ l'updatedb.
Quand la mémoire semble être très occupée, une grande partie est en fait en
cache
Ce n'est _pas_ ce qu'indique free : il indique effectivement près de 160 Mo
occupés en plus après l'updatedb qu'avant, _sans compter le cache_.
En l'occurence, /proc/slabinfo indiquerait probablement que c'est quand même
du cache, mais ça n'avait rien d'évident, et ça mériterait par ailleurs un
bug-report aux auteurs de free.
** free.post-run.2.log (après updatedb de mes 2 parititions NTFS)
-/+ buffers/cache: 186944 199888
On constate rien d'anormal.
Si, tu lis mal.
en particulier ici lors du 'updatedb' qui fait appel à de nombreux accès aux données des disques.
Ce n'était pas _lors du_ updatedb, mais _après_ l'updatedb.
Quand la mémoire semble être très occupée, une grande partie est en fait en cache
Ce n'est _pas_ ce qu'indique free : il indique effectivement près de 160 Mo occupés en plus après l'updatedb qu'avant, _sans compter le cache_.
En l'occurence, /proc/slabinfo indiquerait probablement que c'est quand même du cache, mais ça n'avait rien d'évident, et ça mériterait par ailleurs un bug-report aux auteurs de free.
François-Denis Gonthier
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de mémoire.
Mémoire cache. Et je vous redemande en quoi cela est gênant que la mémoire soit utilisée au maximum afin d'accélérer généralement certaines taches, sachant que dès qu'une application qui nécessiterait de la mémoire, de la mémoire serait alors libérée pour cette application. Si vous aviez lu les nombreux messages que je vous avais donné au sujet de la mémoire, vous auriez vu que c'est expliqué x fois, en long et en large.
Je n'ai pas de chiffre précis à te dire, car je n'ai pas songé à sauvegarder la sortie de free, mais je sais que cache tendait vers 0 lorsque mon système à été mis à terre hier après-midi. La mémoire était totallement occupée et le système swappais sans bon sens. Peut-être même que je suis arrivé au bout de mon swap, mais je n'étais pas là quand ma copine a du le redémarrer.
Les données montré ici ont été fait en runlevel 1, donc j'imagine qu'il y avait suffisament de mémoire au total pour accomplir cette tâche.
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de
mémoire.
Mémoire cache. Et je vous redemande en quoi cela est gênant que la mémoire
soit utilisée au maximum afin d'accélérer généralement certaines taches,
sachant que dès qu'une application qui nécessiterait de la mémoire, de la
mémoire serait alors libérée pour cette application.
Si vous aviez lu les nombreux messages que je vous avais donné au sujet de
la mémoire, vous auriez vu que c'est expliqué x fois, en long et en large.
Je n'ai pas de chiffre précis à te dire, car je n'ai pas songé à sauvegarder
la sortie de free, mais je sais que cache tendait vers 0 lorsque mon
système à été mis à terre hier après-midi. La mémoire était totallement
occupée et le système swappais sans bon sens. Peut-être même que je suis
arrivé au bout de mon swap, mais je n'étais pas là quand ma copine a du le
redémarrer.
Les données montré ici ont été fait en runlevel 1, donc j'imagine qu'il y
avait suffisament de mémoire au total pour accomplir cette tâche.
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de mémoire.
Mémoire cache. Et je vous redemande en quoi cela est gênant que la mémoire soit utilisée au maximum afin d'accélérer généralement certaines taches, sachant que dès qu'une application qui nécessiterait de la mémoire, de la mémoire serait alors libérée pour cette application. Si vous aviez lu les nombreux messages que je vous avais donné au sujet de la mémoire, vous auriez vu que c'est expliqué x fois, en long et en large.
Je n'ai pas de chiffre précis à te dire, car je n'ai pas songé à sauvegarder la sortie de free, mais je sais que cache tendait vers 0 lorsque mon système à été mis à terre hier après-midi. La mémoire était totallement occupée et le système swappais sans bon sens. Peut-être même que je suis arrivé au bout de mon swap, mais je n'étais pas là quand ma copine a du le redémarrer.
Les données montré ici ont été fait en runlevel 1, donc j'imagine qu'il y avait suffisament de mémoire au total pour accomplir cette tâche.
François-Denis Gonthier
Sebastien Kirche wrote:
Est-ce que l'accès DMA est activé (on ne sait jamais :) sur le disque qui contient cette partition NTFS ?
Et de fait, l'examen de /proc/slabinfo permet de regarder comment le noyau dépense cette mémoire. En l'occurence, chez moi, les deux gros consommateurs sont ext2_inode_cache (128 Mo) et dentry_cache (50 Mo). D'après leur nom, il s'agit bien de cache, d'un côté d'inodes pour de l'ext2 et de l'autre d'entrées de répertoire. En tant que cache, ça va probablement se libérer s'il y a de la demande autre, mais probablement avec moins de priorité de que des caches de données.
Merci!
Encore ce matin, je me suis réveillé avec une bonne quantité de mémoire allouée au slab du fait de updatedb à 6h25:
ext3_inode_cache 215193 240435 448 9 ...
Atop rapporte 146mb de slab, et c'est en diminution. Je vais essayer d'observer si ce chiffre diminue au cour de la journée.
Et de fait, l'examen de /proc/slabinfo permet de regarder comment le noyau
dépense cette mémoire. En l'occurence, chez moi, les deux gros
consommateurs sont ext2_inode_cache (128 Mo) et dentry_cache (50 Mo).
D'après leur nom, il s'agit bien de cache, d'un côté d'inodes pour de
l'ext2 et de l'autre d'entrées de répertoire. En tant que cache, ça va
probablement se libérer s'il y a de la demande autre, mais probablement
avec moins de priorité de que des caches de données.
Merci!
Encore ce matin, je me suis réveillé avec une bonne quantité de mémoire
allouée au slab du fait de updatedb à 6h25:
ext3_inode_cache 215193 240435 448 9 ...
Atop rapporte 146mb de slab, et c'est en diminution. Je vais essayer
d'observer si ce chiffre diminue au cour de la journée.
Et de fait, l'examen de /proc/slabinfo permet de regarder comment le noyau dépense cette mémoire. En l'occurence, chez moi, les deux gros consommateurs sont ext2_inode_cache (128 Mo) et dentry_cache (50 Mo). D'après leur nom, il s'agit bien de cache, d'un côté d'inodes pour de l'ext2 et de l'autre d'entrées de répertoire. En tant que cache, ça va probablement se libérer s'il y a de la demande autre, mais probablement avec moins de priorité de que des caches de données.
Merci!
Encore ce matin, je me suis réveillé avec une bonne quantité de mémoire allouée au slab du fait de updatedb à 6h25:
ext3_inode_cache 215193 240435 448 9 ...
Atop rapporte 146mb de slab, et c'est en diminution. Je vais essayer d'observer si ce chiffre diminue au cour de la journée.
Alain Labarthe
Le 16-09-2004, François-Denis Gonthier écrivait:
Sebastien Kirche wrote:
Est-ce que l'accès DMA est activé (on ne sait jamais :) sur le disque qui contient cette partition NTFS ?
