Mémoire des BrowserContext avec Chromium 151

Une nouvelle donnée de capacité

De nombreux services d'automatisation regroupent plusieurs BrowserContext actifs dans un même navigateur. Chaque contexte conserve son stockage et sa session applicative, tandis que le groupe partage le démarrage du navigateur. Ce modèle peut réduire le travail répété, mais son coût dépend aussi de la version du navigateur.

Dans certaines versions Chromium 151 à partir de 151.0.7922.108, les charges headless ou d'automatisation qui gardent beaucoup de contextes ouverts ont une base mémoire plus élevée. Un contexte actif peut s'accompagner d'un renderer supplémentaire lié à l'interface du navigateur. La mémoire augmente donc avec le nombre de contextes actifs, même lorsque la page n'a pas changé.

Ce comportement ne décrit pas toutes les versions, toutes les plateformes ni toutes les charges. La comparaison Linux x64 ci-dessous fournit un ordre de grandeur à mesurer, pas une garantie. Répétez la mesure avec la version, l'hôte, le profil et la charge réellement prévus.

Lire la comparaison

Sur un hôte Linux x64, 151.0.7922.76 n'affichait pas le renderer UI omnibox supplémentaire dans cette charge, avec environ 120 MB par contexte actif. La comparaison 151.0.7922.138 affichait ce renderer et environ 289 MB par contexte. L'écart observé était donc proche de 169 MB par contexte. Le renderer supplémentaire représentait souvent 250 à 280 MB dans ces exemples.

Ces valeurs varient avec les pages, les médias, les téléchargements, les workers et les documents. Ajoutez la mémoire partagée du navigateur et la variation de la charge. Le modèle utile est une base partagée plus une pente mesurée par contexte, mais il ne faut pas en faire une constante universelle.

Le guide Adapter la charge avec les profils Per-Context traite des files, du cycle de vie et de l'isolation. Ici, la version Chromium devient une donnée supplémentaire du dossier de capacité.

Vérifier une mise à jour

Avant la promotion, consignez la version, le système et l'architecture, l'hôte, les limites du conteneur, le mode graphique, la politique de profils, les extensions, le réseau et la classe de tâche. Rejouez la même tâche sur la version acceptée et la candidate.

Mesurez le groupe avant la création, pendant la création, en activité stable, en attente et après la fermeture. Notez le total du groupe et le nombre de contextes actifs. La création peut produire un pic temporaire. La fermeture peut être asynchrone, donc ne rendez pas un emplacement avant la fin du nettoyage.

Le comportement confirmé n'est pas une fuite permanente. Après la fermeture d'un contexte, le processus supplémentaire peut être libéré. Le coût reste toutefois présent tant que le contexte reste ouvert. Une création plus rapide que la fermeture peut conduire à l'OOM. Suivez mémoire disponible, pression mémoire, CPU, latences, file d'attente, réussites et redémarrages.

La validation des versions du navigateur aide à associer version et paquet de profils. Pour un travail avec séparation d'identité, consultez aussi la documentation Per-Context.

Mesure temporaire au démarrage

Pour la charge concernée, essayez ensemble les deux noms suivants :

--disable-features=WebUIOmniboxPopup,WebUIOmniboxAimPopup

Cette option concerne l'interface de la barre d'adresse du navigateur. Elle ne modifie ni le JavaScript, ni le DOM, ni le CSS de la page. En headless, l'effet visible est généralement nul. L'option reste temporaire et doit être mesurée sur la version cible.

Une autre option peut réduire la mémoire sans retirer le processus supplémentaire :

--disable-features=PreloadTopChromeWebUI

Elle ne constitue donc pas une solution complète. Un futur déploiement Chromium peut retirer ou ignorer ces options. Ce n'est pas une correction propre à BotBrowser. Observez la mémoire réelle après le démarrage et ne transformez pas l'option en dépendance permanente.

Dimensionner avec une marge

Partez de la mémoire disponible sur l'hôte, pas de la mémoire installée. Réservez l'espace du système, du superviseur, des journaux, du réseau, du cache et de la récupération. Déduisez ensuite la base partagée et la variation de charge. Le reste forme le budget des contextes actifs.

Lorsque la marge baisse, arrêtez l'admission et utilisez une file bornée. Une nouvelle demande peut attendre une durée définie, recevoir une réponse de capacité ou aller vers un groupe approuvé. Les nouvelles tentatives suivent la même règle. Cadencez la création pour éviter un pic de démarrage.

Le service qui crée un contexte doit le fermer, libérer son bail et confirmer le nettoyage. Si la fermeture dépasse le délai observé, drainez le groupe puis remplacez-le selon la politique. Augmenter la limite ne résout pas une propriété incertaine des ressources. Les pratiques générales sont détaillées dans Optimiser les performances.

Première mise en production

Conservez la version précédente jusqu'à la fin de l'observation. Déployez la candidate sur un petit groupe et suivez mémoire, contextes actifs, latence de création et de fermeture, âge de file et travail terminé. Si la pression augmente, suspendez l'admission avant de drainer les groupes concernés.

Après le déploiement, confirmez que la fermeture libère bien le processus supplémentaire et que l'hôte revient dans sa plage de reprise. Recommencez après tout changement de navigateur, d'hôte, de profil, de page, d'extension, de graphique ou de réseau. La page tarifaire décrit les capacités du plan, mais elle ne remplace pas la mesure de la mémoire de l'hôte.

Chromium 151 peut donc fonctionner avec des BrowserContext, à condition que la limite soit fondée sur une mesure par version et par charge. Le coût supplémentaire existe pendant la vie du contexte, sa libération aide la reprise, et l'option de démarrage ne vaut que comme mesure temporaire validée.