Memoria de BrowserContext con Chromium 151

Una nueva variable de capacidad

Muchos servicios de automatización agrupan varios BrowserContext activos en un navegador. Cada contexto mantiene su almacenamiento y sesión de aplicación, mientras el grupo comparte el arranque. Este modelo puede reducir trabajo repetido, pero su coste también depende de la versión del navegador.

En algunas compilaciones de Chromium 151 desde 151.0.7922.108, las cargas headless o de automatización con muchos contextos activos presentan una base de memoria mayor. Un contexto activo puede venir acompañado de un renderer adicional de la interfaz del navegador. Por eso la memoria crece con el número de contextos aunque la página no haya cambiado.

Esto no describe todas las versiones, plataformas ni cargas. La comparación Linux x64 es solo una referencia de magnitud. Mide la versión, el host, el perfil y la carga que realmente utilizarás.

Qué muestran los datos

En un host Linux x64, 151.0.7922.76 no mostró el renderer UI omnibox adicional en esta carga y registró unos 120 MB por contexto activo. La comparación con 151.0.7922.138 sí mostró el renderer adicional y unos 289 MB por contexto. La diferencia observada fue cercana a 169 MB por contexto. En estos ejemplos, el renderer adicional solía representar entre 250 y 280 MB.

No son constantes universales. Las páginas con medios, documentos, descargas, workers o aplicaciones grandes cambian el resultado. Suma la memoria compartida del navegador y la variación de la carga. El modelo sirve para organizar las mediciones, no para prometer una capacidad fija.

La guía Escalar BrowserContext con perfiles por contexto cubre colas, ciclos de vida y aislamiento. En este caso, la versión de Chromium es una variable más del registro de capacidad.

Comprobar una actualización

Antes de promover una compilación, registra versión, sistema y arquitectura, host, límites del contenedor, modo gráfico, política de perfiles, extensiones, red y clase de tarea. Repite la misma transacción en la versión aprobada y en la candidata.

Mide el grupo antes de crear contextos, durante la creación, en actividad estable, durante la espera y después del cierre. Anota el total del grupo y el número de contextos activos. La creación puede causar un pico breve y el cierre puede tardar, así que no devuelvas el cupo hasta completar la limpieza.

El comportamiento confirmado no es una fuga permanente. Al cerrar el contexto, el proceso adicional puede liberarse. Mientras el contexto siga abierto, su coste sigue presente. Si se crean contextos más rápido de lo que se cierran, el host puede llegar a OOM. Observa memoria disponible, presión, CPU, latencias, cola, resultados y reinicios.

Usa Validación de versiones del navegador para mantener juntos la versión y el paquete de perfiles. En sesiones con separación de identidad, revisa la documentación Per-Context.

Mitigación temporal de arranque

Para la carga afectada, pasa juntos estos dos nombres:

--disable-features=WebUIOmniboxPopup,WebUIOmniboxAimPopup

La opción modifica la interfaz propia de la barra de direcciones. No cambia el JavaScript, el DOM ni el CSS de la página. En headless normalmente no hay un efecto visible. Aun así, es una medida temporal y debe medirse en la versión objetivo.

También existe esta opción:

--disable-features=PreloadTopChromeWebUI

Puede reducir la memoria del proceso adicional, pero no lo elimina, por lo que no es una solución completa. Un futuro rollout de Chromium puede quitar o ignorar las opciones. No es una corrección exclusiva de BotBrowser: observa la memoria real después de arrancar y repite la comprobación en cada cambio relevante.

Proteger el margen de recuperación

Parte de la memoria disponible del host, no de la memoria instalada. Reserva espacio para el sistema, el supervisor, los registros, la red, la caché, la recuperación y el pico de creación. Después resta la base compartida y la variación de la carga. El resultado es el presupuesto para contextos activos.

Cuando se alcanza el límite, usa una cola acotada. Una petición puede esperar un tiempo definido, recibir una respuesta de capacidad o ir a otro grupo aprobado. Los reintentos aplican la misma regla. Crea contextos de forma gradual para evitar un pico de inicialización.

El servicio que crea un contexto debe cerrarlo, liberar su asignación y confirmar la limpieza. Si se supera el plazo de cierre, drena y reemplaza el grupo según la política. Subir el límite no resuelve una propiedad incierta de los recursos. Consulta Optimización del rendimiento para prácticas generales de ciclo de vida.

Primera puesta en producción

Conserva la versión anterior hasta terminar la observación. Despliega la candidata en un grupo pequeño y vigila memoria, contextos activos, memoria disponible, latencias de creación y cierre, antigüedad de cola y trabajo terminado. Si aumenta la presión, pausa la admisión antes de drenar los grupos afectados.

Después confirma que cerrar contextos libera el proceso adicional y que el host vuelve a su margen esperado. Repite tras cualquier cambio de navegador, host, perfil, página, extensión, gráficos o red. La página de precios describe la capacidad del plan, pero no sustituye la medición de memoria del host.

Chromium 151 puede operar con BrowserContext si el límite se basa en mediciones por versión y carga. El renderer adicional tiene un coste real mientras el contexto está activo, su liberación ayuda a recuperar capacidad y el parámetro de arranque solo debe usarse como medida temporal validada.