OVH Cloud OVH Cloud

question bête: inactif-libre

16 réponses
Avatar
tino
Bonjour,
j'ai l'impression que mon g4 800 1,25 RAM swappe beaucoup plus depuis le
passage à Panther.
Quand je regarde les activités, on distingue la RAM en quatre catégories
- réservée - utilisée - inactive et libre.
Quelqu'un peut me dire ce qui est la différence entre les deux
dernières.
Est-ce que ça commence à swapper quand il n'y a plus de mémoire libre?
Merci de vos lumières
martin

--
So have I heard and do in part believe it. - Horatio

10 réponses

1 2
Avatar
Éric Lévénez
Le 22/01/04 21:53, dans <1g7zgex.1rw1dp71kaj6bqN%,
« Martin Rass » a écrit :

j'ai l'impression que mon g4 800 1,25 RAM swappe beaucoup plus depuis le
passage à Panther.
Quand je regarde les activités, on distingue la RAM en quatre catégories
- réservée - utilisée - inactive et libre.
Quelqu'un peut me dire ce qui est la différence entre les deux
dernières.
Est-ce que ça commence à swapper quand il n'y a plus de mémoire libre?


Pour ton problème l'intéressant est "est-ce que machine swappe et de
combien?". La notion de mémoire libre n'a pas beaucoup de sens (pour ce que
tu veux trouver) sur une machine avec de la mémoire virtuelle. Tu sembles en
effet confondre RAM (les barrettes mémoire) et mémoire virtuelle.

Alors la chose à voir est la deuxième valeur (après le slash) de "Flux de
pages" dans l'onglet "Mém. système" du programme Moniteur d'activité. À
chaque fois qu'une page mémoire de 4 ko est écrite dans la swap, la valeur
augmente. Si la page revient du swap (du disque) vers la RAM, cette deuxième
valeur ne changera pas. Une valeur non nulle n'indique pas que l'on est en
train de swapper, mais que l'on a swappé (depuis le boot).

La deuxième chose à voir est le maximum swappé sur disque, et cela ce voit
en regardant la taille des fichiers swap dans /var/vm. Il y a un fichier
créé de 64 Mo même si l'on ne swappe pas. Si un moment donné on swappe de
plus de 64 Mo, on aura 2 fichiers...

Swapper beaucoup mais en restant à un seul fichier de swap n'est
généralement pas très embêtant pour les perfs car cela indique que des pages
font la navette de RAM vers le disque et inversement. Si la taille des
fichiers swap augmente cela indique par contre que l'on manque vraiment de
place RAM.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
tino
Éric Lévénez wrote:

[snip]

Swapper beaucoup mais en restant à un seul fichier de swap n'est
généralement pas très embêtant pour les perfs car cela indique que des pages
font la navette de RAM vers le disque et inversement. Si la taille des
fichiers swap augmente cela indique par contre que l'on manque vraiment de
place RAM.


Merci pour ton explication claire et complète, donc si j'ai bien compris
un swapfile de 64 MO y est d'office, ce que je vois après les avoir
éléminés et redémarré.
Le changement étant qu'avant hier j'ai vu que l'espace disponible avait
baissé considérablement (environ 3 GO) et j'ai trouvé ce volume reparti
sur trois swapfiles

Je ne peux pas le dire avec certitude, mais je soupçonne l'activité de
snapzpro (capturer une vidéo de l'écran) à la base du swap (faudrait que
je vérifie une autre fois en direct)

Là je viens de transférer l'espace pour les swapfiles sur un autre
disque pour pour ne pas piocher dans le disque de démarrage,

Seulement le moniteur d'activité, va-t-il toujours indiquer le flux des
pages dans les deux sens?

sinon ça me rappelle le bon vieux temps, pour récupérer, faut redémarrer
....


--
So have I heard and do in part believe it. - Horatio

Avatar
Éric Lévénez
Le 22/01/04 22:56, dans <1g7zj0b.1pmpxz1kqz4uqN%,
« Martin Rass » a écrit :

Merci pour ton explication claire et complète, donc si j'ai bien compris
un swapfile de 64 MO y est d'office, ce que je vois après les avoir
éléminés et redémarré.


"éliminés" ? Tu veux dire que tu les effaces à la main ? Il ne faut pas. Ces
fichiers sont effacés au moment du boot. Et c'est après cela qu'un nouveau
tout beau est créé.

Le changement étant qu'avant hier j'ai vu que l'espace disponible avait
baissé considérablement (environ 3 GO) et j'ai trouvé ce volume reparti
sur trois swapfiles

Je ne peux pas le dire avec certitude, mais je soupçonne l'activité de
snapzpro (capturer une vidéo de l'écran) à la base du swap (faudrait que
je vérifie une autre fois en direct)


Pourquoi pas. Tu veux le lancer et maniper avec. En même temps, avec
Moniteur d'activité, tu sélectionnes le programme par un double-clic. Cela
affiche une fenêtre avec plein d'infos sur le programme qui est en train de
tourner. Tu regardes alors la mémoire virtuelle. Si elle augmente, augmente,
augmente, et si le Flux de pages (le deuxième nombre) augmente aussi alors
tu auras le coupable.

