selenium - Limita el uso de memoria y CPU sin cabeza de Chrome

google-chrome headless (2)

Considera utilizar Docker. Tiene funciones bien documentadas para el uso de umbrales de recursos del sistema como la memoria y la CPU. La buena noticia es que es bastante fácil crear una imagen de Docker con Chromes sin cabeza (en la parte superior de X11) dentro de ella.

Hay muchas soluciones listas para usar en eso, échale un vistazo: https://hub.docker.com/r/justinribeiro/chrome-headless/

Estoy usando selenio para ejecutar chrome sin cabeza con el siguiente comando:

system "LC_ALL=C google-chrome --headless --enable-logging --hide-scrollbars --remote-debugging-port=#{debug_port} --remote-debugging-address=0.0.0.0 --disable-gpu --no-sandbox --ignore-certificate-errors &"

Sin embargo, parece que Chrome Headless consume demasiada memoria y CPU, ¿alguien sabe cómo podemos limitar el uso de CPU / Memory de Chrome Headless? O si hay alguna solución.

Gracias por adelantado.

Hubo mucha discusión sobre la impredecible CPU y el consumo de memoria de las sesiones sin cabeza de Chrome .

De acuerdo con la discusión Construyendo sin cabeza para un uso mínimo de CPU + memoria, el uso de CPU + Memoria se puede optimizar mediante:

Usando un proxy personalizado o C ++ ProtocolHandlers puede devolver imágenes de píxel 1x1 o incluso bloquearlas por completo.
Chromium Team está trabajando en agregar un control programático sobre cuándo se producen los marcos. Actualmente, Chrome sin cabeza aún está intentando renderizar a 60 fps, lo que es un desperdicio. Muchas páginas necesitan algunos cuadros (tal vez 10-20 fps ) para procesarse correctamente (debido al uso de requestAnimationFrame y los animation triggers ) pero esperamos que haya muchos ahorros de CPU aquí.
MemoryInfra debería ayudarlo a determinar qué componente es el mayor consumidor de memoria en su configuración.
Un uso puede ser:

$ headless_shell --remote-debugging-port=9222 --trace-startup=*,disabled-by-default-memory-infra http://www.chromium.org
Chromium siempre va a utilizar todos los recursos disponibles. Si desea limitar de forma efectiva su utilización, debería considerar el uso de cgroups

Habiendo dicho los puntos mencionados anteriormente, aquí se encuentran algunas de las mejores prácticas comunes para adaptarse al ejecutar navegadores sin cabeza en un entorno de producción:

Fig: Uso de recursos volátiles de Headless Chrome

No ejecute un navegador sin cabeza :

Por todas las cuentas, si es posible, simplemente no ejecute un navegador sin cabeza. Los navegadores sin cabeza son imprevisibles y hambrientos. Casi todo lo que puede hacer con un navegador (guardar para interpolar y ejecutar JavaScript) se puede hacer con herramientas simples de Linux. Hay bibliotecas que ofrecen elegantes API de Nodo para obtener datos a través de solicitudes HTTP y raspado si ese es su objetivo final.
No ejecute un navegador sin cabeza cuando no necesite :

Hay usuarios que intentan mantener el navegador abierto, incluso cuando no están en uso, para que siempre esté disponible para las conexiones. Si bien esta podría ser una buena estrategia para ayudar a acelerar el lanzamiento de la sesión, solo terminará en desdicha después de unas horas. Esto se debe en gran parte a que a los navegadores les gusta almacenar cosas en caché y comer lentamente más memoria. Cada vez que no estés usando activamente el navegador, ciérralo!
Paralelizar con navegadores, no páginas :

Solo debemos ejecutar uno cuando sea absolutamente necesario, la siguiente mejor práctica es ejecutar solo una sesión en cada navegador. Si bien es posible que ahorre algo de sobrecarga al paralelizar el trabajo a través de las páginas, si una página falla, puede derribar todo el navegador. Además, no se garantiza que cada página esté totalmente limpia (es posible que las cookies y el almacenamiento se filtren).
page.waitForNavigation :

Uno de los problemas más comunes observados son las acciones que activan una carga de la página y la pérdida repentina de la ejecución de los scripts. Esto se debe a que las acciones que desencadenan una pageload menudo pueden hacer que el trabajo posterior se trague. Para solucionar este problema, generalmente tendrá que invocar la acción de carga de página y esperar inmediatamente la próxima carga de página.
Utilice la ventana acoplable para contener todo :

Chrome necesita muchas dependencias para funcionar correctamente. Incluso después de que todo esté completo, hay cosas como las fuentes y los procesos fantasmas por los que debe preocuparse, por lo que es ideal usar algún tipo de contenedor para contenerlo. Docker está casi hecho a la medida para esta tarea, ya que puede limitar la cantidad de recursos disponibles y hacer un sandbox. Crea tu propio Dockerfile tú mismo.

Y para evitar la ejecución de procesos zombie (lo que suele suceder con Chrome), querrás utilizar algo como dumb-init para iniciar correctamente.
Dos tiempos de ejecución diferentes :

Puede haber dos tiempos de ejecución de JavaScript activados (Nodo y el navegador). Esto es excelente para los fines de la compartición, pero conlleva el costo de la confusión, ya que algunos métodos de página requerirán que pase explícitamente referencias (en lugar de hacerlo con cierres o izar).

Como ejemplo, al usar page.evaluate en las entrañas del protocolo, esto literalmente stringifies la función y la pasa a Chrome, de modo que las cosas como los cierres y la elevación no funcionarán en absoluto. Si necesita pasar algunas referencias o valores a una llamada de evaluación, simplemente agréguelos como argumentos que se manejan adecuadamente.

Referencia: Observaciones ejecutando 2 millones de sesiones sin cabeza.