Ceci dit ton choix de redémarrer n'est pas rationnel : le temps perdu à
le faire dépasse largement le temps que tu vas (éventuellement) gagner
par la suite. Et tu arriverais au même résultat avec un simple "sudo
purge".
Ceci dit ton choix de redémarrer n'est pas rationnel : le temps perdu à
le faire dépasse largement le temps que tu vas (éventuellement) gagner
par la suite. Et tu arriverais au même résultat avec un simple "sudo
purge".
Ceci dit ton choix de redémarrer n'est pas rationnel : le temps perdu à
le faire dépasse largement le temps que tu vas (éventuellement) gagner
par la suite. Et tu arriverais au même résultat avec un simple "sudo
purge".
Le 15/11/2018 à 18:00, Patrick a écrit :On 2018-11-15 15:51:33 +0000, pehache said:Le 15/11/2018 à 16:34, Patrick a écrit :
Tu aurais de la documentation ou des URL sur le « swap en mémoire »
"swap en mémoire" je ne connais pas ce terme :-)
qu'effectuerait Windows ou les différents Unix depuis des lustres.
Parce que, moi, je cherche encore. Je ne savais pas que sur ces OS tout
comme sur macOS depuis peu, une application qui quitte ne libèrait pas
les ressources qui lui sont associées. Je ne demande qu'à apprendre.
par exemple
https://www.randco.fr/blog/2012/gestion-de-la-ram-sous-linux/
https://docs.microsoft.com/en-us/windows/desktop/fileio/file-caching
Comme nous l’avons vu précédemment, comparé à la RAM, un disque dur est
environ 100x plus lent. C’est dans ce cadre qu’est utilisé la mémoire
tampon. Linux place dans celle-ci toutes les données en attente
d’écriture sur le disque, les données lues sur un disque conservées
pour améliorer les performances du système (resultat d’un ‘ls’, droits
sur les fichiers, …), la position des blocs libres sur les disques, ...
En bref, toutes les informations utiles pour augmenter les performances
du système dans ses interactions avec les périphériques tel que les
disques durs.
By default, Windows caches file data that is read from disks and
written to disks. This implies that read operations read file data from
an area in system memory known as the system file cache, rather than
from the physical disk. Correspondingly, write operations write file
data to the system file cache rather than to the disk, and this type of
cache is referred to as a write-back cache.
Le 15/11/2018 à 18:00, Patrick a écrit :
On 2018-11-15 15:51:33 +0000, pehache said:
Le 15/11/2018 à 16:34, Patrick a écrit :
Tu aurais de la documentation ou des URL sur le « swap en mémoire »
"swap en mémoire" je ne connais pas ce terme :-)
qu'effectuerait Windows ou les différents Unix depuis des lustres.
Parce que, moi, je cherche encore. Je ne savais pas que sur ces OS tout
comme sur macOS depuis peu, une application qui quitte ne libèrait pas
les ressources qui lui sont associées. Je ne demande qu'à apprendre.
par exemple
https://www.randco.fr/blog/2012/gestion-de-la-ram-sous-linux/
https://docs.microsoft.com/en-us/windows/desktop/fileio/file-caching
Comme nous l’avons vu précédemment, comparé à la RAM, un disque dur est
environ 100x plus lent. C’est dans ce cadre qu’est utilisé la mémoire
tampon. Linux place dans celle-ci toutes les données en attente
d’écriture sur le disque, les données lues sur un disque conservées
pour améliorer les performances du système (resultat d’un ‘ls’, droits
sur les fichiers, …), la position des blocs libres sur les disques, ...
En bref, toutes les informations utiles pour augmenter les performances
du système dans ses interactions avec les périphériques tel que les
disques durs.
By default, Windows caches file data that is read from disks and
written to disks. This implies that read operations read file data from
an area in system memory known as the system file cache, rather than
from the physical disk. Correspondingly, write operations write file
data to the system file cache rather than to the disk, and this type of
cache is referred to as a write-back cache.
Le 15/11/2018 à 18:00, Patrick a écrit :On 2018-11-15 15:51:33 +0000, pehache said:Le 15/11/2018 à 16:34, Patrick a écrit :
Tu aurais de la documentation ou des URL sur le « swap en mémoire »
"swap en mémoire" je ne connais pas ce terme :-)
qu'effectuerait Windows ou les différents Unix depuis des lustres.
Parce que, moi, je cherche encore. Je ne savais pas que sur ces OS tout
comme sur macOS depuis peu, une application qui quitte ne libèrait pas
les ressources qui lui sont associées. Je ne demande qu'à apprendre.
par exemple
https://www.randco.fr/blog/2012/gestion-de-la-ram-sous-linux/
https://docs.microsoft.com/en-us/windows/desktop/fileio/file-caching
Comme nous l’avons vu précédemment, comparé à la RAM, un disque dur est
environ 100x plus lent. C’est dans ce cadre qu’est utilisé la mémoire
tampon. Linux place dans celle-ci toutes les données en attente
d’écriture sur le disque, les données lues sur un disque conservées
pour améliorer les performances du système (resultat d’un ‘ls’, droits
sur les fichiers, …), la position des blocs libres sur les disques, ...
En bref, toutes les informations utiles pour augmenter les performances
du système dans ses interactions avec les périphériques tel que les
disques durs.
By default, Windows caches file data that is read from disks and
written to disks. This implies that read operations read file data from
an area in system memory known as the system file cache, rather than
from the physical disk. Correspondingly, write operations write file
data to the system file cache rather than to the disk, and this type of
cache is referred to as a write-back cache.
Le 15/11/2018 à 19:40, Gilbert OLIVIER a écrit :pehache wrote:Le 15/11/2018 à 17:15, Gerald a écrit :2/ d'expérience, l'ouverture successive d'applications diverses puis
leur fermeture fait qu'au bout d'un moment la "mémoire" active est de
plus en plus utilisée. Aboutissant parfois au swap et donc, à terme de
quelques jours, poru moi, au redémarrage pour faire propre.
Ca c'est possible : quand il n'y a pas de RAM libre et qu'une appli en
demande, l'OS doit arbitrer entre benner des données conservées en cache
(ce qui est immédiat) ou swapper une application ouverte de la RAM vers le
disque (ce qui est plus lent).
Sans oublier la mémoire compressée.
OuiC'est dans cet arbitrage qu'elle intervient ou bien elle dépends
d'autres processus?
J'imagine, mais en pratique je ne sais pas.
Le 15/11/2018 à 19:40, Gilbert OLIVIER a écrit :
pehache <pehache.7@gmail.com> wrote:
Le 15/11/2018 à 17:15, Gerald a écrit :
2/ d'expérience, l'ouverture successive d'applications diverses puis
leur fermeture fait qu'au bout d'un moment la "mémoire" active est de
plus en plus utilisée. Aboutissant parfois au swap et donc, à terme de
quelques jours, poru moi, au redémarrage pour faire propre.
Ca c'est possible : quand il n'y a pas de RAM libre et qu'une appli en
demande, l'OS doit arbitrer entre benner des données conservées en cache
(ce qui est immédiat) ou swapper une application ouverte de la RAM vers le
disque (ce qui est plus lent).
Sans oublier la mémoire compressée.
Oui
C'est dans cet arbitrage qu'elle intervient ou bien elle dépends
d'autres processus?
J'imagine, mais en pratique je ne sais pas.
Le 15/11/2018 à 19:40, Gilbert OLIVIER a écrit :pehache wrote:Le 15/11/2018 à 17:15, Gerald a écrit :2/ d'expérience, l'ouverture successive d'applications diverses puis
leur fermeture fait qu'au bout d'un moment la "mémoire" active est de
plus en plus utilisée. Aboutissant parfois au swap et donc, à terme de
quelques jours, poru moi, au redémarrage pour faire propre.
Ca c'est possible : quand il n'y a pas de RAM libre et qu'une appli en
demande, l'OS doit arbitrer entre benner des données conservées en cache
(ce qui est immédiat) ou swapper une application ouverte de la RAM vers le
disque (ce qui est plus lent).
Sans oublier la mémoire compressée.
OuiC'est dans cet arbitrage qu'elle intervient ou bien elle dépends
d'autres processus?
J'imagine, mais en pratique je ne sais pas.
Le 15/11/2018 à 18:10, Patrick a écrit :Là, tu parles d'APFS, le nouveau système de fichiers d'Apple. Mais
pehache va nous dire que c'est une gestion de fichiers classique qui
existe sur tous les OS qu'il connaît ;-)
Il va surtout dire que le système de fichier (APFS ou autre) est
indépendant de l'OS. Le fichier que la simple duplication d'un fichier
n'entraine pas l'allocation de nouveaux blocs sur le disque est une
caractéristique d'APFS, pas de macOS.
Il va aussi dire que les caractéristiques d'APFS sont grosso-modo les
mêmes que celles de ZFS, qui a été introduit en 2005 par Sun.Il y a aussi des changements au niveau de la gestion de la RAM. macOS
Mojave a des secrets bien enfouis sous le capot.
Il faudrait surtout arrêter de penser que macOS recèle des trucs
extraordinaires qui n'existeraient nulle part ailleurs. D'autant moins que
le code source du noyau et de toute la base de l'OS est libre, donc un
"secret" ne le resterait pas bien longtemps.
Le 15/11/2018 à 18:10, Patrick a écrit :
Là, tu parles d'APFS, le nouveau système de fichiers d'Apple. Mais
pehache va nous dire que c'est une gestion de fichiers classique qui
existe sur tous les OS qu'il connaît ;-)
Il va surtout dire que le système de fichier (APFS ou autre) est
indépendant de l'OS. Le fichier que la simple duplication d'un fichier
n'entraine pas l'allocation de nouveaux blocs sur le disque est une
caractéristique d'APFS, pas de macOS.
Il va aussi dire que les caractéristiques d'APFS sont grosso-modo les
mêmes que celles de ZFS, qui a été introduit en 2005 par Sun.
Il y a aussi des changements au niveau de la gestion de la RAM. macOS
Mojave a des secrets bien enfouis sous le capot.
Il faudrait surtout arrêter de penser que macOS recèle des trucs
extraordinaires qui n'existeraient nulle part ailleurs. D'autant moins que
le code source du noyau et de toute la base de l'OS est libre, donc un
"secret" ne le resterait pas bien longtemps.
Le 15/11/2018 à 18:10, Patrick a écrit :Là, tu parles d'APFS, le nouveau système de fichiers d'Apple. Mais
pehache va nous dire que c'est une gestion de fichiers classique qui
existe sur tous les OS qu'il connaît ;-)
Il va surtout dire que le système de fichier (APFS ou autre) est
indépendant de l'OS. Le fichier que la simple duplication d'un fichier
n'entraine pas l'allocation de nouveaux blocs sur le disque est une
caractéristique d'APFS, pas de macOS.
Il va aussi dire que les caractéristiques d'APFS sont grosso-modo les
mêmes que celles de ZFS, qui a été introduit en 2005 par Sun.Il y a aussi des changements au niveau de la gestion de la RAM. macOS
Mojave a des secrets bien enfouis sous le capot.
Il faudrait surtout arrêter de penser que macOS recèle des trucs
extraordinaires qui n'existeraient nulle part ailleurs. D'autant moins que
le code source du noyau et de toute la base de l'OS est libre, donc un
"secret" ne le resterait pas bien longtemps.
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
les ressources de l'application seront paginées et donc écrites sur
disque.
les ressources de l'application seront paginées et donc écrites sur
disque.
les ressources de l'application seront paginées et donc écrites sur
disque.
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
> 2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
> désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
JPP wrote:2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
Aucune idée... plutôt le lancement des disques à plateaux ?
Mais tu as aiguisé ma curiosité et je viens d'aller chronométrer mon
redémarrage après extinction complète (puisqu'il n'y a plus de son de
démarrage pour donner le top départ. Mon disque interne est chiffré, le
boot se fait donc en deux temps : pré-boot qui amène sur l'écran de
déverrouillage, puis boot avec barre de progression, jusqu'à apparition
de la barre des menus et fin de l'ouverture de session :
pré-boot = 18 s
boot = 22 s
C'est marrant, intuitivement j'avais l'impression d'un pré-boot quasi
instantané mais ce n'est pas le cas et c'est logique : il y a bien un
boot véritable, sur le système de la partition recovery, les chiffres
sont donc logiquement très semblables. Les quatre secondes de différence
peuvent même probablement s'expliquer par la détection de l'iPhone et de
l'iPad qui étaient branchés en recharge et qui se signalent par un
signal sonore avec léger ralentissement de la barre de progression.
Mon affirmation ci-dessus devient donc : "le boot d'un SSD sous Mojave,
ça prend environ 40 s. désormais". (à quoi, en toute honnêteté, il
faudrait rajouter la saisie des mots de passe pour déverrouiller les
disques externes, et le lancement éventuel automatique d'applications.
Par contre le lancement de mes utilitaires était compris dans les 22 s.
à savoir PopChar, CCC User Agent, Dropbox et iStat Menus.
À moins d'une minute tout compris pour revenir au même état
opérationnel, un redémarrage "de propreté" est désormais
particulièrement indolore.
JPP <jpp@gmail.com> wrote:
2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
Aucune idée... plutôt le lancement des disques à plateaux ?
Mais tu as aiguisé ma curiosité et je viens d'aller chronométrer mon
redémarrage après extinction complète (puisqu'il n'y a plus de son de
démarrage pour donner le top départ. Mon disque interne est chiffré, le
boot se fait donc en deux temps : pré-boot qui amène sur l'écran de
déverrouillage, puis boot avec barre de progression, jusqu'à apparition
de la barre des menus et fin de l'ouverture de session :
pré-boot = 18 s
boot = 22 s
C'est marrant, intuitivement j'avais l'impression d'un pré-boot quasi
instantané mais ce n'est pas le cas et c'est logique : il y a bien un
boot véritable, sur le système de la partition recovery, les chiffres
sont donc logiquement très semblables. Les quatre secondes de différence
peuvent même probablement s'expliquer par la détection de l'iPhone et de
l'iPad qui étaient branchés en recharge et qui se signalent par un
signal sonore avec léger ralentissement de la barre de progression.
Mon affirmation ci-dessus devient donc : "le boot d'un SSD sous Mojave,
ça prend environ 40 s. désormais". (à quoi, en toute honnêteté, il
faudrait rajouter la saisie des mots de passe pour déverrouiller les
disques externes, et le lancement éventuel automatique d'applications.
Par contre le lancement de mes utilitaires était compris dans les 22 s.
à savoir PopChar, CCC User Agent, Dropbox et iStat Menus.
À moins d'une minute tout compris pour revenir au même état
opérationnel, un redémarrage "de propreté" est désormais
particulièrement indolore.
JPP wrote:2/ Le boot d'un SSD sous Mojave, franchement, ça se compte en secondes
désormais.
A ce propos, je m'étonne du temps qu'il faut pour voir apparaitre la
barre de progression du démarrage sur mon iMac 13,2/late 2012
(SSD512/16GB/HSierra), soit 20 à 30s.
Est-ce dû à la vérification des 16GB de RAM ?
Aucune idée... plutôt le lancement des disques à plateaux ?
Mais tu as aiguisé ma curiosité et je viens d'aller chronométrer mon
redémarrage après extinction complète (puisqu'il n'y a plus de son de
démarrage pour donner le top départ. Mon disque interne est chiffré, le
boot se fait donc en deux temps : pré-boot qui amène sur l'écran de
déverrouillage, puis boot avec barre de progression, jusqu'à apparition
de la barre des menus et fin de l'ouverture de session :
pré-boot = 18 s
boot = 22 s
C'est marrant, intuitivement j'avais l'impression d'un pré-boot quasi
instantané mais ce n'est pas le cas et c'est logique : il y a bien un
boot véritable, sur le système de la partition recovery, les chiffres
sont donc logiquement très semblables. Les quatre secondes de différence
peuvent même probablement s'expliquer par la détection de l'iPhone et de
l'iPad qui étaient branchés en recharge et qui se signalent par un
signal sonore avec léger ralentissement de la barre de progression.
Mon affirmation ci-dessus devient donc : "le boot d'un SSD sous Mojave,
ça prend environ 40 s. désormais". (à quoi, en toute honnêteté, il
faudrait rajouter la saisie des mots de passe pour déverrouiller les
disques externes, et le lancement éventuel automatique d'applications.
Par contre le lancement de mes utilitaires était compris dans les 22 s.
à savoir PopChar, CCC User Agent, Dropbox et iStat Menus.
À moins d'une minute tout compris pour revenir au même état
opérationnel, un redémarrage "de propreté" est désormais
particulièrement indolore.