Qu'est-ce qui déclenche les surcharges du processeur de mon Finder ?

"J'aimerais qu'il y ait un moyen de "rentrer dans la tête du Finder" et de voir ce qu'il fait. J'ai essayé de lancer un échantillon du processus Finder dans Activity Monitor, mais honnêtement, je ne sais pas ce qu'il fait, et encore moins comment interpréter le résultat."

Prendre un échantillon dans le moniteur d'activité est exactement cela : entrer dans la tête du Finder pour voir ce qu'il fait. Bien que cela puisse sembler être du grec, moi ou d'autres ici pouvons l'interpréter pour vous. Il suffit de le poster, ou de le rendre disponible pour le téléchargement ou la visualisation (car ils ont tendance à être assez gros).

Quelle version d'OS X utilisez-vous ? Dans OS X 10.5.x et antérieur, je crois que le contenu multimédia était exécuté dans le Finder lui-même, plutôt que de le déléguer à un processus de type agent/assistant, ce qui fait que l'utilisation du CPU peut sembler plus élevée. Par exemple, la prévisualisation d'un film QuickTime peut faire monter en flèche le Finder 10.5.x et antérieurs à 60% du CPU, alors que dans 10.6 il pourrait être divisé à quelque chose comme 10% du CPU pour le Finder, 30% du CPU pour le processus de fond QTKitHelper.

Sinon, j'ai parfois vu le code utilisé par le Finder pour calculer la taille du contenu d'un dossier provoquer des pics temporaires de CPU. (Vous remarquerez quelque chose comme TSomething::HFSSizerSomething dans la trace de la pile d'un échantillon). En général, il semble insister pour terminer son calcul, même si la vue que vous aviez ouverte et qui justifiait le calcul a été fermée depuis.

Dans tous les cas, le fait de voir l'échantillon devrait aider à identifier le problème et à savoir quel contexte a conduit au pic. Il sera plus facile d'expliquer ce que fait la prise d'un échantillon une fois que nous l'aurons sous les yeux pour le regarder.

Vous disposez de DTrace.

man -k DTrace

Ces outils, plus fs_usage -f filesys devraient vous donner la réponse.

Modifiez l'option Finder > Préférences > Général "Affichage de la nouvelle fenêtre du Finder" sur tout autre chose que "Tous mes fichiers". Cela aide beaucoup.

De bons conseils jusqu'à présent. Je vais vous faire part d'une expérience que j'ai eue avec un Powerbook à l'époque de Tiger (mais comme Leopard a aussi un processus FatFinder, ce problème se pose aussi en 10.5).

Je me souviens avoir eu un AVI dans un dossier. Le format était bizarre, ce n'était pas un simple film Quicktime ou autre ; à l'époque, les appareils photo des téléphones portables étaient mauvais et utilisaient les pires codecs possibles jamais créés. Ainsi, chaque fois que j'allais dans ce "dossier" avec le Finder, il se bloquait, parce qu'il essayait de "lire" le fichier et que le codec était mauvais.

Finalement, soit par chance, soit parce que je l'ai oublié (ou supprimé), cela a cessé de se produire. Mais il m'a fallu un certain temps pour comprendre ce que c'était. Je me souviens que ce comportement exact m'est arrivé sous Leopard avec une vidéo "mal" formatée également. Quicklook bloquait le finder avec ce média.

J'ai dû l'ouvrir avec VLC pour le "réparer". Et ensuite, il s'est mystérieusement remis à fonctionner.

Je vous suggère d'essayer de garder un œil sur vos habitudes d'utilisation avant le pic de CPU pour voir s'il y a quelque chose en commun. Un type de fichier, un dossier spécifique, une méthode d'utilisation spécifique temps etc.

À l'heure où j'écris ces lignes, je ne connais pas votre version d'OS X (10.x ?). Ces informations peuvent donc être légèrement dépassées si vous utilisez Snow Leopard.

En outre, suivez le conseil d'essayer de sortir fs_usage, top, et des outils similaires. Cela pourrait nous donner un meilleur indice. La sortie de Console.app (/Applications/Utilities) pourrait nous éclairer sur le problème.

Je n'ai trouvé que deux outils qui se sont avérés très utiles pour résoudre les problèmes d'utilisation élevée du CPU sur un programme isolé. Oui, le moniteur d'activité peut échantillonner et vous dire où il est bloqué / en cours de traitement - mais je trouve qu'Instruments est mieux adapté pour vraiment aller au cœur du problème si fs_usage ne le peut pas. DTrace est génial - je n'ai simplement jamais eu besoin de passer du temps à l'apprendre - Instruments fonctionne assez bien et la courbe d'apprentissage pour moi était beaucoup plus faible.

1. fs_usage y grep pour déterminer les fichiers auxquels on accède me permet souvent de savoir où et comment se situent les problèmes, afin que je puisse prendre des mesures pour y remédier ou les régler.
2. Application instrumentale - Xcode 3 est fourni pour développeurs libres ou Xcode 4 (acheté dans le Mac App Store ou en tant que développeur payant). Considérez cela comme un moniteur d'activité/échantillon sur des stéroïdes - vous pouvez examiner des choses comme l'allocation de mémoire / les fuites et obtenir une vue beaucoup plus complète de ce qui se passe à l'intérieur d'un processus lent pendant son exécution.