Pourquoi les processus auxiliaires perturbent les moniteurs de bande passante macOS

Vous ouvrez Activity Monitor un après-midi calme, triez par octets réseau, et le haut de votre liste ressemble à : Google Chrome Helper (Renderer), Google Chrome Helper (GPU), Google Chrome Helper, Slack Helper, Slack Helper (Renderer), Slack Helper (GPU). Pas de ligne pour « Chrome » ou « Slack » — juste un confetti d'auxiliaires, chacun tirant quelques centaines de kilooctets par seconde. Quelle application parle réellement ? Cette confusion est toute la raison pour laquelle l'attribution de bande passante des processus auxiliaires Mac est la partie la plus difficile dans la construction d'un moniteur réseau sur macOS.

Ce billet explique pourquoi les applications lancent des auxiliaires en premier lieu, pourquoi le noyau rapporte leur usage réseau séparément, et ce que « regroupement » signifie quand un outil essaie de vous donner un chiffre propre par application.

Pourquoi les applications lancent des processus auxiliaires

Les applications macOS modernes ne tournent presque jamais comme un seul processus. Il y a trois grandes raisons.

Sandboxing et séparation de privilèges

App Sandbox d'Apple est une frontière par processus. Un rendu qui parse du HTML non fiable ou exécute du JavaScript tourne avec un ensemble d'entitlements différent du parent qui possède votre permission microphone. Si le rendu est compromis par une page malicieuse, le rayon d'action s'arrête à ce processus — il ne peut pas soudain commencer à enregistrer l'audio ou lire votre dossier Documents. C'est pourquoi Chrome et Safari livrent tous deux avec des processus séparés pour chaque onglet ou site, et pourquoi Slack, Discord et Notion (toutes des applications Electron) suivent le même motif.

Isolement des plantages

Si un onglet dans Chrome manque de mémoire ou frappe un bug du moteur JavaScript, vous ne voulez pas que chaque onglet du navigateur meure avec lui. Les processus auxiliaires signifient qu'une seule mauvaise page montre l'écran « Aw, Snap » pour cet onglet et rien d'autre. La même logique s'applique à Slack rendant un canal, ou Discord rendant un appel vocal.

Architecture Electron et Chromium

Si l'application est construite sur Electron — Slack, Discord, VS Code, Notion, Linear, Figma desktop, 1Password 8, Microsoft Teams, Postman — elle hérite en bloc du modèle multi-processus de Chromium. Il y a un processus « principal », un processus « GPU », un processus « Network Service » (souvent appelé Utility), et un processus de rendu par fenêtre de navigateur ou vue significative. Le rendu n'ouvre jamais de socket lui-même. Il parle au service réseau via IPC, et le service réseau fait la vraie poignée de main TCP.

Ce dernier détail compte plus qu'il ne paraît.

Pourquoi l'attribution de bande passante des auxiliaires Mac est difficile

Le noyau macOS attribue les octets au PID qui a appelé socket(2) puis connect(2)/sendto(2)/recvfrom(2). C'est la bonne réponse pour le noyau — il n'a aucune idée de ce que « Slack » signifie en tant que produit. Il sait seulement que le PID 4711 a ouvert une socket vers 34.117.x.x:443.

Donc quand vous demandez à nettop ou lsof -i ou à l'API brute proc_pidinfo « qui a utilisé des octets réseau », vous obtenez en retour une liste plate de PIDs. Chaque PID a un nom de processus (le nom de l'exécutable sur disque), et ce nom est presque toujours quelque chose comme :

• Google Chrome Helper
• Google Chrome Helper (GPU)
• Google Chrome Helper (Renderer)
• Google Chrome Helper (Plugin)
• Slack Helper
• Slack Helper (Renderer)
• Slack Helper (GPU)
• com.docker.backend

Un moniteur naïf — qui se contente de déverser la vue du noyau à l'écran — vous montre exactement cela. Vous voyez sept lignes Chrome qu'il faut additionner mentalement pour répondre à « combien Chrome a-t-il utilisé cette heure ? ». Pire, les rendus sont de courte durée. Fermez un onglet, le rendu meurt. Ouvrez-en un nouveau, un nouveau rendu avec un nouveau PID apparaît. Sommez sur une heure et la réponse est fragmentée à travers des dizaines de PIDs morts. C'est le défi central de l'attribution de bande passante des auxiliaires Mac : les unités que le noyau expose ne correspondent pas aux unités dans lesquelles un humain veut penser.

