OpenClaw 2026 : parallélisme des appels d’outils sur la passerelle, budget de descripteurs de fichiers et réglage d’ulimit macOS — pools de workers, sémaphores, LaunchAgent SoftResourceLimits, prévention EMFILE, coordination avec budgets jetons, diagnostics doctor et tests de charge sur Mac mini cloud

Chaque passerelle OpenClaw qui exécute des outils de type MCP via des sous-processus finit par rencontrer EMFILE. Ce n’est généralement pas la cruauté du système d’exploitation, mais l’arithmétique : la parallélisation multipliée par les tuyaux, sockets et fichiers journaux remplit la table des descripteurs par processus plus vite que les équipes ne l’anticipent. En 2026, associez un sémaphore de workers borné à une marge honnête sur ulimit -n, puis alignez ces chiffres sur les garde-fous budgétaires décrits dans budgets jetons et limitation d’outils OpenClaw et sur la boucle de triage de openclaw doctor diagnostics passerelle. Les pics de concurrence cesseront alors de se déguiser en pannes mystérieuses en amont.

Cet article fournit des garde-fous concrets : par défaut huit processus enfants concurrents par worker de passerelle sur un Mac mini 8 Go, 256 descripteurs réservés à la pile HTTP et aux métriques, et une répétition générale sur du matériel Apple loué à environ 16,9 $ par jour avant de toucher aux tenants de production.

Modèle de processus et consommation FD cachée

Chaque sous-processus hérite de trois flux standard, souvent dupliqués lorsque vous branchez des PTY, plus les sockets vers le fournisseur de modèle, les scrapes Prometheus, le fan-out WebSocket optionnel, les journaux rotatifs, et les connexions SQLite ou Redis. Un fan-out naïf en 32 voies peut donc allouer plus de 1000 descripteurs avant même que les outils utilisateur n’ouvrent des fichiers. Documentez le nombre de connexions longues par canal d’intégration dans la revue d’architecture pour éviter que les scrapers de métriques ne volent le même budget FD que les clients de file d’attente.

Sans cette transparence, les équipes blâment volontiers le réseau alors que la réalité est simplement mathématique : vous avez autorisé plus d’outils concurrents que la somme des paires de tuyaux et des sessions TLS ne peut en absorber.

Sémaphores workers et files équitables

Centralisez un sémaphore de comptage autour de l’exécuteur d’outils : acquisition avant exec, libération sur tous les chemins defer y compris annulation par signal. Préférez l’équité FIFO au sein d’un locataire tout en permettant des priorités pondérées pour les tâches de réparation admin afin que l’automatisation marketing ne bloque pas les ponts d’incident.

Exposez des métriques de temps d’attente au sémaphore par locataire ; sinon vous optimisez pour le client le plus bruyant et négligez les équipes plus petites.

Profil	Plafond parallèle	Justification
Lectures disque	12	Sweet spot de profondeur de file NVMe Apple
Crawlers réseau	6	Chaque socket TLS coûte des FD supplémentaires
Compilations CPU	2× cœurs perf	La marge thermique domine le débit

Limites soft et hard sur macOS

Exécutez launchctl limit maxfiles avant et après modifications. Les shells interactifs montrent souvent des soft defaults de 256 tandis que les serveurs exigent des soft à 10240 avec un hard identique—documentez les deux sur la page de garde du runbook.

Les hard limits ne remplacent pas la fermeture propre des sockets : elles ne font que retarder l’échec suivant lorsque des fuites persistent.

Plist LaunchAgent SoftResourceLimits

Livrez SoftResourceLimits avec NumberOfFiles aligné sur votre calcul de sémaphore plus 20 % de marge pour les rafales courtes. Associez ThrottleInterval pour éviter les tempêtes exec lorsque la configuration est incorrecte.

Versionnez les plists dans le même pipeline CI que les binaires pour éviter que l’ajout d’un agent d’observabilité ne crée des divergences silencieuses.