Là je viens de transférer l'espace pour les swapfiles sur un autre
disque pour pour ne pas piocher dans le disque de démarrage,


C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus
accélère de façon "dramatique" les accès.

Mais bon le mieux étant de ne pas swapper.

Seulement le moniteur d'activité, va-t-il toujours indiquer le flux des
pages dans les deux sens?


Le champ "Flux de pages" contient 2 nombres; le premier est pagein et le
second est pageout. Le second indique le nombre de pages écrites de la RAM
vers le swap disque. Le premier indique le nombre de pages écrites du swap
disque vers la RAM, mais aussi il indique certains accès "normaux" lors du
chargement de page de code pour les programmes. Même sans swapper, le pagein
est non nul.

Pour ce qui est de la libération des fichiers swap sur disque, le système
peut le faire. Mais il faut voir que si l'on a dans un fichier de 64 Mo une
page de 4 ko prise par programme et tout le reste par un second, même en
quittant le deuxième programme le fichier swap ne sera pas libéré car il
gardera une page occupée. Si l'on quitte le premier programme, le fichier
swap doit disparaître.

Le problème est que Mac OS X gère la swap en LIFO et donc il arrive assez
souvent que l'on ait un swap avec des trous et donc au lieu d'occuper un
seul fichier de 64 Mo le système s'est étalé sur plusieurs fichiers. Cela
revient à la fragmentation mémoire sur Mac OS 9. Pas terrible.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
tino
Martin Rass wrote:

Seulement le moniteur d'activité, va-t-il toujours indiquer le flux des
pages dans les deux sens?


Je me réponds, oui, il l'indique.

--
So have I heard and do in part believe it. - Horatio

Avatar
tino
Éric Lévénez wrote:

"éliminés" ? Tu veux dire que tu les effaces à la main ?


Je l'ai déjà fait à la main, là ce fut à l'aide de xupport

Il ne faut pas. Ces
fichiers sont effacés au moment du boot. Et c'est après cela qu'un nouveau
tout beau est créé.


Et donc ils y restent jusqu'au prochain reboot, ça peut long des fois.
Mais bon je ne l'enlèverai plus comme ça, de toute façon le finder n'en
tient pas compte avant reboot ...

Pourquoi pas. Tu veux le lancer et maniper avec. En même temps, avec
Moniteur d'activité, tu sélectionnes le programme par un double-clic. Cela
affiche une fenêtre avec plein d'infos sur le programme qui est en train de
tourner. Tu regardes alors la mémoire virtuelle. Si elle augmente, augmente,
augmente, et si le Flux de pages (le deuxième nombre) augmente aussi alors
tu auras le coupable.


Ok, je verrai la prochaine fois lorsque je constate une baisse anormale
de l'espace disque en question.

Là je viens de transférer l'espace pour les swapfiles sur un autre
disque pour pour ne pas piocher dans le disque de démarrage,


C'est bien si tu sais ce que tu fais. Un second disque avec le swap dessus
accélère de façon "dramatique" les accès.


Je l'ai fait aussi avec xupport

Mais bon le mieux étant de ne pas swapper.


Je pensais être à l'abri avec plus d'un giga de mémoire vive, mais ça
nne compte plus désormais ;-)



Merci encore


--
So have I heard and do in part believe it. - Horatio


Avatar
Éric Lévénez
Le 22/01/04 23:37, dans <1g7zlbv.fnw0vvhhqj0gN%, « Martin
Rass » a écrit :

Éric Lévénez wrote:

"éliminés" ? Tu veux dire que tu les effaces à la main ?


Je l'ai déjà fait à la main, là ce fut à l'aide de xupport


Mauvais, très mauvais. En fait tu as dû supprimé juste l'entrée dans le
répertoire et pas le fichier sur disque. Mais bon, il ne faut pas le faire.

Il ne faut pas. Ces
fichiers sont effacés au moment du boot. Et c'est après cela qu'un nouveau
tout beau est créé.


Et donc ils y restent jusqu'au prochain reboot, ça peut long des fois.
Mais bon je ne l'enlèverai plus comme ça, de toute façon le finder n'en
tient pas compte avant reboot ...


Quel rapport entre le Finder et le swap ? Le Finder n'est qu'un programme
comme les autres/

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Philippe Di Valentin
Le 23/01/04 9:32, Éric Lévénez écrivait:

Mauvais, très mauvais. En fait tu as dû supprimé juste l'entrée dans le
répertoire et pas le fichier sur disque. Mais bon, il ne faut pas le faire.
Cocktail supprime fort bien le ou les fichiers swap en 2 secondes; je

l'utilise lorsque de temps en temps j'optimise la partition Panther afin que
le fichier swap ne soit pas incorporé dans les autres fichiers et provoque
un "trou" de 64 MO au démarrage suivant.

--
• Philippe

Avatar
tino
Éric Lévénez wrote:

Quel rapport entre le Finder et le swap ?
Aucun rapport direct, mais

Le Finder n'est qu'un programme
comme les autres/ ....


... qui t'indique dans sa fenêtre (d'une manière plus ou moins fiable)
l'espace disponible sur le disque en question.
Donc un swapfile énorme va se répercuter dans cette indication.
Par contre si on le vire, même en redémarrant le finder l'espace "gagné"
ne s'y repercute pas.

D'où ma conclusion, il faut de toute façon redémarrer pour retrouver
l'espace libéré.
Bref, enlever le swapfile sans redémarrage est complètement inutile.

Et comme tu disais que le reboot élimine automatiquement les swapfiles
pour créer un seul de 64 MO, la maniière la plus simple et plus propre
pour se débarrasser d'un swap est de redémarrer.

Voilà qui m'a rappelé les OS avant X où il faut redémarrer pour
défragmenter la RAM.



--
So have I heard and do in part believe it. - Horatio

Avatar
Éric Lévénez
Le 23/01/04 10:13, dans <1g80ejg.g3k4bazbyj48N%, « Martin
Rass » a écrit :

Éric Lévénez wrote:

Quel rapport entre le Finder et le swap ?
Aucun rapport direct, mais

Le Finder n'est qu'un programme
comme les autres/ ....


... qui t'indique dans sa fenêtre (d'une manière plus ou moins fiable)


Pourquoi ne serait-ce pas fiable ?

l'espace disponible sur le disque en question.
Donc un swapfile énorme va se répercuter dans cette indication.
Par contre si on le vire, même en redémarrant le finder l'espace "gagné"
ne s'y repercute pas.


C'est normal.

Bon alors un petit cours unix.

Un fichier c'est un inode et des blocs sur disque. L'inode est une petite
zone qui comprend les metadatas comme les dates de modifications, accès...
les autorisations, les propriétaires/groupes... et la liste des blocs disque
utilisé. On y trouve aussi un nombre de liens.

Un répertoire est un fichier spécial qui contient le nom de fichiers et les
numéro d'inodes de ceux-ci.

Quand une application ouvre un fichier, le système, par le répertoire
connaît son numéro d'inode et va pouvoir accéder à travers l'inode au
fichier. Si un fichier n'a qu'un nom il aura un nombre de liens à 1. Si il a
2 noms différents (pointant vers le même inode), il aura un nombre de liens
de 2. C'est ce que l'on appelle un lien dur ou hard link. Les 2 noms
permettent d'accéder au même inode. Il n'y a pas un noms principal et un
alias, mais juste 2 noms au même niveau.

Quand on efface un fichier, le nombre de lien de l'inode est décrémenté. Si
il arrive à 0 et si plus personne n'utilise l'inode, les blocs qui composent
le fichier sont libérés.

Dans le cas de fichiers de travail, comme les fichiers swap, ils sont
ouverts par une application, (c'est un peu particulier car c'est dans le
noyau). Effacer le fichier par son nom, c'est supprimer le point d'entrée
dans le répertoire. Le nombre de lien de l'inode est décrémenté ("ls -l"
affiche cela en deuxième colonne) et passe à 0. Mais comme l'inode est
utilisé en interne, la libération des blocs n'a pas lieu. C'est seulement
quand celui qui a ouvert le fichier pour y travailler va le fermer, que le
système voit que l'inode à son nombre de lien à 0 et c'est seulement là
qu'il va libérer les blocs disque associés.

Cette astuce est très utilisée sous unix pour avoir un fichier temporaire
sur disque que l'application n'aura pas à effacer : le programme crée un
fichier et l'ouvre pour y écrire, puis le programme efface le fichier sans
avoir fermé celui-ci. Le nom du fichier est alors effacé du répertoire, mais
l'inode est toujours actif (avec un nombre de lien à 0), et le programme
peut lire/écrire dedans sans aucun problème. Et quand le programme
s'arrêtera, que ce soit proprement ou salement, le noyau détectera que
l'inode n'est plus utilisé et a un nombre de liens à 0. Et le fichier sur
disque disparaîtra comme par magie.

Avec HFS+ qui n'a pas vraiment la notion d'inodes et de liens en dur, c'est
quand même le même principe grâce à une simulation du comportement d'un file
system standard unix.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.


Avatar
Patrick Stadelmann
In article <BC36DBF0.66B27%,
Éric Lévénez wrote:

Cette astuce est très utilisée sous unix pour avoir un fichier temporaire
sur disque que l'application n'aura pas à effacer : le programme crée un
fichier et l'ouvre pour y écrire, puis le programme efface le fichier sans
avoir fermé celui-ci. Le nom du fichier est alors effacé du répertoire, mais
l'inode est toujours actif


Y a un moyen de voir que le fichier est en fait toujours là ? Sur Sun,
je me souviens que dans ce cas je voyais un .nfsXXXX à la place du
fichier, mais seulement en NFS, pas en local.

Patrick
--
Patrick Stadelmann

1 2