Ce que « regroupement » signifie

Le regroupement est l'acte de regarder un processus auxiliaire — par son chemin de bundle, son PID parent, ou les deux — et d'attribuer ses octets à l'application visible à laquelle il appartient. Bien fait, vous arrêtez de voir onze lignes Chrome et commencez à voir une ligne appelée « Google Chrome » avec la somme.

Il y a quelques façons de le faire, et chacune a des compromis.

Par chemin de bundle

Chaque auxiliaire vit à l'intérieur du bundle de l'application parente. Pour Chrome, ce chemin est quelque chose comme :

/Applications/Google Chrome.app/Contents/Frameworks/
  Google Chrome Framework.framework/Versions/.../Helpers/
  Google Chrome Helper.app/Contents/MacOS/Google Chrome Helper

Si le chemin de l'exécutable d'un processus contient un autre bundle .app plus haut dans l'arbre, le bundle externe est presque certainement le parent. C'est le signal de regroupement le plus fiable parce qu'il survit aux changements de PID — ouvrez un nouvel onglet Chrome, le chemin du nouveau rendu est encore sous Google Chrome.app.

Par PID parent

Vous pouvez remonter l'arbre des processus jusqu'à frapper un parent qui vit dans /Applications ou dont l'identifiant de bundle correspond à une « vraie » application. Cela marche mais est plus fragile — launchd reparente les processus orphelins, et certains auxiliaires sont lancés par des services XPC plutôt que directement par le parent.

Par préfixe d'identifiant de bundle

L'ID de bundle de Slack est com.tinyspeck.slackmacgap. L'ID de bundle de l'auxiliaire est com.tinyspeck.slackmacgap.helper ou com.tinyspeck.slackmacgap.helper.renderer. Une correspondance par préfixe contre la table des applications installées attrape la plupart des cas. C'est la technique qu'Apple utilise en interne pour certains rapports destinés aux utilisateurs.

En pratique, un bon moniteur utilise les trois signaux et retombe gracieusement quand l'un manque.

Voyez ova en action

Un moniteur de bande passante en barre de menu consultable d'un coup d'œil — local, signé, ~3 Mo.

Télécharger pour macOS

Le cas spécial Electron

Les applications Electron méritent leur propre paragraphe parce qu'elles sont très courantes. Un auxiliaire Electron nommé Slack Helper (Renderer) n'ouvre pas réellement de sockets — c'est le service réseau, généralement appelé Slack Helper (sans suffixe) ou Slack Helper (Plugin) selon la version d'Electron. Le rendu parle au service réseau via le bus IPC Mojo de Chromium.

Donc si vous ne voyez jamais de trafic que sur le Slack Helper nu, ce n'est pas un bug — c'est l'architecture. Le rendu fait la requête, mais le noyau voit le service réseau faire l'I/O. Du point de vue utilisateur les deux devraient se regrouper sous « Slack ». D'un point de vue débogage, savoir cela vous économise un après-midi quand vous vous demandez pourquoi le rendu ne s'allume pas.

Pareil pour Chrome lui-même : dans les versions récentes de Chrome, presque tout le trafic réseau vient de Google Chrome Helper (Plugin) ou de l'auxiliaire de service réseau, pas des rendus par onglet.

Pourquoi vous ne pouvez pas faire confiance aux totaux simples

Une fois que vous comprenez les auxiliaires, quelques questions courantes deviennent plus faciles à répondre.

« Pourquoi mon usage Chrome a-t-il l'air bas ? » Parce que les octets sont répartis sur une douzaine d'auxiliaires, et votre moniteur ne les somme pas. Chaque auxiliaire individuel a l'air modeste.

« Pourquoi 200 Mo sont apparus soudainement sous un processus que je ne reconnais pas ? » Probablement un rendu pour un flux vidéo, un service XPC gérant la synchro (CloudKit, iCloud, Dropbox), ou un démon système faisant du travail d'arrière-plan. Regardez le chemin de l'exécutable, pas seulement le nom.

