Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Mac OS Autres OS Mac OS X Process "Netstat" à 100% en sortie de veille ???

Process "Netstat" à 100% en sortie de veille ???

21 réponses
Avatar
pas.de.spam
Bonjour(soir) à tous,

Appel aux cadors de l'Unix :

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).

A quoi sert-il ?

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.

Cela s'est produit aussi bien sur le G4 que sur le G5 (Panther pour les
2 machines).

Avant je redémarrais pour le virer, là je viens de l'occire sans pitié
avec moniteur d'activité, sans qu'à priori cela ne gne le fonctionnement
de la machine.

merci.

--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Eric Lévénez
Le 19/11/04 22:22, dans <1gnizk3.1lcfymdpykkyzN%,
« Pierre-Olivier TAUBATY » a écrit :

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}"`

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

Avatar
pas.de.spam
Eric Lévénez wrote:

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.


je m'en doutais un peu, c'est d'ailleurs pour cela que je n'ai pas posé
la "quetion qui (te) tue" :-)

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'utilise Menu Meters pour avoir le débit instantanné internet, et pour
avoir une idée des flux entrant et et sortants, ainsi que de
l'occupation mémoire et autre.

Mais ce process n'est pas toujours lancé ... très rarement même (enfin,
plutôt ce n'est que rarement que je constate des problèmes et qu'il est
impliqué), ce matin en sortant de veille, il ne tournait pas ...


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


merci.

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}"`


merci bien, je tâcherais de retrouver cette formule lorsque la blague se
reproduira ...


une idée à propos du fait qu'il reste actif même après une
clôture-réouverture de session. Je pensais que ce faisant, on
réinitialisait à peu près tout ...
--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr


Avatar
Eric Lévénez
Le 20/11/04 8:40, dans <1gnjq76.gm57x21hgjstvN%,
« Pierre-Olivier TAUBATY » a écrit :

une idée à propos du fait qu'il reste actif même après une
clôture-réouverture de session. Je pensais que ce faisant, on
réinitialisait à peu près tout ...


Sous unix, quand un processus père lance un processus fils. Si le père
s'arrête, le fils n'est pas prévenu et il se fait adopté par le processus
numéro 1, init, qui est le père de tout le monde. Normalement, tout père qui
lance un fils doit s'occuper de lui. Il existe des techniques plus ou moins
sioux pour cela. Mais dans ton cas c'est peut-être une mort brutal du père
qui entraîne le problème.

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

Avatar
pas.de.spam
Eric Lévénez wrote:

Le 20/11/04 8:40, dans <1gnjq76.gm57x21hgjstvN%,

une idée à propos du fait qu'il reste actif même après une
clôture-réouverture de session. Je pensais que ce faisant, on
réinitialisait à peu près tout ...


Sous unix, quand un processus père lance un processus fils. Si le père
s'arrête, le fils n'est pas prévenu et il se fait adopté par le processus
numéro 1, init, qui est le père de tout le monde. Normalement, tout père qui
lance un fils doit s'occuper de lui. Il existe des techniques plus ou moins
sioux pour cela. Mais dans ton cas c'est peut-être une mort brutal du père
qui entraîne le problème.,


certes, mais dans mon esprit, une fermeture de session clôturait
obligatoirement tous les process ...

ce qui ne semble pas être le cas.

Tiens, pendant que je te tiens, peux tu me dire, ce qu'est une "page
fault" en terme de mémoire virtuelle. Car cela fait parti des infos que
le donne MenuMeters, j'en ai en ce moment un peu plus de 34 Millions.

c'est grave Dr ?
--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr


Avatar
Eric Lévénez
Le 20/11/04 13:05, dans <1gnk4kh.1u553q51ppg1lzN%,
« Pierre-Olivier TAUBATY » a écrit :

certes, mais dans mon esprit, une fermeture de session clôturait
obligatoirement tous les process ...


En fait on demande à un processus de s'arrêter. Lui demande à ceux qu'il a
lancé de le faire, et ainsi de suite.

ce qui ne semble pas être le cas.


Cela peut être le cas, mais cela dépend comment c'est programmé. Il y a sous
unix la notion de session et de groupe de processus. On peut tuer tous ceux
d'un groupe d'un seul coup par exemple. Typiquement quand on se connecte en
shell sous unix, ce shell crée un groupe, et ainsi tous les programmes que
l'on peut lancer seront fermé à la fin du shell.

Mais comme d'habitude, en plus de cette possibilité, chaque programme peut
redéfinir son comportement sur les demande de fermeture (signaux unix).

Tiens, pendant que je te tiens, peux tu me dire, ce qu'est une "page
fault" en terme de mémoire virtuelle. Car cela fait parti des infos que
le donne MenuMeters, j'en ai en ce moment un peu plus de 34 Millions.


