Pourquoi le Finder fonctionne-t-il avec une priorité de processus aussi faible?

Je suis un peu perdu à ce sujet.
J'exécute une grande importation dans l'ouverture, et cela ralentit mon système pour une analyse complète, le rendant essentiellement inutilisable pour rien, même en naviguant sur le Web. Comme cela semble un peu contre nature, j'ai passé un peu de temps à regarder autour de moi.

L'exécution ps -Almontre que, apparemment par défaut, les Dock, Finderet SystemUIServertous semblent fonctionner à une priorité bien inférieure à celle des applications utilisateur. Alors que les applications utilisateur ont généralement une priorité de 33, le Dock, le Finder, etc. ont une priorité de 53.

Le résultat final est TOUTE tâche gourmande en processeur qui encombre complètement l'interface utilisateur et rend le système inutilisable jusqu'à la fin.

Quoi qu'il en soit, l'utilisation renice -20 -p <prid>les fait remonter à la même priorité que le reste de l'interface utilisateur de l'espace utilisateur, et vous évite d'avoir à attendre 1 à 3 secondes (!) Pour que l'interface utilisateur réponde à quelque chose d'aussi simple qu'un clic de souris.

Thad a dit, j'ai deux questions:
y a-t-il une raison pour laquelle je ne devrais pas modifier la priorité de thread du viseur comme ça?
Existe-t-il un moyen de rendre le changement de priorité persistant, par exemple pour qu'il reste ainsi après le redémarrage.

snow-leopard console Faux nom
la source

J'ai généralement constaté que ce sont les E / S du disque, et non la charge du processeur, qui font que mon système explore. Le Finder et les autres applications que vous mentionnez attendent probablement des lectures / écritures lorsqu'ils semblent ne pas répondre. Je n'ai pas vraiment de solution à cela (à part obtenir un disque rapide comme un SSD), cependant, je vais le poster comme un commentaire au lieu d'une réponse.

Kyle Cronin

Je l'aurais pensé aussi. Cependant, le changement de priorité du thread n'affecte le comportement de l' interface utilisateur, ce qui me fait penser que ce soit la priorité du thread affecte la gestion des files d'attente IO, ou il est en effet limité par le CPU.

Fake Name

Par exemple, avec la priorité du quai laissée en stock, il faut 5 à 10 secondes pour réagir au déplacement de la souris dessus. Avec une augmentation manuelle du même 33 que tout le reste, il réagit immédiatement (bien qu'il y ait un peu d'agitation).

Fake Name

Mise à jour: la commande nice affecte à la fois la gestion des files d'attente CPU et IO: insanelymac.com/forum/lofiversion/index.php/t164156.html

Fake Name

Le problème n'est pas une limitation d'espace mémoire / disque. J'exécute des processus qui prennent intentionnellement toutes les ressources possibles. Un ordonnanceur de multitâche approprié devrait permettre au système de rester parfaitement réactif (ou du moins ne causer qu'un impact mineur sur les performances) malgré cela, à condition que la priorité soit définie correctement. Cependant, pour une raison insensée, l' aspect le plus important de l'interface utilisateur est défini sur la priorité la plus basse possible, et l'ensemble du système est donc rendu inutilisable.

Fake Name

Réponses:

Je ne suis pas sûr que quiconque en dehors des développeurs d'Apple soit en mesure de répondre à cette question, les secrets intérieurs de Finder sont leur domaine. Si vous pensez qu'il y a des problèmes de décalage notables avec l'interface utilisateur, vous voudrez peut-être soumettre un rapport de bogue à Apple à ce sujet.

A en juger par le son des choses (processus occupant intentionnellement toutes les ressources), c'est un peu un cas de pointe pour la gestion de la mémoire. Je n'ai pas encore vu un système fonctionner à son meilleur sans quelque part autour de 10-20% de ressources gratuites, comme aide de mise en mémoire tampon.

Juste curieux, quels sont ces processus que vous exécutez?

Tim
la source

Python, principalement. Faire des calculs récursifs lourds.

Fake Name

En outre, traitement d'images par lots

Fake Name

Cela ressemble plus à un problème d'utilisation de la RAM qu'à un problème de CPU. J'ai eu quelque chose comme git utilise des tonnes de CPU sans retarder l'interface utilisateur, mais quand quelque chose commence à manger toute la RAM, l'interface utilisateur prend un coup majeur. Quelle est votre utilisation de la RAM pendant ces processus?