« Pourquoi la même application apparaît-elle sous deux noms différents à travers les redémarrages ? » Certains auxiliaires incluent un numéro de version ou un UUID dans leur nom de processus. La plupart des moniteurs les enlèvent, mais pas tous.

Regroupement en pratique — et quand le défaire

Un moniteur qui regroupe les auxiliaires vous montre quelque chose comme :

Google Chrome    412 MB ↓   18 MB ↑
Slack             89 MB ↓    4 MB ↑
Spotify           62 MB ↓  120 KB ↑
Dropbox           34 MB ↓   12 MB ↑

… au lieu de :

Google Chrome Helper (Renderer)   38 MB ↓
Google Chrome Helper (GPU)         2 KB ↓
Google Chrome Helper (Plugin)    220 MB ↓
Google Chrome Helper             140 MB ↓
Google Chrome Helper (Renderer)   12 MB ↓
Slack Helper (Renderer)           41 MB ↓
Slack Helper                      48 MB ↓
... (continue pendant 30 lignes de plus)

Le premier est ce que vous voulez vraiment. ova fait ce regroupement automatiquement — il groupe chaque PID auxiliaire sous le bundle parent pour que vous lisiez « Slack » au lieu de sept lignes d'auxiliaires.

Quand vous voulez vraiment voir les auxiliaires

Il y a un cas où le regroupement gêne : déboguer une application qui se comporte mal. Si vous êtes un développeur essayant de déterminer quel processus Chromium fuit des sockets, ou si votre rendu contourne le service réseau, vous voulez la vue brute.

Un moniteur utile vous laisse cliquer dans la ligne regroupée et voir les auxiliaires sous-jacents — octets par auxiliaire, PID actuel, chemin complet de l'exécutable. Ainsi la vue par défaut est propre, mais le détail est à un clic.

C'est aussi utile pour diagnostiquer les plantages : un auxiliaire qui redémarre toutes les 30 secondes et rétablit des sessions TLS peut accumuler un trafic d'arrière-plan surprenant, et c'est seulement visible quand vous pouvez voir l'historique au niveau auxiliaire.

Pas à pas : enquêter sur un mystère Slack

Supposez que Slack montre 600 Mo téléchargés aujourd'hui et que vous n'avez regardé aucune vidéo. Voici l'ordre dans lequel je vérifierais.

1. Vérifiez le motif heure-de-la-journée. Un pic à 9 h est probablement la synchro de rattrapage du matin. Une courbe plate sur 24 heures est plus intéressante.
2. Vérifiez la répartition par auxiliaire. Si c'est 90 % dans Slack Helper (Plugin) (le service réseau), c'est du trafic « réel » de l'application. Si c'est réparti à travers les rendus de manière étrange, vous pourriez avoir un onglet fuyant ouvert.
3. Vérifiez le nombre d'espaces de travail. Chaque espace de travail Slack ajoute un WebSocket persistant et son propre cache d'avatars/fichiers. Trois espaces de travail c'est grossièrement 3x le trafic au repos d'un seul.
4. Vérifiez l'historique des partages d'écran ou huddles. Les huddles utilisent WebRTC et avalent 1-3 Mo/s pendant qu'ils sont actifs.

Vous n'avez besoin de capture de paquets pour rien de cela. Vous avez besoin d'un moniteur par application qui regroupe les auxiliaires et garde une heure d'historique.

Pour conclure

Les processus auxiliaires ne sont pas une particularité à contourner — c'est ainsi que les applications macOS modernes restent sûres et stables. Le coût est que la vue du noyau de « qui a utilisé le réseau » se lit comme une liste plate cryptique, et c'est pourquoi la comptabilité de bande passante des auxiliaires Mac fait trébucher chaque outil généraliste. Tout moniteur de bande passante décent sur macOS doit faire le regroupement des auxiliaires, et tout celui qui ne le fait pas vous laissera additionner mentalement les lignes pour le reste de votre vie.

Si votre outil actuel vous montre les lignes brutes des auxiliaires et que vous en avez assez de lire « Google Chrome Helper (Renderer) » pour la millième fois, installez ova — il s'installe dans la barre de menu à environ 3 Mo, échantillonne à environ 1 Hz, et regroupe les auxiliaires automatiquement. Toutes les données restent sur votre Mac. macOS 14 et ultérieur, Apple Silicon et Intel.