Existe-t-il un moyen de retracer la raison pour laquelle le processus «fseventsd» monopolise le processeur?


11

J'ai exécuté Mac OSX 10.6 et j'ai remarqué qu'un processus 'fseventsd' prenait 100% de CPU et 1,5G de RAM. En faisant une recherche sur Google, j'ai trouvé que cela pouvait être lié à Time Machine. Cependant, je n'exécute pas Time Machine sur cet ordinateur.

Existe-t-il un moyen de retracer la source du porc de ressources? Se connecte-t-il n'importe où? Un redémarrage a «résolu» le problème, mais je suis sûr qu'il reviendra si je n'arrive pas à comprendre pourquoi il a commencé en premier lieu.

Merci d'avance.


Avez-vous déjà trouvé la source? Nous rencontrons le même problème sur notre serveur Snow Leopard. Je peux essayer un redémarrage, mais je ne peux le faire que plus tard ce soir.
Greg W

Je ne l'ai pas fait apparaître depuis mon redémarrage, (mal) heureusement, donc je ne connais toujours pas la source
DTest

J'ai le même problème. Le redémarrage n'aide pas. Après 20 à 30 minutes, fseventsd redémarre pour prendre 99% de CPU. Le Macbook n'est plus silencieux ...
Laurent K

Réponses:


7

fseventd est le processus de journalisation des événements du système de fichiers, vous pouvez en lire beaucoup dans la revue ars technica de Mac OS X Leopard. Vous pouvez utiliser des programmes comme fseventer pour voir le même type de sortie qu'il voit.

De l'article:

Le framework FSEvents repose sur un seul processus démon en cours d'exécution appelé fseventsd qui lit à partir de / dev / fsevents et écrit les événements dans des fichiers journaux sur disque (stockés dans un répertoire .fseventsd à la racine du volume auquel les événements sont destinés). C'est tout. C'est la solution ultra-high-tech: il suffit d'écrire les événements dans un fichier journal. Ennuyeux, pragmatique, mais assez efficace.

Vous pouvez consulter ce journal mais je ne sais pas à quel point il vous sera utile. Je ne serais pas si surpris de voir Time Machine, qui traite de nombreux fichiers, et parfois de nombreux fichiers minuscules, provoquer éventuellement des problèmes avec les événements fsevents.


Espérons que ce ne soit pas Time Machine, car il est désactivé! Quoi qu'il en soit, je lis sur fseventer, donc merci pour la suggestion.
DTest le

3

Soit un programme était coincé dans une boucle d'écriture très efficace, ce qui causait fseventsdbeaucoup de travail, soit c'était une boucle infinie elle-même traitant une structure de données non résoluble sur l'un des volumes montés.

Dans le cas précédent - des programmes comme fseventer qui lisent le même flux de données se bloqueront probablement également - vous aurez maintenant deux processus à 50% d'utilisation essayant de traiter une quantité infinie de données. (C'est un excellent point de données si vous piquez pour voir ce qui ne va pas.) Il est analogue à des questions demandant pourquoi syslogdprend tout le processeur - généralement, c'est un autre programme devenu fou, ce qui entraîne beaucoup de travail.

Quand / si cela se reproduit - commencez à quitter les programmes et envisagez de vous déconnecter. Vous saurez si l'élément incriminé est un processus de niveau système ou un processus de niveau utilisateur. fs_usagepourrait être utile pour voir quels programmes spécifiques sont lourds d'ES.

fsck d'un démarrage en mode mono-utilisateur est généralement requis si vous avez des liens durs circulaires ou d'autres manigances dégénérées du système de fichiers qui peuvent provoquer ce type de pic d'activité.


Ouais, désolé si je n'étais pas clair, vous ne pouviez certainement pas ouvrir fseventer pendant que le caca frappait proverbialement le ventilateur. Je voulais juste en savoir plus pour vous donner une idée du type de données enregistrées et visibles, comme le ferait fs_usage.
ConstantineK

J'ai adoré en savoir plus sur fseventer - très joli. Il n'y a pas d'échec - juste des données.
bmike

Wow, merci pour l'astuce sur 'fs_usage'. Et oui, je pensais que ce n'était pas réellement fseventsd qui causait la charge, mais plutôt un autre programme. J'attends une boucle quelque part. Soit dit en passant, la machine fonctionne à charge normale depuis environ 24 heures, et cela ne s'est pas reproduit.
DTest le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.