je viens de constater un tres curieux probleme sur mon pc (hp, quadcore,
8Go ram, 1To dd) sous Mandriva2010.2:
- apparition du message: plus de memoire disponible ou <200Mo
j'efface qques Go de video, donc 4Go de ram libre annonces par df
- qques mn plus tard, rebelote, meme reaction de ma part, à nouveau
qques Go de libre
- je me depeche de terminer l'en cours tout en etant interrompu par
qques sequences identiques
- puis je cherche ou peuvent bien etre passes ces Go qui disparaissent
je constate que j'ai un repertoire /proc de 128To donné par les
propriétés de la fenetre qui s'ouvre suite a un clic droit sur /proc
dans dolphin......
et dans ce repertoire je trouve un fichier kcore de 130 mille (environ)
Go!!! bien sur impossible a effacer meme en root
- je reboote apres avoir laissé le pc eteint qques minutes
resultat: j'ai maintenant 42Go de libre dur le DD dans /,
/proc et kcore ont toujours les memes valeurs ahurissantes mais une
heure plus tard, il semble que l'espace libre sur le DD ne s'evapore
plus comme avant le reboot
Est-ce que vous avez deja rencontre ce type de probleme?
Avez-vous une explication du phenomene?
Qu'en pensez-vous?
merci pour vos commentaires et bonne nuit.
--
"Le grand ennemi de la vérité n'est très souvent pas le mensonge -
délibéré, artificiel et malhonnête - mais le mythe - persistant,
persuasif et irréaliste. *Trop souvent, nous nous en tenons aux clichés
de nos ancêtres*. Nous soumettons tous les faits à un ensemble
préfabriqué d'interprétations. Nous apprécions le confort d'une opinion
sans l'inconfort de la pensée. "-John F. Kennedy
On Sun, 09 Dec 2012 23:41:13 +0100, Baton .rouge wrote:
On Sun, 09 Dec 2012 02:18:20 +0100, jean wrote:
- apparition du message: plus de memoire disponible ou <200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df
La root (/) est de combien de libre quand le message apparait ? Les log indique quelque chose ?
Et le /tmp ?
Francois Lafont
Le 09/12/2012 23:39, Nicolas George a écrit :
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne peux pas dépasser la taille de la RAM + celle de la swap ?
et que je les ai effacés du disque dur
Pour cette histoire de fichiers ouverts mais effacés, c'est ouverts du point de vue du noyau, c'est à dire qu'un processus a un file descriptor pointant sur le fichier, ce qui permet de faire des opérations en lecture et/ou écriture dessus. Le fichier est toujours sur le disque dur, exactement là où il était, la seule différence est qu'il n'apparaît plus dans aucun répertoire, et disparaîtra automatiquement dès qu'il n'y aura plus de file descriptors dessus.
ok, je vois.
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon éditeur par exemple en faisant « gedit f.txt », le contenu du fichier texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas uniquement cette copie qui est modifiée par l'éditeur sauf au moment où je clique sur "enregistrer" où la version du fichier stockée dans la RAM est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est pas comme ça que ça se passe ?
-- François Lafont
Le 09/12/2012 23:39, Nicolas George a écrit :
Francois Lafont , dans le message
<50c50db8$0$16496$426a74cc@news.free.fr>, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon
éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable
d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y
pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me
dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne
peux pas dépasser la taille de la RAM + celle de la swap ?
et que je les ai effacés
du disque dur
Pour cette histoire de fichiers ouverts mais effacés, c'est ouverts du point
de vue du noyau, c'est à dire qu'un processus a un file descriptor pointant
sur le fichier, ce qui permet de faire des opérations en lecture et/ou
écriture dessus. Le fichier est toujours sur le disque dur, exactement là où
il était, la seule différence est qu'il n'apparaît plus dans aucun
répertoire, et disparaîtra automatiquement dès qu'il n'y aura plus de file
descriptors dessus.
ok, je vois.
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon
éditeur par exemple en faisant « gedit f.txt », le contenu du fichier
texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas
uniquement cette copie qui est modifiée par l'éditeur sauf au moment où
je clique sur "enregistrer" où la version du fichier stockée dans la RAM
est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est
pas comme ça que ça se passe ?
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne peux pas dépasser la taille de la RAM + celle de la swap ?
et que je les ai effacés du disque dur
Pour cette histoire de fichiers ouverts mais effacés, c'est ouverts du point de vue du noyau, c'est à dire qu'un processus a un file descriptor pointant sur le fichier, ce qui permet de faire des opérations en lecture et/ou écriture dessus. Le fichier est toujours sur le disque dur, exactement là où il était, la seule différence est qu'il n'apparaît plus dans aucun répertoire, et disparaîtra automatiquement dès qu'il n'y aura plus de file descriptors dessus.
ok, je vois.
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon éditeur par exemple en faisant « gedit f.txt », le contenu du fichier texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas uniquement cette copie qui est modifiée par l'éditeur sauf au moment où je clique sur "enregistrer" où la version du fichier stockée dans la RAM est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est pas comme ça que ça se passe ?
-- François Lafont
jean
Le 09/12/2012 15:19, Emmanuel Florac a écrit :
Le Sun, 09 Dec 2012 02:18:20 +0100, jean a écrit:
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou<200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df - qques mn plus tard, rebelote, meme reaction de ma part, à nouveau qques Go de libre
Tu parles de df et de RAM, mais df mesure le remplissage des disques, pas
bien evidement, et puisque je parle de df, le mot ram est une erreur stupide (lire DD) due probablement au fait qu'il etait 2h du matin passé...
de la RAM. Un disque doit être considéré comme "plein" au dessus de 90% (voire 95). Donc si tu as moins de 50 Go de libre, ton disque est trop plein; premier point; ensuite tu as 4 Go de RAM, donc les fichiers temporaires et autres broutilles en mémoire peuvent représenter environ 4 Go, donc tu ne dois en aucun cas jamais laisser ton disque se remplir jusqu'à avoir moins de 4 Go de libre sous peine de problèmes.
la petite fenetre qui s'affichait pour me prevenir du probleme signalait que je n'avais plus que 200Mo de libre sur le DD et proposait d'ouvrir un gestionnaire de fichier pour liberer de l'espace. a chaque apparition, j'ai donc effacé des fichiers video non indispensables ou sauvegardes par ailleurs pour regler le probleme
- je me depeche de terminer l'en cours tout en etant interrompu par qques sequences identiques - puis je cherche ou peuvent bien etre passes ces Go qui disparaissent je constate que j'ai un repertoire /proc de 128To donné par les propriétés de la fenetre qui s'ouvre suite a un clic droit sur /proc dans dolphin......
/proc est un filesystem virtuel, et /proc/kcore représente la mémoire virtuelle de ton PC. ne touche à rien dans /proc si tu ne sais pas ce que tu fais, tu peux planter salement ta machine.
bien compris et merci pour l'explication, j'en etais resté aux valeurs pour processeur 32bits ce qui m'a desarçonné! (je suis un amateur, pas un pro de linux!) autres precisions: j'ai regardé rapidement dans les repertoires si je pouvais voir une anomalie eventuelle sur les tailles des repertoires qui aurait donné une piste pour expliquer cette disparition de 40Go sur le disque, mais en vain (avant de rebooter) j'aurais pourtant du voir quelquechose car 40Go sur une partition de 150Go, ça aurait du pouvoir se voir facilement. je travaillais sur de la saisie de textes avec kwrite et pas sur de la video, la memoire virtuelle ne devait pas etre utilisée vu la taille de la ram. la seule particularité de la journée est que j'ai a plusieurs reprises rebooté sans coupure de l'alim pour switcher entre linux et windows vista, je signale cela a tout hasard. si le phenomene se reproduit, je ferai un enregistrement de tree sur la racine avec taille des fichiers avant et apres reboot, la comparaison des 2 fichiers devrait m'en apprendre plus.... et merci a tous ceux qui se sont penchés sur le probleme
Le 09/12/2012 15:19, Emmanuel Florac a écrit :
Le Sun, 09 Dec 2012 02:18:20 +0100, jean a écrit:
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore,
8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de
memoire disponible ou<200Mo j'efface qques Go de video, donc 4Go de ram
libre annonces par df - qques mn plus tard, rebelote, meme reaction de
ma part, à nouveau qques Go de libre
Tu parles de df et de RAM, mais df mesure le remplissage des disques, pas
bien evidement, et puisque je parle de df, le mot ram est une erreur
stupide (lire DD) due probablement au fait qu'il etait 2h du matin passé...
de la RAM. Un disque doit être considéré comme "plein" au dessus de 90%
(voire 95). Donc si tu as moins de 50 Go de libre, ton disque est trop
plein; premier point; ensuite tu as 4 Go de RAM, donc les fichiers
temporaires et autres broutilles en mémoire peuvent représenter environ 4
Go, donc tu ne dois en aucun cas jamais laisser ton disque se remplir
jusqu'à avoir moins de 4 Go de libre sous peine de problèmes.
la petite fenetre qui s'affichait pour me prevenir du probleme signalait
que je n'avais plus que 200Mo de libre sur le DD et proposait d'ouvrir
un gestionnaire de fichier pour liberer de l'espace.
a chaque apparition, j'ai donc effacé des fichiers video non
indispensables ou sauvegardes par ailleurs pour regler le probleme
- je me depeche de terminer l'en cours tout en etant interrompu par
qques sequences identiques
- puis je cherche ou peuvent bien etre passes ces Go qui disparaissent
je constate que j'ai un repertoire /proc de 128To donné par les
propriétés de la fenetre qui s'ouvre suite a un clic droit sur /proc
dans dolphin......
/proc est un filesystem virtuel, et /proc/kcore représente la mémoire
virtuelle de ton PC. ne touche à rien dans /proc si tu ne sais pas ce que
tu fais, tu peux planter salement ta machine.
bien compris et merci pour l'explication, j'en etais resté aux valeurs
pour processeur 32bits ce qui m'a desarçonné! (je suis un amateur, pas
un pro de linux!)
autres precisions: j'ai regardé rapidement dans les repertoires si je
pouvais voir une anomalie eventuelle sur les tailles des repertoires qui
aurait donné une piste pour expliquer cette disparition de 40Go sur le
disque, mais en vain (avant de rebooter) j'aurais pourtant du voir
quelquechose car 40Go sur une partition de 150Go, ça aurait du pouvoir
se voir facilement.
je travaillais sur de la saisie de textes avec kwrite et pas sur de la
video, la memoire virtuelle ne devait pas etre utilisée vu la taille de
la ram.
la seule particularité de la journée est que j'ai a plusieurs reprises
rebooté sans coupure de l'alim pour switcher entre linux et windows
vista, je signale cela a tout hasard.
si le phenomene se reproduit, je ferai un enregistrement de tree sur la
racine avec taille des fichiers avant et apres reboot, la comparaison
des 2 fichiers devrait m'en apprendre plus....
et merci a tous ceux qui se sont penchés sur le probleme
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou<200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df - qques mn plus tard, rebelote, meme reaction de ma part, à nouveau qques Go de libre
Tu parles de df et de RAM, mais df mesure le remplissage des disques, pas
bien evidement, et puisque je parle de df, le mot ram est une erreur stupide (lire DD) due probablement au fait qu'il etait 2h du matin passé...
de la RAM. Un disque doit être considéré comme "plein" au dessus de 90% (voire 95). Donc si tu as moins de 50 Go de libre, ton disque est trop plein; premier point; ensuite tu as 4 Go de RAM, donc les fichiers temporaires et autres broutilles en mémoire peuvent représenter environ 4 Go, donc tu ne dois en aucun cas jamais laisser ton disque se remplir jusqu'à avoir moins de 4 Go de libre sous peine de problèmes.
la petite fenetre qui s'affichait pour me prevenir du probleme signalait que je n'avais plus que 200Mo de libre sur le DD et proposait d'ouvrir un gestionnaire de fichier pour liberer de l'espace. a chaque apparition, j'ai donc effacé des fichiers video non indispensables ou sauvegardes par ailleurs pour regler le probleme
- je me depeche de terminer l'en cours tout en etant interrompu par qques sequences identiques - puis je cherche ou peuvent bien etre passes ces Go qui disparaissent je constate que j'ai un repertoire /proc de 128To donné par les propriétés de la fenetre qui s'ouvre suite a un clic droit sur /proc dans dolphin......
/proc est un filesystem virtuel, et /proc/kcore représente la mémoire virtuelle de ton PC. ne touche à rien dans /proc si tu ne sais pas ce que tu fais, tu peux planter salement ta machine.
bien compris et merci pour l'explication, j'en etais resté aux valeurs pour processeur 32bits ce qui m'a desarçonné! (je suis un amateur, pas un pro de linux!) autres precisions: j'ai regardé rapidement dans les repertoires si je pouvais voir une anomalie eventuelle sur les tailles des repertoires qui aurait donné une piste pour expliquer cette disparition de 40Go sur le disque, mais en vain (avant de rebooter) j'aurais pourtant du voir quelquechose car 40Go sur une partition de 150Go, ça aurait du pouvoir se voir facilement. je travaillais sur de la saisie de textes avec kwrite et pas sur de la video, la memoire virtuelle ne devait pas etre utilisée vu la taille de la ram. la seule particularité de la journée est que j'ai a plusieurs reprises rebooté sans coupure de l'alim pour switcher entre linux et windows vista, je signale cela a tout hasard. si le phenomene se reproduit, je ferai un enregistrement de tree sur la racine avec taille des fichiers avant et apres reboot, la comparaison des 2 fichiers devrait m'en apprendre plus.... et merci a tous ceux qui se sont penchés sur le probleme
Th.A.C
Le 10/12/2012 00:22, Francois Lafont a écrit :> Le 09/12/2012 23:39, Nicolas George a écrit :
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte
s'il n'y
pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne peux pas dépasser la taille de la RAM + celle de la swap ?
La mémoire virtuelle, c'est de la mémoire qui n'est pas de la vraie ram (comme la ddr,ddr2,ddr3,...), c'est donc dans ton cas le swap.
Elle n'existe donc pas physiquement comme la ram, mais virtuellement,
c'est à dire que le systeme peut simuler (faire comme si elle existait) de la ram en 'swappant'. En gros, si le noyau a besoin de vraie ram, il copie une partie de sa vraie ram dans le fichier de swap et peut donc utiliser cette zone mémoire pour autre chose. S'il a besoin à nouveau de ce qu'il a stocké dans le swap, il fait le contraire (je simplifie beaucoup)?
Tu ne peux donc pas avoir plus de mémoire que ram + swap.
Ceci dit, tu peux augmenter le swap 'à chaud' si tu te trouves à cours de mémoire. Soit avec une partition/espace_disque non utilisé, soit en créant un fichier que tu utiliseras comme swap supplémentaire
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon éditeur par exemple en faisant « gedit f.txt », le contenu du fichier texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas uniquement cette copie qui est modifiée par l'éditeur sauf au moment où je clique sur "enregistrer" où la version du fichier stockée dans la RAM est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est pas comme ça que ça se passe ?
ca dépend de la facon dont a été fait le programme. Il peut par exemple travailler par bloc s'il n'y a pas assez de ram, et utiliser un fichier temporaire sur le disque. Un peu comme le principe du swap avec les inconvénients (lenteur par exemple quand tu changes de zone(bloc) dans ton texte.
Le 10/12/2012 00:22, Francois Lafont a écrit :> Le 09/12/2012 23:39,
Nicolas George a écrit :
Francois Lafont , dans le message
<50c50db8$0$16496$426a74cc@news.free.fr>, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon
éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable
d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte
s'il n'y
pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me
dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne
peux pas dépasser la taille de la RAM + celle de la swap ?
La mémoire virtuelle, c'est de la mémoire qui n'est pas de la vraie ram
(comme la ddr,ddr2,ddr3,...), c'est donc dans ton cas le swap.
Elle n'existe donc pas physiquement comme la ram, mais virtuellement,
c'est à dire que le systeme peut simuler (faire comme si elle existait)
de la ram en 'swappant'.
En gros, si le noyau a besoin de vraie ram, il copie une partie de sa
vraie ram dans le fichier de swap et peut donc utiliser cette zone
mémoire pour autre chose.
S'il a besoin à nouveau de ce qu'il a stocké dans le swap, il fait le
contraire (je simplifie beaucoup)?
Tu ne peux donc pas avoir plus de mémoire que ram + swap.
Ceci dit, tu peux augmenter le swap 'à chaud' si tu te trouves à cours
de mémoire. Soit avec une partition/espace_disque non utilisé, soit en
créant un fichier que tu utiliseras comme swap supplémentaire
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon
éditeur par exemple en faisant « gedit f.txt », le contenu du fichier
texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas
uniquement cette copie qui est modifiée par l'éditeur sauf au moment où
je clique sur "enregistrer" où la version du fichier stockée dans la RAM
est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est
pas comme ça que ça se passe ?
ca dépend de la facon dont a été fait le programme.
Il peut par exemple travailler par bloc s'il n'y a pas assez de ram, et
utiliser un fichier temporaire sur le disque.
Un peu comme le principe du swap avec les inconvénients (lenteur par
exemple quand tu changes de zone(bloc) dans ton texte.
Le 10/12/2012 00:22, Francois Lafont a écrit :> Le 09/12/2012 23:39, Nicolas George a écrit :
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte
s'il n'y
pas 40 Go de mémoire virtuelle disponible.
Ah, je crois que ce concept de mémoire virtuelle et le reste aussi me dépasse un peu. Mais est-ce correct dire que la mémoire virtuelle ne peux pas dépasser la taille de la RAM + celle de la swap ?
La mémoire virtuelle, c'est de la mémoire qui n'est pas de la vraie ram (comme la ddr,ddr2,ddr3,...), c'est donc dans ton cas le swap.
Elle n'existe donc pas physiquement comme la ram, mais virtuellement,
c'est à dire que le systeme peut simuler (faire comme si elle existait) de la ram en 'swappant'. En gros, si le noyau a besoin de vraie ram, il copie une partie de sa vraie ram dans le fichier de swap et peut donc utiliser cette zone mémoire pour autre chose. S'il a besoin à nouveau de ce qu'il a stocké dans le swap, il fait le contraire (je simplifie beaucoup)?
Tu ne peux donc pas avoir plus de mémoire que ram + swap.
Ceci dit, tu peux augmenter le swap 'à chaud' si tu te trouves à cours de mémoire. Soit avec une partition/espace_disque non utilisé, soit en créant un fichier que tu utiliseras comme swap supplémentaire
Mais quand j'ouvre (au sens naïf du terme) un fichier texte avec mon éditeur par exemple en faisant « gedit f.txt », le contenu du fichier texte n'est-il pas entièrement copié dans la RAM et n'est-ce pas uniquement cette copie qui est modifiée par l'éditeur sauf au moment où je clique sur "enregistrer" où la version du fichier stockée dans la RAM est recopiée sur le disque dur à la place du fichier f.txt ? Ce n'est pas comme ça que ça se passe ?
ca dépend de la facon dont a été fait le programme. Il peut par exemple travailler par bloc s'il n'y a pas assez de ram, et utiliser un fichier temporaire sur le disque. Un peu comme le principe du swap avec les inconvénients (lenteur par exemple quand tu changes de zone(bloc) dans ton texte.
Marc Boyer
Le 09-12-2012, Nicolas George <nicolas$ a écrit :
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y pas 40 Go de mémoire virtuelle disponible.
Pourtant, j'ai fais ça avec emacs sur dans le passé. A l'époque, à ma grande suprise, vi n'y arrivait pas d'ailleurs. Peut-être juste un pb d'option ou de config. J'avais pas vraiment creusé.
Un éditeur de texte n'a pas besoin de charger tout le fichier pour travailler dessus. Il peut tout à fait ouvrir bloc par bloc.
OK, tous les éditeurs ne sont pas forcément bien programmé aussi.
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 09-12-2012, Nicolas George <nicolas$george@salle-s.org> a écrit :
Francois Lafont , dans le message
<50c50db8$0$16496$426a74cc@news.free.fr>, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon
éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable
d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y
pas 40 Go de mémoire virtuelle disponible.
Pourtant, j'ai fais ça avec emacs sur dans le passé. A l'époque,
à ma grande suprise, vi n'y arrivait pas d'ailleurs. Peut-être juste
un pb d'option ou de config. J'avais pas vraiment creusé.
Un éditeur de texte n'a pas besoin de charger tout le fichier
pour travailler dessus. Il peut tout à fait ouvrir bloc par bloc.
OK, tous les éditeurs ne sont pas forcément bien programmé aussi.
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
Francois Lafont , dans le message <50c50db8$0$16496$, a écrit :
Pour reprendre l'exemple d'Emmanuel, imaginons que j'ai ouvert avec mon éditeur l'équivalent de 40 Go de fichiers texte
Il n'est pas clair qu'un éditeur de texte quelconque soit capable d'« ouvrir », au sens charger et donner à éditer, 40 Go de texte s'il n'y pas 40 Go de mémoire virtuelle disponible.
Pourtant, j'ai fais ça avec emacs sur dans le passé. A l'époque, à ma grande suprise, vi n'y arrivait pas d'ailleurs. Peut-être juste un pb d'option ou de config. J'avais pas vraiment creusé.
Un éditeur de texte n'a pas besoin de charger tout le fichier pour travailler dessus. Il peut tout à fait ouvrir bloc par bloc.
OK, tous les éditeurs ne sont pas forcément bien programmé aussi.
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Marc Boyer
Le 09-12-2012, jean a écrit :
bonsoir,
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou <200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
Est-ce que vous avez deja rencontre ce type de probleme? Avez-vous une explication du phenomene?
1) Comme dit par ailleurs, /proc ne sert pas à stocker des "vrais" fichiers, donc, inutile d'aller regarder par là. 2) tu peux essayer de trouver où se situent ces fichiers qui prennent tant de place.
Tu lances une commande du genre du -k --max-depth=2 / > ${HOME}/du-ok lorsque ton système va bien. Puis lorsque ça dit manquer de place du -k --max-depth=2 / > ${HOME}/du-full et ensuite, tu compares les deux fichiers (avec tkdiff par exemple, ou avec un gestionnaire de feuilles de calcul, tu fais des % d'augmentation).
Qu'en pensez-vous?
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 09-12-2012, jean <jean@adinvalid.com> a écrit :
bonsoir,
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore,
8Go ram, 1To dd) sous Mandriva2010.2:
- apparition du message: plus de memoire disponible ou <200Mo
j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
Est-ce que vous avez deja rencontre ce type de probleme?
Avez-vous une explication du phenomene?
1) Comme dit par ailleurs, /proc ne sert pas à stocker des
"vrais" fichiers, donc, inutile d'aller regarder par là.
2) tu peux essayer de trouver où se situent ces fichiers
qui prennent tant de place.
Tu lances une commande du genre
du -k --max-depth=2 / > ${HOME}/du-ok
lorsque ton système va bien. Puis lorsque ça dit manquer
de place
du -k --max-depth=2 / > ${HOME}/du-full
et ensuite, tu compares les deux fichiers (avec tkdiff par
exemple, ou avec un gestionnaire de feuilles de calcul,
tu fais des % d'augmentation).
Qu'en pensez-vous?
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou <200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
Est-ce que vous avez deja rencontre ce type de probleme? Avez-vous une explication du phenomene?
1) Comme dit par ailleurs, /proc ne sert pas à stocker des "vrais" fichiers, donc, inutile d'aller regarder par là. 2) tu peux essayer de trouver où se situent ces fichiers qui prennent tant de place.
Tu lances une commande du genre du -k --max-depth=2 / > ${HOME}/du-ok lorsque ton système va bien. Puis lorsque ça dit manquer de place du -k --max-depth=2 / > ${HOME}/du-full et ensuite, tu compares les deux fichiers (avec tkdiff par exemple, ou avec un gestionnaire de feuilles de calcul, tu fais des % d'augmentation).
Qu'en pensez-vous?
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Sergio
Le Mon, 10 Dec 2012 08:03:38 +0000, Marc Boyer a écrit :
Tu lances une commande du genre du -k --max-depth=2 / > ${HOME}/du-ok lorsque ton système va bien. Puis lorsque ça dit manquer de place du -k --max-depth=2 / > ${HOME}/du-full
du -x / >~/du-ok
Qui permet (option -x) de pas tenir compte des autres partitions (dont / proc et /dev).
Le Mon, 10 Dec 2012 08:03:38 +0000, Marc Boyer a écrit :
Tu lances une commande du genre
du -k --max-depth=2 / > ${HOME}/du-ok
lorsque ton système va bien. Puis lorsque ça dit manquer de place
du -k --max-depth=2 / > ${HOME}/du-full
du -x / >~/du-ok
Qui permet (option -x) de pas tenir compte des autres partitions (dont /
proc et /dev).
Le Mon, 10 Dec 2012 08:03:38 +0000, Marc Boyer a écrit :
Tu lances une commande du genre du -k --max-depth=2 / > ${HOME}/du-ok lorsque ton système va bien. Puis lorsque ça dit manquer de place du -k --max-depth=2 / > ${HOME}/du-full
du -x / >~/du-ok
Qui permet (option -x) de pas tenir compte des autres partitions (dont / proc et /dev).
Baton .rouge
On Mon, 10 Dec 2012 08:03:38 +0000 (UTC), Marc Boyer wrote:
Le 09-12-2012, jean a écrit :
bonsoir,
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou <200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
kdirstat permet d'avoir une vue graphique des blocs fichiers en fonction de la taille : http://www.novell.com/coolsolutions/img/15894-04.png
On Mon, 10 Dec 2012 08:03:38 +0000 (UTC), Marc Boyer
<Marc.Boyer@cert.onera.fr.invalid> wrote:
Le 09-12-2012, jean <jean@adinvalid.com> a écrit :
bonsoir,
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore,
8Go ram, 1To dd) sous Mandriva2010.2:
- apparition du message: plus de memoire disponible ou <200Mo
j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
kdirstat permet d'avoir une vue graphique des blocs fichiers en fonction
de la taille :
http://www.novell.com/coolsolutions/img/15894-04.png
On Mon, 10 Dec 2012 08:03:38 +0000 (UTC), Marc Boyer wrote:
Le 09-12-2012, jean a écrit :
bonsoir,
je viens de constater un tres curieux probleme sur mon pc (hp, quadcore, 8Go ram, 1To dd) sous Mandriva2010.2: - apparition du message: plus de memoire disponible ou <200Mo j'efface qques Go de video, donc 4Go de ram libre annonces par df
df gère l'espace disque, pas la ram
kdirstat permet d'avoir une vue graphique des blocs fichiers en fonction de la taille : http://www.novell.com/coolsolutions/img/15894-04.png
jp willm
Le 09/12/2012 17:15, Nicolas George a écrit :
Euh, oui, évidemment. Je ne vois pas à quoi on peut s'attendre d'autre : dans la mémoire, il y a des tables de pointeurs, des données d'images, du code en langage machine, etc. Dans le lot, il va y avoir un petit peu de texte lisible, mais pas beaucoup. Tu auras la même chose en lisant, par exemple, /bin/ls.
Ok, je suppose donc que la taille de /dev/mem peut nous indiquer la quantité de données qui ont été mémorisées.
-- http://perso.orange.fr/willms/index.html
Le 09/12/2012 17:15, Nicolas George a écrit :
Euh, oui, évidemment. Je ne vois pas à quoi on peut s'attendre d'autre :
dans la mémoire, il y a des tables de pointeurs, des données d'images, du
code en langage machine, etc. Dans le lot, il va y avoir un petit peu de
texte lisible, mais pas beaucoup. Tu auras la même chose en lisant, par
exemple, /bin/ls.
Ok, je suppose donc que la taille de /dev/mem peut nous indiquer la
quantité de données qui ont été mémorisées.
Euh, oui, évidemment. Je ne vois pas à quoi on peut s'attendre d'autre : dans la mémoire, il y a des tables de pointeurs, des données d'images, du code en langage machine, etc. Dans le lot, il va y avoir un petit peu de texte lisible, mais pas beaucoup. Tu auras la même chose en lisant, par exemple, /bin/ls.
Ok, je suppose donc que la taille de /dev/mem peut nous indiquer la quantité de données qui ont été mémorisées.
