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.
Dans le message <news:nm22d.5787$, *François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bonjour tout le monde,
Bonsoir,
[« problème » supposé de mémoire]
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.
Dans le message <news:nm22d.5787$lb5.778870@news20.bellglobal.com>,
*François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bonjour tout le monde,
Bonsoir,
[« problème » supposé de mémoire]
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.
Dans le message <news:nm22d.5787$, *François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bonjour tout le monde,
Bonsoir,
[« problème » supposé de mémoire]
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.
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas l'habitude de poser une question quelque part sans avoir la certitude que j'ai réellement un problème.
La mémoire libre rapportée par gnome-system-monitor est bel & bien correcte puisque lorsqu'il dit qu'il y 20-30 mb de mémoire libre (alors que rien n'est chargé), je n'ai pas besoin de lancer beaucoup d'applications pour que le système se mette à swapper en débile. Ce n'est pas normale qu'un PC qui ne fou rien durant la nuit coule de la mémoire ainsi. Même une tâche planifié ne devrait pas laisser 200mb de mémoire occupé durant la nuit.
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu compte qu'il ne fallait surtout pas laisser updatedb indexer une partition NTFS sous peine de justement causer le problème que j'ai décrit.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu de updatedb...
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas
l'habitude de poser une question quelque part sans avoir la certitude que
j'ai réellement un problème.
La mémoire libre rapportée par gnome-system-monitor est bel & bien correcte
puisque lorsqu'il dit qu'il y 20-30 mb de mémoire libre (alors que rien
n'est chargé), je n'ai pas besoin de lancer beaucoup d'applications pour
que le système se mette à swapper en débile. Ce n'est pas normale qu'un PC
qui ne fou rien durant la nuit coule de la mémoire ainsi. Même une tâche
planifié ne devrait pas laisser 200mb de mémoire occupé durant la nuit.
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu
compte qu'il ne fallait surtout pas laisser updatedb indexer une partition
NTFS sous peine de justement causer le problème que j'ai décrit.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu de
updatedb...
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas l'habitude de poser une question quelque part sans avoir la certitude que j'ai réellement un problème.
La mémoire libre rapportée par gnome-system-monitor est bel & bien correcte puisque lorsqu'il dit qu'il y 20-30 mb de mémoire libre (alors que rien n'est chargé), je n'ai pas besoin de lancer beaucoup d'applications pour que le système se mette à swapper en débile. Ce n'est pas normale qu'un PC qui ne fou rien durant la nuit coule de la mémoire ainsi. Même une tâche planifié ne devrait pas laisser 200mb de mémoire occupé durant la nuit.
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu compte qu'il ne fallait surtout pas laisser updatedb indexer une partition NTFS sous peine de justement causer le problème que j'ai décrit.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu de updatedb...
F-D
TiChou
Dans le message <news:Dp32d.15548$, *François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas
l'habitude de poser une question quelque part sans avoir la certitude que j'ai réellement un problème.
Avez-vous lu les nombreux messages concernant la mémoire donné par mon lien ? J'en doute. Sinon vous nous auriez rapporté quelque chose du genre :
« J'ai un sérieux problème de mémoire, car après avoir effectué quelques recherches sur le fonctionnement de la mémoire sous Linux et en avoir compris l'essentiel, je constate que la commande 'free' m'affiche que j'ai 100% de la mémoire occupée mais quasiment rien en cache, et l'utilisation du swap commence à se faire ressentir ! »
Seulement il semble que ça ne soit pas du tout le cas, n'est-ce pas ? Que vous affiche le champ 'cached' de la commande 'free' ?
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu compte qu'il ne fallait surtout pas laisser updatedb indexer une partition NTFS sous peine de justement causer le problème que j'ai décrit.
Je ne vois pas en quoi indexer une partition NTFS causerait plus de cache qu'une partition d'un autre type, mais passons... Juste pour dire que vous avez la solution à votre sois disant problème.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu de updatedb...
Ça n'est pas un fait connu à ma connaissance.
-- TiChou
Dans le message <news:Dp32d.15548$0h7.1222602@news20.bellglobal.com>,
*François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas
l'habitude de poser une question quelque part sans avoir la certitude que
j'ai réellement un problème.
Avez-vous lu les nombreux messages concernant la mémoire donné par mon lien
? J'en doute. Sinon vous nous auriez rapporté quelque chose du genre :
« J'ai un sérieux problème de mémoire, car après avoir effectué quelques
recherches sur le fonctionnement de la mémoire sous Linux et en avoir
compris l'essentiel, je constate que la commande 'free' m'affiche que j'ai
100% de la mémoire occupée mais quasiment rien en cache, et l'utilisation du
swap commence à se faire ressentir ! »
Seulement il semble que ça ne soit pas du tout le cas, n'est-ce pas ? Que
vous affiche le champ 'cached' de la commande 'free' ?
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce
un problème que la mémoire soit utilisée ?
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu
compte qu'il ne fallait surtout pas laisser updatedb indexer une partition
NTFS sous peine de justement causer le problème que j'ai décrit.
Je ne vois pas en quoi indexer une partition NTFS causerait plus de cache
qu'une partition d'un autre type, mais passons... Juste pour dire que vous
avez la solution à votre sois disant problème.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu
de updatedb...
Merci d'avoir au moins pris la peine de me faire un lien mais je n'ai pas
l'habitude de poser une question quelque part sans avoir la certitude que j'ai réellement un problème.
Avez-vous lu les nombreux messages concernant la mémoire donné par mon lien ? J'en doute. Sinon vous nous auriez rapporté quelque chose du genre :
« J'ai un sérieux problème de mémoire, car après avoir effectué quelques recherches sur le fonctionnement de la mémoire sous Linux et en avoir compris l'essentiel, je constate que la commande 'free' m'affiche que j'ai 100% de la mémoire occupée mais quasiment rien en cache, et l'utilisation du swap commence à se faire ressentir ! »
Seulement il semble que ça ne soit pas du tout le cas, n'est-ce pas ? Que vous affiche le champ 'cached' de la commande 'free' ?
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
J'ai cependant raffiner ma recherche cette après-midi et je me suis rendu compte qu'il ne fallait surtout pas laisser updatedb indexer une partition NTFS sous peine de justement causer le problème que j'ai décrit.
Je ne vois pas en quoi indexer une partition NTFS causerait plus de cache qu'une partition d'un autre type, mais passons... Juste pour dire que vous avez la solution à votre sois disant problème.
Si c'est un fait connu, je ne comprends pas pourquoi NTFS n'est pas exclu de updatedb...
Ça n'est pas un fait connu à ma connaissance.
-- TiChou
François-Denis Gonthier
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas posté ce 2ème message.
Je refais l'expérience sur mon système en runlevel 1 et je te reviens avec des données + précises.
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas posté
ce 2ème message.
Je refais l'expérience sur mon système en runlevel 1 et je te reviens avec
des données + précises.
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de mémoire.
François-Denis Gonthier wrote:
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas posté
ce 2ème message.
Je refais l'expérience sur mon système en runlevel 1 et je te reviens avec
des données + précises.
Voici, comme promis, les données de l'expérience:
** free.pre-run.log (dès l'arrivée en runlevel 1):
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette
après-midi, j'ai rendu mon système carrément inutilisable. Même après la
fin de l'exécution, le système ne répondait plus aux connexions SSH et a
requis un redémarrage.
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de
mémoire.
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Je ne m'explique pas que updatedb sur NTFS occupe une telle quantité de mémoire.
Sebastien Kirche
Le 16 sep 2004, François-Denis Gonthier s'est exprimé ainsi :
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Est-ce que l'accès DMA est activé (on ne sait jamais :) sur le disque qui contient cette partition NTFS ?
Qu'indique hdparm -d (ou -i) sur ce device ?
Sébastien Kirche
Le 16 sep 2004, François-Denis Gonthier s'est exprimé ainsi :
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette
après-midi, j'ai rendu mon système carrément inutilisable. Même après la
fin de l'exécution, le système ne répondait plus aux connexions SSH et a
requis un redémarrage.
Est-ce que l'accès DMA est activé (on ne sait jamais :) sur le disque qui
contient cette partition NTFS ?
Le 16 sep 2004, François-Denis Gonthier s'est exprimé ainsi :
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Est-ce que l'accès DMA est activé (on ne sait jamais :) sur le disque qui contient cette partition NTFS ?
Qu'indique hdparm -d (ou -i) sur ce device ?
Sébastien Kirche
gUI
Voici, comme promis, les données de l'expérience:
juste pour rappeler pour les feneant comme moi (-: que 'free' accepte l'option -m pour ne parler qu'en Mo (ca evite de compter les numeros)
par contre (et c'est dommage) il n'accepte pas '-h' (pour human) qui "humanise" les donnes en rajoutant des 'ko' ou 'Mo' ou meme 'Go' pour rendre plus lisible ('ls -lh' ou 'df -h' ou 'du -h' pour comprend ce que je dis (((-; )
gUI
Voici, comme promis, les données de l'expérience:
juste pour rappeler pour les feneant comme moi (-: que 'free' accepte
l'option -m pour ne parler qu'en Mo (ca evite de compter les numeros)
par contre (et c'est dommage) il n'accepte pas '-h' (pour human) qui
"humanise" les donnes en rajoutant des 'ko' ou 'Mo' ou meme 'Go' pour
rendre plus lisible ('ls -lh' ou 'df -h' ou 'du -h' pour comprend ce que
je dis (((-; )
juste pour rappeler pour les feneant comme moi (-: que 'free' accepte l'option -m pour ne parler qu'en Mo (ca evite de compter les numeros)
par contre (et c'est dommage) il n'accepte pas '-h' (pour human) qui "humanise" les donnes en rajoutant des 'ko' ou 'Mo' ou meme 'Go' pour rendre plus lisible ('ls -lh' ou 'df -h' ou 'du -h' pour comprend ce que je dis (((-; )
gUI
Nicolas George
"TiChou" wrote in message :
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
Héhé, cette fois-ci, c'est toi qui t'emportes sans raison, car c'est bien, plus ou moins ce qu'il a dit : « Avec le programme "atop", j'ai obversé que c'est la mémoire "slab" qui occupait une grande partie de ma mémoire [...] 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. »
Il ne parle pas de swap, c'est vrai, peut-être parce qu'il a assez de mémoire pour que même avec 200 Mo en « slab » ça n'ait pas besoin de taper dedans, mais ce n'est pas une raison, si elle est anormale, pour la laisser se poursuivre.
À mon souvenir, il n'a pas été question récemment de cet aspect de la mémoire, ce « slab », et Google est d'accord avec moi (recherche de « slab memoire » sur fcol* (si on ne précise pas memoire, on tombe sur des posts parlant d'un logiciel de musique nommé Slab) : le présent thread, et deux threads pralent du fichier mm/slab.c des sources du noyau mais ne répondent pas à la question.
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
C'est un problème en ce qu'elle pourrait peut-être être mieux utilisée, à faire du cache-disque, par exemple.
En l'occurence, j'ai un peu cherché dans la doc du noyau, voici ce qu'on trouve dans filesystems/proc.txt :
Slab: in-kernel data structures cache
slabinfo Slab pool info
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.
"TiChou" wrote in message <polom.20040916010053@florizarre.tichou.org>:
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce
un problème que la mémoire soit utilisée ?
Héhé, cette fois-ci, c'est toi qui t'emportes sans raison, car c'est bien,
plus ou moins ce qu'il a dit : « Avec le programme "atop", j'ai obversé que
c'est la mémoire "slab" qui occupait une grande partie de ma mémoire [...]
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. »
Il ne parle pas de swap, c'est vrai, peut-être parce qu'il a assez de
mémoire pour que même avec 200 Mo en « slab » ça n'ait pas besoin de taper
dedans, mais ce n'est pas une raison, si elle est anormale, pour la laisser
se poursuivre.
À mon souvenir, il n'a pas été question récemment de cet aspect de la
mémoire, ce « slab », et Google est d'accord avec moi (recherche de
« slab memoire » sur fcol* (si on ne précise pas memoire, on tombe sur des
posts parlant d'un logiciel de musique nommé Slab) : le présent thread, et
deux threads pralent du fichier mm/slab.c des sources du noyau mais ne
répondent pas à la question.
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce
un problème que la mémoire soit utilisée ?
C'est un problème en ce qu'elle pourrait peut-être être mieux utilisée, à
faire du cache-disque, par exemple.
En l'occurence, j'ai un peu cherché dans la doc du noyau, voici ce qu'on
trouve dans filesystems/proc.txt :
Slab: in-kernel data structures cache
slabinfo Slab pool info
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.
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
Héhé, cette fois-ci, c'est toi qui t'emportes sans raison, car c'est bien, plus ou moins ce qu'il a dit : « Avec le programme "atop", j'ai obversé que c'est la mémoire "slab" qui occupait une grande partie de ma mémoire [...] 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. »
Il ne parle pas de swap, c'est vrai, peut-être parce qu'il a assez de mémoire pour que même avec 200 Mo en « slab » ça n'ait pas besoin de taper dedans, mais ce n'est pas une raison, si elle est anormale, pour la laisser se poursuivre.
À mon souvenir, il n'a pas été question récemment de cet aspect de la mémoire, ce « slab », et Google est d'accord avec moi (recherche de « slab memoire » sur fcol* (si on ne précise pas memoire, on tombe sur des posts parlant d'un logiciel de musique nommé Slab) : le présent thread, et deux threads pralent du fichier mm/slab.c des sources du noyau mais ne répondent pas à la question.
Sinon, vu votre certitude, je vous pose une simple question, en quoi est-ce un problème que la mémoire soit utilisée ?
C'est un problème en ce qu'elle pourrait peut-être être mieux utilisée, à faire du cache-disque, par exemple.
En l'occurence, j'ai un peu cherché dans la doc du noyau, voici ce qu'on trouve dans filesystems/proc.txt :
Slab: in-kernel data structures cache
slabinfo Slab pool info
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.
TiChou
Dans le message <news:un52d.15812$, *François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas posté ce 2ème message. Je refais l'expérience sur mon système en runlevel 1 et je te reviens avec des données + précises.
Voici, comme promis, les données de l'expérience:
** free.pre-run.log (dès l'arrivée en runlevel 1):
On constate rien d'anormal. L'utilisation de la mémoire est bien gérée. L'utilisation du swap est nulle, le système ne manque donc pas de mémoire et il l'utilise même au maximum quand il faut, en particulier ici lors du 'updatedb' qui fait appel à de nombreux accès aux données des disques. Quand la mémoire semble être très occupée, une grande partie est en fait en cache, partie de la mémoire physique servant à stocker les données lus récemment sur les disques mais libérée aussitôt en partie ou totalement dès que le système ou une application nécessite de la mémoire. On remarque bien dans vos tests que le cache est libérée immédiatement après le démontage des grosses partitions puisque ces données en cache à cet instant ne sont alors plus utiles.
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Il s'agit sûrement, comme l'a souligné Sébastien, d'un problème d'accès aux disques qui sollicitent fortement votre CPU. Voir donc du côté des options DMA. Je fais remarquer qu'une mémoire fortement occupée ne rend pas la machine inutilisable, à moins bien sûr qu'il y ait énormément d'échange avec le swap, mais les résultats de vos tests montrent que l'utilisation du swap est nulle.
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.
-- TiChou
Dans le message <news:un52d.15812$0h7.1272195@news20.bellglobal.com>,
*François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas
posté ce 2ème message. Je refais l'expérience sur mon système en runlevel
1 et je te reviens avec des données + précises.
Voici, comme promis, les données de l'expérience:
** free.pre-run.log (dès l'arrivée en runlevel 1):
On constate rien d'anormal. L'utilisation de la mémoire est bien gérée.
L'utilisation du swap est nulle, le système ne manque donc pas de mémoire et
il l'utilise même au maximum quand il faut, en particulier ici lors du
'updatedb' qui fait appel à de nombreux accès aux données des disques.
Quand la mémoire semble être très occupée, une grande partie est en fait en
cache, partie de la mémoire physique servant à stocker les données lus
récemment sur les disques mais libérée aussitôt en partie ou totalement dès
que le système ou une application nécessite de la mémoire.
On remarque bien dans vos tests que le cache est libérée immédiatement après
le démontage des grosses partitions puisque ces données en cache à cet
instant ne sont alors plus utiles.
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette
après-midi, j'ai rendu mon système carrément inutilisable. Même après la
fin de l'exécution, le système ne répondait plus aux connexions SSH et a
requis un redémarrage.
Il s'agit sûrement, comme l'a souligné Sébastien, d'un problème
d'accès aux disques qui sollicitent fortement votre CPU. Voir donc du côté
des options DMA.
Je fais remarquer qu'une mémoire fortement occupée ne rend pas la machine
inutilisable, à moins bien sûr qu'il y ait énormément d'échange avec le
swap, mais les résultats de vos tests montrent que l'utilisation du swap est
nulle.
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.
Dans le message <news:un52d.15812$, *François-Denis Gonthier* tapota sur f.c.o.l.configuration :
Bon, je m'excuse d'avoir été arrogant. Fait comme si je n'avais pas posté ce 2ème message. Je refais l'expérience sur mon système en runlevel 1 et je te reviens avec des données + précises.
Voici, comme promis, les données de l'expérience:
** free.pre-run.log (dès l'arrivée en runlevel 1):
On constate rien d'anormal. L'utilisation de la mémoire est bien gérée. L'utilisation du swap est nulle, le système ne manque donc pas de mémoire et il l'utilise même au maximum quand il faut, en particulier ici lors du 'updatedb' qui fait appel à de nombreux accès aux données des disques. Quand la mémoire semble être très occupée, une grande partie est en fait en cache, partie de la mémoire physique servant à stocker les données lus récemment sur les disques mais libérée aussitôt en partie ou totalement dès que le système ou une application nécessite de la mémoire. On remarque bien dans vos tests que le cache est libérée immédiatement après le démontage des grosses partitions puisque ces données en cache à cet instant ne sont alors plus utiles.
J'ajoute également que lors que j'ai démarré un updatedb dans KDE cette après-midi, j'ai rendu mon système carrément inutilisable. Même après la fin de l'exécution, le système ne répondait plus aux connexions SSH et a requis un redémarrage.
Il s'agit sûrement, comme l'a souligné Sébastien, d'un problème d'accès aux disques qui sollicitent fortement votre CPU. Voir donc du côté des options DMA. Je fais remarquer qu'une mémoire fortement occupée ne rend pas la machine inutilisable, à moins bien sûr qu'il y ait énormément d'échange avec le swap, mais les résultats de vos tests montrent que l'utilisation du swap est nulle.
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.