Il y a bien longtemps (20 ou 25 ans dans le monde unix), pour lancer un
programme le système le chargeait entièrement en RAM puis le lançait.
Aujourd'hui, ce n'est plus le cas. Seul un tout petit bout est chargé en RAM
(quelques ko, même si le programme fait quelques Mo). Au fur et à mesure que
le programme tourne, il va essayer d'accéder à des bouts de code (des pages
de mémoire). Si ces bouts sont en RAM, le programme exécute le code (comme
d'habitude). Mais ces le bout de code n'est pas encore lu en RAM, alors le
programme est suspendu, et le système lit le bout manquant du disque et le
place en RAM. Une fois cela fait le programme peut continuer. Je pense que
ces "pages fault" sont les "Translation faults" de Mach qui sont ces accès à
de la mémoire virtuelle pas encore physique. Donc tout cela est "normal".

Comme je suppose que tu vas demander si cela ne ralenti pas un programme, la
réponse est non, car le système sait lire à l'avance des pages mémoire avant
que le programme n'y accède. De plus cela permet de lancer plus rapidement
un programme car on n'a pas besoin de tout charger en RAM. Cela permet aussi
de n'occuper que la mémoire nécessaire en RAM dans le cas d'un gros
programme dont on n'utiliserait pas toutes les possibilités.

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

Avatar
Grrrr
On Sat, 20 Nov 2004 16:05:46 +0400, Pierre-Olivier TAUBATY wrote:

Eric Lévénez wrote:

Le 20/11/04 8:40, dans <1gnjq76.gm57x21hgjstvN%,

une idée à propos du fait qu'il reste actif même après une
clôture-réouverture de session. Je pensais que ce faisant, on
réinitialisait à peu près tout ...


Sous unix, quand un processus père lance un processus fils. Si le père
s'arrête, le fils n'est pas prévenu et il se fait adopté par le processus
numéro 1, init, qui est le père de tout le monde. Normalement, tout père qui
lance un fils doit s'occuper de lui. Il existe des techniques plus ou moins
sioux pour cela. Mais dans ton cas c'est peut-être une mort brutal du père
qui entraîne le problème.,


certes, mais dans mon esprit, une fermeture de session clôturait
obligatoirement tous les process ...

ce qui ne semble pas être le cas.


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...).

Tiens, pendant que je te tiens, peux tu me dire, ce qu'est une "page
fault" en terme de mémoire virtuelle. Car cela fait parti des infos que
le donne MenuMeters, j'en ai en ce moment un peu plus de 34 Millions.

c'est grave Dr ?


C'est normal. Les page-fault peuvent avoir lieu dans plusieurs cas:
- un processus accède pour la première fois à une page de mémoire
virtuelle. Celle ci doit donc être allouée en mémoire physique.
- le process accède à une page d'un fichier mappé qui n'est pas en
mémoire physique soit parce que c'est le premier accès, soit
parce qu'elle a été démappée et doit être remappée (c'est la
technique standard de swap pour les executables, les librairies
partagées et les fichiers mappés par le processus).
- le processus accède à une page de donnée qui a été swappée. Celle ci
doit donc être réallouée en mémoire physique.
- dernier cas, le seul vraiment grave: le processus essaye d'accéder à
une page non mappée. Il reçoit alors un signal 11, c'est la fameuse
"segmentation fault".
En bref, les page-faults servent à gérer l'allocation de pages mémoire
physique en fonction de l'utilisation d'un processus de sa mémoire
virtuelle.



Avatar
pas.de.spam
Eric Lévénez wrote:

Comme je suppose que tu vas demander si cela ne ralenti pas un programme, la
réponse est non, car le système sait lire à l'avance des pages mémoire avant
que le programme n'y accède. De plus cela permet de lancer plus rapidement
un programme car on n'a pas besoin de tout charger en RAM. Cela permet aussi
de n'occuper que la mémoire nécessaire en RAM dans le cas d'un gros
programme dont on n'utiliserait pas toutes les possibilités.


je n'avais pas noté de ralentissements, et de toute façon, comme toi,
j'ai un RAID 0 (2 x 400 Go). C'est pas mal rapide effectivement. Je me
demande si un raid Hardware serait encore plus performant.

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 ....:-)


Merci à toi de ces précisions.
--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr

Avatar
pas.de.spam
Grrrr wrote:

Merci bien de ces précisions complémentaires à celles d'Eric.


--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
Avatar
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). 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 :-/

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

Avatar
Saïd
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.

--
Saïd.
C programmers never die - they're just cast into void.


1 2 3