Est-ce que vous avez remarque que panther prend plus de swap que Jaguar.
Sous Jaguar j'ai longtemps eu 256Mo de RAM et je n'ai jamais vu le swap
depasser les 400Mo. Quand je suis passe a 640Mo le swap n'a plus jamias
depasse les 1fichier (70Mo a peu pres). Sous Panther j'ai 640Mo de RAM
et le swap monte frequemment a 1Go. En plus cette nouvelle strategie
d'allouer des fichiers de plus en plus gros, je la trouve assez stupide. Ils
aurraient pu au moins la rendre optionnelle.
Pour info j'ai 256 Mo de RAM et avec 7 applications lancées mes fichiers swap font : swapfile0 : 64 Mo swapfile1 : 64 Mo swapfile2 : 128 Mo swapfile3 : 256 Mo
Ce qui nous fait 512 Mo (0,5 Go)
Par contre Moniteur d'activité affiche allègrement 3,97 Go de MV... comprenne qui pourra...
Si j'ai bien compris, quand une application se lance, elle dit au système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au début elle n'en utilisera que 100 Mo (encore par exemple) et en fonction de l'utilisation la mémoire réellement utilisé va varier. Les 1 Go seront compté en VM et les 100 Mo seront répartis entre la RAM et le Swap selon l'utilisation.
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Pour info j'ai 256 Mo de RAM et avec 7 applications lancées mes fichiers
swap font :
swapfile0 : 64 Mo
swapfile1 : 64 Mo
swapfile2 : 128 Mo
swapfile3 : 256 Mo
Ce qui nous fait 512 Mo (0,5 Go)
Par contre Moniteur d'activité affiche allègrement 3,97 Go de MV... comprenne
qui pourra...
Si j'ai bien compris, quand une application se lance, elle dit au
système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au
début elle n'en utilisera que 100 Mo (encore par exemple) et en fonction
de l'utilisation la mémoire réellement utilisé va varier. Les 1 Go
seront compté en VM et les 100 Mo seront répartis entre la RAM et le
Swap selon l'utilisation.
--
MVP Microsoft Mac
www.makiciel.com
Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire
(Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Pour info j'ai 256 Mo de RAM et avec 7 applications lancées mes fichiers swap font : swapfile0 : 64 Mo swapfile1 : 64 Mo swapfile2 : 128 Mo swapfile3 : 256 Mo
Ce qui nous fait 512 Mo (0,5 Go)
Par contre Moniteur d'activité affiche allègrement 3,97 Go de MV... comprenne qui pourra...
Si j'ai bien compris, quand une application se lance, elle dit au système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au début elle n'en utilisera que 100 Mo (encore par exemple) et en fonction de l'utilisation la mémoire réellement utilisé va varier. Les 1 Go seront compté en VM et les 100 Mo seront répartis entre la RAM et le Swap selon l'utilisation.
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Éric Lévénez
Le 25/05/04 0:23, dans <1gebecq.w2gaph1bcpcffN%, « Pascal Bezou » a écrit :
Si j'ai bien compris, quand une application se lance, elle dit au système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au début elle n'en utilisera que 100 Mo (encore par exemple)
Cette description ressemble à la gestion sur Mac OS 9 :-)
Voici, encore, une explication simplifiée.
Supposons un programme de 300 ko. Ce programme utilise divers bibliothèques partagées souvent très volumineuses (plusieurs Mo). Quand on lance le programme, il ne réserve rien (au sens Mac OS 9), mais le système sait qu'il existe, et il lui alloue virtuellement un espace de travail pour le programme et ses bibliothèques. Cet espace virtuelle fait alors typiquement plusieurs Mo. À ce stade le programme n'a pas vraiment commencé à tourner et il n'utilise pas vraiment de mémoire physique (RAM).
Et quand le programme commence son exécution, le système va copier la première page mémoire du programme (de 4 ko) du système de fichier vers la mémoire physique (RAM). Au fur et à mesure de son exécution, le système va copier de plus en plus de pages du disque vers la RAM. On voit cela dans la "pagein". Mais il arrive très souvent que le programme n'ait pas besoin de tout le code du fichier, et donc tout ce code ne sera pas recopié en mémoire physique. De la même façon les bibliothèques partagées sont souvent très grosses et un programme n'en utilise qu'une petite partie. Tout cela fait qu'en mémoire physique (RAM), il n'y a qu'un petit bout d'un programme.
En utilisant le programme "top", on voit par exemple que la RAM prise par un programme (RSIZE) est bien plus petite que la mémoire virtuelle (VSIZE).
Si le programme utilisait toutes les fonctions de son code ainsi que toutes les fonctions de toutes les bibliothèques, il y aurait à terme tout le code en mémoire physique et donc on aurait un RSIZE = VSIZE.
Si le système n'utilisait pas la mémoire virtuelle, il faudrait que tout le programme soit chargé en mémoire physique avant que l'exécution ne commence. Cela entraînerait par exemple comme limite qu'un programme ne puisse s'exécuter que si sa taille totale est inférieure à la taille de la RAM. Sur Mac OS X (et unix), ce n'est pas nécessaire : un programme peut être plus gros que la taille de la RAM.
En plus de ce système, il y a le swap, qui est indépendant de la gestion de la mémoire virtuelle. Le swap (écriture sur disque, "pageout") se déclanche quand la mémoire physique (RAM) est proche de la saturation. Les vieilles pages en RAM sont écrites dans le swap pour libérer de la RAM, cela n'empêche pas l'exécution des programmes, même si ceux-ci avaient utilisés ces pages mémoire. Mais bien sur quand un programme qui tourne en mémoire physique a besoin d'une page qui a été swappée, le système fait l'inverse en réécrivant des pages du swap vers la RAM (l'autre partie du "pagein"). Si beaucoup de programmes tournent dans peu de RAM, le système passera son temps à sortir de la RAM des pages et à en rentrée de nouvelles depuis le swap, et cela fait souvent boule de neige.
Le swap est bien, mais il ne faut pas en abuser.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 25/05/04 0:23, dans <1gebecq.w2gaph1bcpcffN%pbezou@EnTrop.makiciel.com>,
« Pascal Bezou » <pbezou@EnTrop.makiciel.com> a écrit :
Si j'ai bien compris, quand une application se lance, elle dit au
système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au
début elle n'en utilisera que 100 Mo (encore par exemple)
Cette description ressemble à la gestion sur Mac OS 9 :-)
Voici, encore, une explication simplifiée.
Supposons un programme de 300 ko. Ce programme utilise divers bibliothèques
partagées souvent très volumineuses (plusieurs Mo). Quand on lance le
programme, il ne réserve rien (au sens Mac OS 9), mais le système sait qu'il
existe, et il lui alloue virtuellement un espace de travail pour le
programme et ses bibliothèques. Cet espace virtuelle fait alors typiquement
plusieurs Mo. À ce stade le programme n'a pas vraiment commencé à tourner et
il n'utilise pas vraiment de mémoire physique (RAM).
Et quand le programme commence son exécution, le système va copier la
première page mémoire du programme (de 4 ko) du système de fichier vers la
mémoire physique (RAM). Au fur et à mesure de son exécution, le système va
copier de plus en plus de pages du disque vers la RAM. On voit cela dans la
"pagein". Mais il arrive très souvent que le programme n'ait pas besoin de
tout le code du fichier, et donc tout ce code ne sera pas recopié en mémoire
physique. De la même façon les bibliothèques partagées sont souvent très
grosses et un programme n'en utilise qu'une petite partie. Tout cela fait
qu'en mémoire physique (RAM), il n'y a qu'un petit bout d'un programme.
En utilisant le programme "top", on voit par exemple que la RAM prise par un
programme (RSIZE) est bien plus petite que la mémoire virtuelle (VSIZE).
Si le programme utilisait toutes les fonctions de son code ainsi que toutes
les fonctions de toutes les bibliothèques, il y aurait à terme tout le code
en mémoire physique et donc on aurait un RSIZE = VSIZE.
Si le système n'utilisait pas la mémoire virtuelle, il faudrait que tout le
programme soit chargé en mémoire physique avant que l'exécution ne commence.
Cela entraînerait par exemple comme limite qu'un programme ne puisse
s'exécuter que si sa taille totale est inférieure à la taille de la RAM. Sur
Mac OS X (et unix), ce n'est pas nécessaire : un programme peut être plus
gros que la taille de la RAM.
En plus de ce système, il y a le swap, qui est indépendant de la gestion de
la mémoire virtuelle. Le swap (écriture sur disque, "pageout") se déclanche
quand la mémoire physique (RAM) est proche de la saturation. Les vieilles
pages en RAM sont écrites dans le swap pour libérer de la RAM, cela
n'empêche pas l'exécution des programmes, même si ceux-ci avaient utilisés
ces pages mémoire. Mais bien sur quand un programme qui tourne en mémoire
physique a besoin d'une page qui a été swappée, le système fait l'inverse en
réécrivant des pages du swap vers la RAM (l'autre partie du "pagein"). Si
beaucoup de programmes tournent dans peu de RAM, le système passera son
temps à sortir de la RAM des pages et à en rentrée de nouvelles depuis le
swap, et cela fait souvent boule de neige.
Le swap est bien, mais il ne faut pas en abuser.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 25/05/04 0:23, dans <1gebecq.w2gaph1bcpcffN%, « Pascal Bezou » a écrit :
Si j'ai bien compris, quand une application se lance, elle dit au système qu'elle est "susceptible" d'utiliser 1 Go (par exemple), mais au début elle n'en utilisera que 100 Mo (encore par exemple)
Cette description ressemble à la gestion sur Mac OS 9 :-)
Voici, encore, une explication simplifiée.
Supposons un programme de 300 ko. Ce programme utilise divers bibliothèques partagées souvent très volumineuses (plusieurs Mo). Quand on lance le programme, il ne réserve rien (au sens Mac OS 9), mais le système sait qu'il existe, et il lui alloue virtuellement un espace de travail pour le programme et ses bibliothèques. Cet espace virtuelle fait alors typiquement plusieurs Mo. À ce stade le programme n'a pas vraiment commencé à tourner et il n'utilise pas vraiment de mémoire physique (RAM).
Et quand le programme commence son exécution, le système va copier la première page mémoire du programme (de 4 ko) du système de fichier vers la mémoire physique (RAM). Au fur et à mesure de son exécution, le système va copier de plus en plus de pages du disque vers la RAM. On voit cela dans la "pagein". Mais il arrive très souvent que le programme n'ait pas besoin de tout le code du fichier, et donc tout ce code ne sera pas recopié en mémoire physique. De la même façon les bibliothèques partagées sont souvent très grosses et un programme n'en utilise qu'une petite partie. Tout cela fait qu'en mémoire physique (RAM), il n'y a qu'un petit bout d'un programme.
En utilisant le programme "top", on voit par exemple que la RAM prise par un programme (RSIZE) est bien plus petite que la mémoire virtuelle (VSIZE).
Si le programme utilisait toutes les fonctions de son code ainsi que toutes les fonctions de toutes les bibliothèques, il y aurait à terme tout le code en mémoire physique et donc on aurait un RSIZE = VSIZE.
Si le système n'utilisait pas la mémoire virtuelle, il faudrait que tout le programme soit chargé en mémoire physique avant que l'exécution ne commence. Cela entraînerait par exemple comme limite qu'un programme ne puisse s'exécuter que si sa taille totale est inférieure à la taille de la RAM. Sur Mac OS X (et unix), ce n'est pas nécessaire : un programme peut être plus gros que la taille de la RAM.
En plus de ce système, il y a le swap, qui est indépendant de la gestion de la mémoire virtuelle. Le swap (écriture sur disque, "pageout") se déclanche quand la mémoire physique (RAM) est proche de la saturation. Les vieilles pages en RAM sont écrites dans le swap pour libérer de la RAM, cela n'empêche pas l'exécution des programmes, même si ceux-ci avaient utilisés ces pages mémoire. Mais bien sur quand un programme qui tourne en mémoire physique a besoin d'une page qui a été swappée, le système fait l'inverse en réécrivant des pages du swap vers la RAM (l'autre partie du "pagein"). Si beaucoup de programmes tournent dans peu de RAM, le système passera son temps à sortir de la RAM des pages et à en rentrée de nouvelles depuis le swap, et cela fait souvent boule de neige.
Le swap est bien, mais il ne faut pas en abuser.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pbezou
Éric Lévénez wrote:
Cette description ressemble à la gestion sur Mac OS 9 :-)
Désolé, je ne suis pas encore un expert Unix ;-)
Voici, encore, une explication simplifiée. [snip]
Merci, je l'ai archivé dans mon dossier sur Mac OS X.
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Éric Lévénez <news@levenez.com> wrote:
Cette description ressemble à la gestion sur Mac OS 9 :-)
Désolé, je ne suis pas encore un expert Unix ;-)
Voici, encore, une explication simplifiée.
[snip]
Merci, je l'ai archivé dans mon dossier sur Mac OS X.
--
MVP Microsoft Mac
www.makiciel.com
Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire
(Enlever "EnTrop" dans l'adresse pour me contacter par mail)
Cette description ressemble à la gestion sur Mac OS 9 :-)
Désolé, je ne suis pas encore un expert Unix ;-)
Voici, encore, une explication simplifiée. [snip]
Merci, je l'ai archivé dans mon dossier sur Mac OS X.
-- MVP Microsoft Mac www.makiciel.com Retrouver les Grand Prix de F1 et le Top 50 du 3ème millénaire (Enlever "EnTrop" dans l'adresse pour me contacter par mail)
blanc
Saïd wrote:
merci. La lecture du man de 'dynamic_pager' est tres instructive. Avec l'option -S on peut limiter la taille des fichiers de swap.
Plus précisément on impose une taille fixe en octets pour ces fichiers "swapfile" : l'argument de l'option -S
avec -H on peut dire de creer une nouvelle page si il y moins d'un certain nombre d'octets libres dans le swap.
Autrement dit -H permet de définir un "seuil de hautes eaux" en dessous duquel il faut créer un nouveau fichier "swapfile" (et non pas une page, "paging file" = fichier de pagination (ou fichier de swap)).
Par contre -L a l'air plus obscur
Mais non, c'est tout simplement l'opposé. Cette option permet de définir un "seuil de basses eaux" à partir duquel il faut regrouper (coalesce) les pages afin de pouvoir libérer (et par suite supprimer) l'un des fichiers "swapfile".
Il est dit par ailleurs que les trois options (-S,-H,-L) désactivent le défaut (qui est : "taille variable augmentant lorsque la demande de pages s'accroit). Ce qui n'est pas clair, c'est qu'elle est la taille fixe lorsqu'il n'y a pas l'option -S (et qu'il y a l'une des deux autres options). Peut-être la différence entre les deux seuils ?
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Saïd <said@brian.lan> wrote:
merci. La lecture du man de 'dynamic_pager' est tres instructive.
Avec l'option -S on peut limiter la taille des fichiers de swap.
Plus précisément on impose une taille fixe en octets pour ces fichiers
"swapfile" : l'argument de l'option -S
avec -H on peut dire de creer une nouvelle page
si il y moins d'un certain nombre d'octets libres dans le swap.
Autrement dit -H permet de définir un "seuil de hautes eaux" en dessous
duquel il faut créer un nouveau fichier "swapfile" (et non pas une page,
"paging file" = fichier de pagination (ou fichier de swap)).
Par contre -L a l'air plus obscur
Mais non, c'est tout simplement l'opposé. Cette option permet de définir
un "seuil de basses eaux" à partir duquel il faut regrouper (coalesce)
les pages afin de pouvoir libérer (et par suite supprimer) l'un des
fichiers "swapfile".
Il est dit par ailleurs que les trois options (-S,-H,-L) désactivent le
défaut (qui est : "taille variable augmentant lorsque la demande de
pages s'accroit).
Ce qui n'est pas clair, c'est qu'elle est la taille fixe lorsqu'il n'y a
pas l'option -S (et qu'il y a l'une des deux autres options).
Peut-être la différence entre les deux seuils ?
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
merci. La lecture du man de 'dynamic_pager' est tres instructive. Avec l'option -S on peut limiter la taille des fichiers de swap.
Plus précisément on impose une taille fixe en octets pour ces fichiers "swapfile" : l'argument de l'option -S
avec -H on peut dire de creer une nouvelle page si il y moins d'un certain nombre d'octets libres dans le swap.
Autrement dit -H permet de définir un "seuil de hautes eaux" en dessous duquel il faut créer un nouveau fichier "swapfile" (et non pas une page, "paging file" = fichier de pagination (ou fichier de swap)).
Par contre -L a l'air plus obscur
Mais non, c'est tout simplement l'opposé. Cette option permet de définir un "seuil de basses eaux" à partir duquel il faut regrouper (coalesce) les pages afin de pouvoir libérer (et par suite supprimer) l'un des fichiers "swapfile".
Il est dit par ailleurs que les trois options (-S,-H,-L) désactivent le défaut (qui est : "taille variable augmentant lorsque la demande de pages s'accroit). Ce qui n'est pas clair, c'est qu'elle est la taille fixe lorsqu'il n'y a pas l'option -S (et qu'il y a l'une des deux autres options). Peut-être la différence entre les deux seuils ?
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
