Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%,En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit). Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe. Les buffers du cache disque
mettent en effet "un certain temps" à être réécrit sur disque. Avec 5 Go, je
swappe quand je veux :-/
Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%pas.de.spam@chez.moi>,
En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit). Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe. Les buffers du cache disque
mettent en effet "un certain temps" à être réécrit sur disque. Avec 5 Go, je
swappe quand je veux :-/
Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%,En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit). Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe. Les buffers du cache disque
mettent en effet "un certain temps" à être réécrit sur disque. Avec 5 Go, je
swappe quand je veux :-/
Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Le seul moyen d'empêcher celà est que le process fils crée une
nouvelle session de process et se retrouve alors rataché à init.
Ce
n'est généralement utile que pour les daemons ou pour des processes
lancés à la main depuis un shell.
En passant, il n'existe qu'une seule technique sous Unix pour gérer les
processus fils, qui est d'utiliser l'appel système waitpid (ou les
"vieux" wait wait3 et wait4 de BSD mais ça revient au même...).
Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Le seul moyen d'empêcher celà est que le process fils crée une
nouvelle session de process et se retrouve alors rataché à init.
Ce
n'est généralement utile que pour les daemons ou pour des processes
lancés à la main depuis un shell.
En passant, il n'existe qu'une seule technique sous Unix pour gérer les
processus fils, qui est d'utiliser l'appel système waitpid (ou les
"vieux" wait wait3 et wait4 de BSD mais ça revient au même...).
Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Le seul moyen d'empêcher celà est que le process fils crée une
nouvelle session de process et se retrouve alors rataché à init.
Ce
n'est généralement utile que pour les daemons ou pour des processes
lancés à la main depuis un shell.
En passant, il n'existe qu'une seule technique sous Unix pour gérer les
processus fils, qui est d'utiliser l'appel système waitpid (ou les
"vieux" wait wait3 et wait4 de BSD mais ça revient au même...).
Le 20/11/04 19:16, dans , « Grrrr »
a écrit :Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Le 20/11/04 19:16, dans <pan.2004.11.20.18.16.06.576147@Grrr.org>, « Grrrr »
<Grrr@Grrr.org> a écrit :
Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Le 20/11/04 19:16, dans , « Grrrr »
a écrit :Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Eric Lévénez :Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%,
« Pierre-Olivier TAUBATY » a écrit :En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit).
T'es sur que c'est du cache en ecriture et pas plutot un cache de lecture
(i.e. si on relit les fichiers sources qui viennent d'etre copies, la
lecture est immediate). Parce que tarder a ecrire des donnees ca me semble
dangereux comme manip.
Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe.
C'est ballot. Soit le cache en question est en attente d'ecriture et dans
ce cas-la autant ecrire sur le disque et liberer de la RAM, ca ne prendra
pas beaucoup plus de temps que de swaper des donnees de programmes qui se
trouvent en RAM. Soit c'est du cache en lecture et il peut etre libere
immediatement.
Eric Lévénez :
Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%pas.de.spam@chez.moi>,
« Pierre-Olivier TAUBATY » <pas.de.spam@chez.moi> a écrit :
En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit).
T'es sur que c'est du cache en ecriture et pas plutot un cache de lecture
(i.e. si on relit les fichiers sources qui viennent d'etre copies, la
lecture est immediate). Parce que tarder a ecrire des donnees ca me semble
dangereux comme manip.
Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe.
C'est ballot. Soit le cache en question est en attente d'ecriture et dans
ce cas-la autant ecrire sur le disque et liberer de la RAM, ca ne prendra
pas beaucoup plus de temps que de swaper des donnees de programmes qui se
trouvent en RAM. Soit c'est du cache en lecture et il peut etre libere
immediatement.
Eric Lévénez :Le 20/11/04 19:26, dans <1gnkm0l.t3pjv518o14sqN%,
« Pierre-Olivier TAUBATY » a écrit :En ce qui concerne la mémoire de la bête, je lui ai mis 3,5 Go en
pensant voir disparaître une bonne fois pour toute les fichiers swap au
delà du 64 Mo initial et inamovible, ben c'est raté ... c'te satané
machine a trouvé le moyen un jour de monter jusqu'au 256 Mo ....:-)
Là, c'est dû à Mac OS X 10.3, il semble que ce système gère de manière
spécial le cache disque. Ainsi si on utilise beaucoup d'accès disque, comme
une copie de gros fichiers, la RAM se rempli de buffers (non encore
réécrit).
T'es sur que c'est du cache en ecriture et pas plutot un cache de lecture
(i.e. si on relit les fichiers sources qui viennent d'etre copies, la
lecture est immediate). Parce que tarder a ecrire des donnees ca me semble
dangereux comme manip.
Et si on lance à ce moment une application, il n'y a plus assez de
place RAM libre pour le programme, et ça swappe.
C'est ballot. Soit le cache en question est en attente d'ecriture et dans
ce cas-la autant ecrire sur le disque et liberer de la RAM, ca ne prendra
pas beaucoup plus de temps que de swaper des donnees de programmes qui se
trouvent en RAM. Soit c'est du cache en lecture et il peut etre libere
immediatement.
Eric Lévénez :Le 20/11/04 19:16, dans , « Grrrr »
a écrit :Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Le fils recoit un signal HUP, non?
Eric Lévénez :
Le 20/11/04 19:16, dans <pan.2004.11.20.18.16.06.576147@Grrr.org>, « Grrrr »
<Grrr@Grrr.org> a écrit :
Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Le fils recoit un signal HUP, non?
Eric Lévénez :Le 20/11/04 19:16, dans , « Grrrr »
a écrit :Par défaut, sous Unix, quand un process meurt, tous ses fils meurent avec
lui.
Cela n'est pas le cas et n'a jamais été le cas sous unix. Par défaut, les
process fils sont adoptés par init et ne meurt pas.
Le fils recoit un signal HUP, non?
Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Pierre-Olivier TAUBATY wrote:Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Disk Velox <http://www.cutolo.tk/> gratuit
Ram Disk Creator <http://www.donelleschi.com/ramdiskcreator/ >13.17
EUR
Je crois pas que tu puisse boote OS X dessus, à voir.
Pierre-Olivier TAUBATY <pas.de.spam@chez.moi> wrote:
Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Disk Velox <http://www.cutolo.tk/> gratuit
Ram Disk Creator <http://www.donelleschi.com/ramdiskcreator/ >13.17
EUR
Je crois pas que tu puisse boote OS X dessus, à voir.
Pierre-Olivier TAUBATY wrote:Par contre, ce qui m'amuserait assez ce serait de faire un RAM disque
permanent (possible) et d'y mettre le système pour voir ce que ça
donnerait ... Ça devrait booter raisonnablement vite :-))
--
Disk Velox <http://www.cutolo.tk/> gratuit
Ram Disk Creator <http://www.donelleschi.com/ramdiskcreator/ >13.17
EUR
Je crois pas que tu puisse boote OS X dessus, à voir.
Le 19/11/04 22:22, dans <1gnizk3.1lcfymdpykkyzN%,j'ai remarqué que de temps en temps, en sortie de veille, j'ai le
process "netstat" qui occupe quasi 100% de temps processeur (bi pro).
Pas normal.A quoi sert-il ?
netstat est un outil pour avoir des statistiques et des status sur le réseau
IP. On le lance sous shell
netstat -i donne la liste des interfaces réseaux (loopback, Ethernet...)
netstat -s donne le nombre de paquets émis/reçus par toutes les couches
netstat -a donne la liste des sockets IP et UNIX ouverts
...J'ai noté qu'il n'est pas souvent actif. Lorsque cela se produit, il
reste à ce taux, même après une fermeture et réouverture de session.
Personne ne devrait le lancer à part toi. Si quelqu'un le lance, c'est qu'un
programme, au lieu d'écrire le code de lecture de ses stats, se contente de
lancer netstat pour récupérer ces résultats. Pas joli si cela est. Pour voir
le père de netstat (celui qui l'a lancé) :
ps axcl
Tu recherches d'abord le PPID de "netstat", puis tu recherches le PID qui a
cette valeur et cela te donnera le parent donc le coupable. Cela peut se
traduire par (il faut que netstat tourne) :
ps lwwp `ps axlc | grep netstat | awk "{print $3}"`
Le 19/11/04 22:22, dans <1gnizk3.1lcfymdpykkyzN%pas.de.spam@chez.moi>,
j'ai remarqué que de temps en temps, en sortie de veille, j'ai le
process "netstat" qui occupe quasi 100% de temps processeur (bi pro).
Pas normal.
A quoi sert-il ?
netstat est un outil pour avoir des statistiques et des status sur le réseau
IP. On le lance sous shell
netstat -i donne la liste des interfaces réseaux (loopback, Ethernet...)
netstat -s donne le nombre de paquets émis/reçus par toutes les couches
netstat -a donne la liste des sockets IP et UNIX ouverts
...
J'ai noté qu'il n'est pas souvent actif. Lorsque cela se produit, il
reste à ce taux, même après une fermeture et réouverture de session.
Personne ne devrait le lancer à part toi. Si quelqu'un le lance, c'est qu'un
programme, au lieu d'écrire le code de lecture de ses stats, se contente de
lancer netstat pour récupérer ces résultats. Pas joli si cela est. Pour voir
le père de netstat (celui qui l'a lancé) :
ps axcl
Tu recherches d'abord le PPID de "netstat", puis tu recherches le PID qui a
cette valeur et cela te donnera le parent donc le coupable. Cela peut se
traduire par (il faut que netstat tourne) :
ps lwwp `ps axlc | grep netstat | awk "{print \$3}"`
Le 19/11/04 22:22, dans <1gnizk3.1lcfymdpykkyzN%,j'ai remarqué que de temps en temps, en sortie de veille, j'ai le
process "netstat" qui occupe quasi 100% de temps processeur (bi pro).
Pas normal.A quoi sert-il ?
netstat est un outil pour avoir des statistiques et des status sur le réseau
IP. On le lance sous shell
netstat -i donne la liste des interfaces réseaux (loopback, Ethernet...)
netstat -s donne le nombre de paquets émis/reçus par toutes les couches
netstat -a donne la liste des sockets IP et UNIX ouverts
...J'ai noté qu'il n'est pas souvent actif. Lorsque cela se produit, il
reste à ce taux, même après une fermeture et réouverture de session.
Personne ne devrait le lancer à part toi. Si quelqu'un le lance, c'est qu'un
programme, au lieu d'écrire le code de lecture de ses stats, se contente de
lancer netstat pour récupérer ces résultats. Pas joli si cela est. Pour voir
le père de netstat (celui qui l'a lancé) :
ps axcl
Tu recherches d'abord le PPID de "netstat", puis tu recherches le PID qui a
cette valeur et cela te donnera le parent donc le coupable. Cela peut se
traduire par (il faut que netstat tourne) :
ps lwwp `ps axlc | grep netstat | awk "{print $3}"`
donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print $3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print \$3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print $3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
Le 22/11/04 20:27, dans <1gnoe6t.5h70bbt5upwuN%,donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print $3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
Bin, à priori c'est un programme Mac OS X qui veut changer le nom de
l'ordinateur. Tu devrait donc faire un bug report à Apple sur netstat.
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
Configd est un démon qui regarde les changement dans la configuration IP
pour les appliquer (en changeant le nom de la machine par exemple).c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
Dieu le père est init (1), kernel_task est plutôt le néant dans le noyau.
Le 22/11/04 20:27, dans <1gnoe6t.5h70bbt5upwuN%pas.de.spam@chez.moi>,
donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print \$3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
Bin, à priori c'est un programme Mac OS X qui veut changer le nom de
l'ordinateur. Tu devrait donc faire un bug report à Apple sur netstat.
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
Configd est un démon qui regarde les changement dans la configuration IP
pour les appliquer (en changeant le nom de la machine par exemple).
c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
Dieu le père est init (1), kernel_task est plutôt le néant dans le noyau.
Le 22/11/04 20:27, dans <1gnoe6t.5h70bbt5upwuN%,donc voila cela vient de se reproduire et j'ai :
Ordinateur-de-Pierre-Olivier-TAUBATY:~ po$ ps lwwp `ps axlc | grep
netstat | awk "{print $3}"`
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME
COMMAND
0 1607 1605 0 31 0 18644 348 - S ?? 0:00.00
sh
/System/Library/SystemConfiguration/Kicker.bundle/Contents/Resources/set
-hostname
Bin, à priori c'est un programme Mac OS X qui veut changer le nom de
l'ordinateur. Tu devrait donc faire un bug report à Apple sur netstat.
donc netstat (PID 1608), avait comme parent sh (1607) initié par sh
(1605, initié par configd (89) initié par mach_init (2) initié par
kernel_task (0), j'ai trouvé cela grâce au moniteur d'activité et
remonté la "généalogie"
Configd est un démon qui regarde les changement dans la configuration IP
pour les appliquer (en changeant le nom de la machine par exemple).c'est biblique OS X, si l'on remonte la lignée des ancètres, on arrive à
Dieu le Père (kernel_task) ... :-)
Dieu le père est init (1), kernel_task est plutôt le néant dans le noyau.