Tim

"J'exécute une grosse importation dans l'ouverture, et cela ralentit mon système jusqu'à une analyse complète"

Aperture est alors (probablement) le programme que vous voulez renice, pas les autres. Les processus que vous avez mentionnés sont réglés par rapport aux applications utilisateur moyennes, de sorte que les applications utilisateur obtiennent une priorité plus élevée et restent réactives, car elles sont ce que les utilisateurs utilisent la plupart du temps.

Votre cas est le moins courant, où une application exécute une tâche intensive à long terme et où l'utilisateur veut faire autre chose en même temps. Par défaut, ce sont les applications de l'utilisateur qui sont prioritaires afin que ces tâches intensives obtiennent plus de ressources et se terminent plus tôt.

Pour chaque utilisateur qui se plaint que d'autres applications ne sont pas suffisamment réactives, un autre utilisateur se plaint que l'application active ne s'exécute pas assez rapidement.

Si vous exécutez une tâche longue et gourmande en ressources et que vous savez que vous souhaitez qu'elle ait une priorité inférieure afin que vous puissiez utiliser d'autres processus pendant la fin de la tâche - et cela ne vous dérange pas si la tâche intensive prend plus de temps - vous devez baisser la priorité de le processus exécutant la tâche intensive.

Quant à votre deuxième question, il existe plusieurs solutions possibles pour rendre le reniceplus automatique. Par exemple, vous pouvez créer une applet de script qui exécute Aperture avec une priorité inférieure et l'utiliser pour démarrer Aperture. Ou vous pouvez démarrer Aperture via un script shell stocké dans un fichier * .command (cependant, cela ouvrira Terminal et exécutera la commande dans une fenêtre de terminal, qui peut ne pas être ce que vous voulez). Chacun d'eux est un peu impliqué. Si vous souhaitez des exemples, je peux voir comment les fournir plus tard.

Chris Page
la source

Les tâches en arrière-plan, par définition , doivent être de priorité inférieure aux tâches de premier plan. La tâche de premier plan la plus importante de tout le système est l'interface graphique, qui est en grande partie le processus du Finder. Je peux peut-être patcher les threads processus par processus renice, mais le problème réel est la priorité des chercheurs.

Fake Name

Par exemple, dans Windows 7, qui possède l'une des interfaces graphiques les plus réactives du marché, le gestionnaire de fenêtres s'exécute automatiquement avec une priorité «Élevée». Maintenant, cela signifie que la mauvaise conduite de ce processus entraînera un retard du système, mais cela signifie également que la mauvaise conduite ailleurs ne le sera pas . J'ai fait planter des applications pour utiliser 100% de chaque cœur de processeur, et l'interface utilisateur sur Windows reste toujours extrêmement réactive.

Fake Name

@Fake Nom: Le Finder ne pas traiter tous les aspects de l'interface utilisateur autre que ses propres fenêtres (dossiers et les icônes de bureau). (Il est possible de quitter le Finder; il a en fait disparu, et tout le reste fonctionne toujours.) SystemUIServer gère uniquement les éléments de droite de la barre de menus et les superpositions de "cadre" (volume / luminosité, etc.). Le rendu et les événements des fenêtres sont entièrement gérés par les processus WindowServer.

Kevin Reid

@Fake Name, à titre de clarification: renicefonctionne sur des processus, pas sur des threads.

Chris Page

J'ai posé une question similaire - il y a longtemps, sur ServerFault - mais pas aussi spécifiquement axée sur le Finder (bien que je trouve que le Finder soit intolérablement lent également). Comment «renier» définitivement un processus sur Mac OS X (ou iOS, etc.)? Peu d'informations y ont été glanées - quant à une bonne façon de le faire… ou quant à la raison pour laquelle cela est tel ..

J'y pense encore souvent, et il y a en fait quelques façons de discuter avec les "bases" si vous osez. Comme mentionné précédemment, vous pouvez faire divers chicaneries shell .. mais un bon endroit pour de tels méfaits sont les diverses /etc/rc*routines de démarrage .. qui sont déjà là-dedans .. définissant toutes sortes de paramètres système arbitraires (définis par Apple) pour vous. modifiez-les ou recherchez comment ajouter vos propres routines au processus de démarrage.

aussi, si vous voulez vraiment faire exploser votre tête ..

sudo sysctl list et c'est la clé de la boîte de Pandore, alias /etc/sysctl.conf

gris alex
la source