Détecter rapidement les fuites de descripteurs

Échantillonnez lsof -p $GATEWAY_PID toutes les 60 secondes pendant les tests de trempage et différenciez les sockets CLOSE_WAIT. Alerte lorsque les descripteurs ouverts dépassent 70 % du soft limit pendant plus de cinq minutes, en joignant les SHA des trois derniers déploiements.

Les fuites apparaissent souvent d’abord comme des trous de monitoring lorsque le client Prometheus ne peut plus ouvrir de sockets.

Profils liés à l’IO versus CPU

Balisez les outils dans les manifestes avec io_bound ou cpu_bound afin que l’ordonnanceur applique des sémaphores distincts. Un plafond unique affame les utilitaires shell sensibles à la latence derrière de longs jobs ffmpeg.

Le profilage sur Apple Silicon montre souvent que les charges IO bénéficient de légers sur-abonnements jusqu’à saturation de la file NVMe.

Profondeur de file et backpressure

Exportez gateway_tool_queue_depth en jauge et alertez lorsque le 95e percentile dépasse 50 jobs pendant plus de dix minutes. Incluez la position dans la file dans les journaux structurés pour que le support rassure les utilisateurs sans SSH.

Répercutez aussi la backpressure dans les en-têtes HTTP ou les métadonnées gRPC pour encourager les clients à adopter un backoff exponentiel.

Liste de déploiement

1. Capturer le ulimit -n actuel depuis le PID parent de production.
2. Réduire d’abord la concurrence en staging et mesurer la latence p95 des outils.
3. N’augmenter les soft limits qu’après 72 heures sans régression de fuite.
4. Relancer les sondes doctor pour vérifier la connectivité des canaux.

Isolation multi-locataire sur Mac mini partagé

Lorsque plusieurs équipes partagent un hôte, partitionnez les sémaphores par groupe Unix ou espace de noms d’environnement afin qu’un locataire d’automatisation déréglé n’épuise pas le pool global—réservez au moins 30 % pour les sessions interactives et comptabilisez cette réserve comme tampon incident dans les tableaux financiers.

Documentez quels locataires sont autorisés à faire des rafales et lesquels ont des SLA de latence stricts pour arbitrer en cas de saturation.

Attentes sur le harness de benchmark

Les harness synthétiques doivent augmenter la parallélisation par paliers de +4 toutes les cinq minutes tout en enregistrant la puissance du package CPU et le duty cycle des ventilateurs. Apple Silicon throttle plus tôt lorsque les résidents GPU entrent en collision avec les charges d’outils.

Sans rotation de journaux ni handshakes TLS réalistes, les benchmarks sous-estiment souvent la consommation de FD de 25 à 40 %.

Coordination avec les throttles et les 429 amont

Une forte parallélisation amplifie les limites de débit amont décrites dans le guide limitation par jetons. Lorsque les 429 explosent, baissez temporairement la parallélisation avant d’allonger les backoff afin d’améliorer la latence perçue dans les deux dimensions.

Les équipes finance doivent savoir que la capacité amont coûte plus cher qu’un simple plafond de sémaphore.

Observabilité et playbooks d’astreinte

Attachez des exemplaires aux histogrammes reliant le nombre d’outils concurrents à l’usage FD afin que le commandant d’incident distingue « trop d’outils » de « sockets qui fuient » dans les cinq premières minutes.

Les playbooks doivent contenir des commandes prêtes à coller pour les filtres lsof et des liens Grafana.

Interactions avec la sandbox de sécurité

Les profils Seatbelt qui dupliquent des descripteurs IPC peuvent compter doublement contre les limites—validez les profils sur des passerelles de staging avant d’appliquer des plafonds plus stricts en production.

La sécurité veut souvent plus d’isolation ; l’exploitation a besoin de budgets FD stables : un comité conjoint évite les surprises.

