Skip to main content

​
Requisitos de hardware

Al aprovisionar hardware para ejecutar Overleaf, el factor principal a tener en cuenta es cuántos usuarios simultáneos ejecutarán compilaciones. Por ejemplo, si tienes una licencia para 100 usuarios en total, pero solo esperas que unos ~5 trabajen al mismo tiempo, la instalación mínima será suficiente. Si esperas que una proporción mayor trabaje (y compile) simultáneamente, deberías considerar aprovisionar un servidor con especificaciones más altas.

​
Instalación mínima

Se necesita un requisito base mínimo de 2 núcleos y 3 GB de memoria para las operaciones básicas con unos 5 usuarios simultáneos. Este requisito mínimo también será suficiente para grupos más grandes con menos uso simultáneo, o en los que se acepte que los tiempos de compilación sean más largos durante los periodos de uso intenso.
Si estás pensando en usar un sistema de archivos basado en NFS (Network File System) para tu instancia pequeña, consulta este apartado de la sección Solución de problemas.

​
Escalado

Como regla general, para ofrecer un nivel de servicio alto y constante, se debe añadir 1 núcleo de CPU y 1 GB de memoria a la instalación mínima por cada 5-10 usuarios simultáneos. Esto debe tomarse solo como orientación, ya que factores como el tamaño de los documentos habituales (los documentos más grandes consumen más recursos de compilación), la frecuencia con la que compilan los usuarios y la tolerancia a tiempos de compilación más largos durante el uso intenso afectan al nivel de aprovisionamiento necesario. Muchos de nuestros clientes buscan desplegar Server Pro en toda la organización o en equipos grandes. En esas situaciones, nos resulta difícil aconsejar requisitos de configuración concretos, porque los casos de uso y el hardware disponible pueden ser muy variados. Los clientes que superen los límites de un único servidor grande pueden consultar Escalado horizontal para Server Pro.

​
Almacenamiento

Desaconsejamos usar Network File System (NFS)/Amazon EFS/Amazon EBS para el almacenamiento de proyectos e historial en configuraciones grandes y explícitamente no lo admitimos para el escalado horizontal. El comportamiento de estos sistemas de archivos no proporciona el rendimiento ni la fiabilidad que Server Pro necesita cuando funciona a gran escala. Cuando el sistema de archivos no puede soportar la carga, la aplicación se bloquea por demasiadas operaciones de E/S bloqueantes. Estos bloqueos pueden provocar que se excedan los bloqueos (locks) basados en Redis, lo que a su vez puede dar lugar a datos de proyecto corruptos. En su lugar, recomendamos usar almacenamiento de objetos compatible con S3. Un rendimiento lento de S3 solo afecta a la subida y descarga de archivos, lo que únicamente provoca un mayor número de conexiones abiertas con tu proveedor de S3 y no afecta al comportamiento del resto de la aplicación. Además, Server Pro puede especificar tiempos de espera razonables en las solicitudes a S3, algo que no es posible para las operaciones de sistema de archivos/E/S a nivel de aplicación.
Como referencia, GitLab sigue una postura similar de no admitir NFS/Amazon EFS en su oferta autogestionada.

​
Configuración específica de Nginx para despliegues grandes

De forma predeterminada, las instancias de Overleaf Server limitan el número de conexiones a 768. Esto incluye las conexiones Websocket persistentes, la navegación HTML de nivel superior y las solicitudes ajax. Cuando se alcanza el límite, es posible que el editor no pueda conectarse, que la página del editor no se cargue por completo y que las solicitudes de compilación fallen. Nginx devolverá respuestas con estado 500 y registrará worker_connections are not enough while connecting to upstream en var/log/nginx/error.log dentro del contenedor sharelatex. El ajuste worker_connections limita el número de conexiones simultáneas que nginx aceptará por worker. El número de workers se controla con el ajuste worker_processes y está establecido en 4 de forma predeterminada en nuestra configuración de nginx. Nginx no realiza mucho trabajo en comparación con otras partes del sistema, por lo que estos límites actúan como una medida de seguridad que impide que demasiadas conexiones saturen el sistema. Es preferible descartar pronto algunas conexiones excedentes que ralentizar todas las conexiones. Las instancias de Overleaf Server exponen variables de entorno para ajustar esta configuración de nginx:
  • NGINX_WORKER_PROCESSES para worker_processes (valor predeterminado 4)
  • NGINX_WORKER_CONNECTIONS para worker_connections (valor predeterminado 768)
  • NGINX_KEEPALIVE_TIMEOUT para keepalive_timeout (valor predeterminado 65)
    Si ejecutas otro proxy delante del contenedor sharelatex (p. ej., para la terminación TLS), el valor de NGINX_KEEPALIVE_TIMEOUT en la instancia de Overleaf Server debe ser mayor que el del proxy anterior. Por ejemplo, con otro proceso nginx en el host de Docker nginx-host, estos son dos ejemplos:
  • Valor predeterminado de NGINX_KEEPALIVE_TIMEOUT: usa keepalive_timeout 60s (valor predeterminado en upstream) en nginx-host
  • Valor personalizado NGINX_KEEPALIVE_TIMEOUT=100s: usa keepalive_timeout 90s (valor personalizado en upstream) en nginx-host

​
Velocidad de la CPU

LaTeX es un programa de un solo hilo, lo que significa que solo puede utilizar un núcleo de CPU a la vez. La CPU es también la principal limitación al compilar un documento. Por lo tanto, cuanto mayor sea el rendimiento de un solo núcleo de tu CPU, más rápido podrás compilar un documento. Más núcleos solo ayudarán si intentas compilar más documentos que núcleos de CPU libres tienes.
Last modified on October 4, 2026