Dérive documentaire

Maintenez un tableau Markdown unique listant les valeurs de sémaphore par famille d’outils ; une documentation obsolète pousse les opérateurs à augmenter les limites au lieu de corriger les fuites.

Des checks CI peuvent bloquer les PR qui oublient de mettre à jour ce tableau.

Pression vnode et répertoires temporaires

Les outils qui créent des milliers de fichiers scratch sous /var/folders peuvent épuiser le cache vnode alors que la table FD semble saine. Surveillez sysctl vfs.numvnodes pendant la CI et imposez un quota de 10000 fichiers par job sauf manifeste explicite.

Privilégiez les extracteurs streaming pour ne pas saturer inodes et vnodes.

Surveillance de répertoires kqueue

Les passerelles qui observent l’espace de travail avec kqueue allouent un descripteur par chemin surveillé. Réduisez les montres récursives à une racine unique avec filtrage userspace lorsque les dépôts dépassent 5000 fichiers suivis.

Les watchers façon IDE sont des multiplicateurs classiques de FD.

Flux gRPC et multiplexage HTTP/2

Chaque flux multiplexé consomme quand même des tampons de fenêtre ; gardez les flux sortants concurrents sous 100 par connexion amont pour éviter le churn des trames SETTINGS qui monte le CPU sur les cœurs d’efficacité M-series.

Alignez les limites de connexion HTTP/2 sur les SLA fournisseur.

Pools de connexions Redis

Les files centralisées ouvrent souvent une connexion Redis par thread worker—limitez le pool à 32 connexions partagées sur un hôte 8 Go et vérifiez la reprise de session TLS pour que les reconnexions ne multiplient pas les handshakes.

Les clusters Redis multi-shards ajoutent de la complexité arithmétique : chaque fragment compte dans le même plafond global.

Fenêtres de déploiement roulant

Pendant les déploiements roulants, l’overlap binaire double brièvement l’usage des descripteurs ; augmentez les soft limits de 15 % pendant la fenêtre de maintenance ou réduisez la parallélisation sur deux intervalles de scrape.

Communiquez ces fenêtres sur la page de statut pour gérer les attentes client.

Macros support pour erreurs visibles

Lorsque les utilisateurs voient « trop de fichiers ouverts », répondez avec des macros citant openclaw doctor, les plafonds de sémaphore et les clés plist exactes—dans les environnements matures cela réduit les tickets dupliqués d’environ 40 %.

Formez le support à distinguer pics transitoires et fuites persistantes via captures Grafana.

Tableur de capacité pour démarrer

Modélisez le pire cas comme (workers × tools_parallel × (3 tuyaux + 2 journaux + 2 sockets)) + fixed_overhead. Avec huit workers et une parallélisation huit, la partie fixe approche déjà 1500 descripteurs avant charge utilisateur—ajoutez 25 % de marge avant de choisir les plafonds plist et révisez chaque trimestre car chaque nouveau canal ajoute des connexions longues.

Les validations finance doivent lier chaque hausse de limite à un ticket qui corrige une fuite réelle.

Affichez ces chiffres à côté du tableau de bord SLO pour expliquer pourquoi une demande de « doubler la concurrence » est refusée avant les lancements majeurs, les audits, les pics de trafic des fêtes ou les fenêtres de maintenance fournisseur.

Les locations de Mac mini Apple Silicon via MacHTML offrent une héritance launchd fidèle à la production, un buffering de tuyaux réaliste et une charge soutenue silencieuse—idéal pour valider la mathématique des sémaphores avant le Black Friday. À environ 16,9 $ par jour, les équipes finance traitent les expériences de capacité comme de l’OpEx plutôt que du CapEx, tout en conservant une introspection root sur les tables de fichiers.

Des fenêtres de location flexibles permettent aussi de cloner une passerelle de type production sur du matériel isolé lors du debug de régressions FD sans risquer les clusters de staging partagés.