> ## Documentation Index > Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Requisitos de hardware ## 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](/es/on-premises/support/troubleshooting). ### 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. | Ejemplo 1 | Ejemplo 2 | | - | - | | Si ejecutas una instalación de Server Pro para 300 usuarios en total y esperas habitualmente que entre 30 y 60 de ellos compilen documentos al mismo tiempo, 8 GB y 7 núcleos (5 núcleos + 5 GB + la base de 2 núcleos y 3 GB) deberían proporcionar recursos suficientes para que tus usuarios disfruten de un nivel de servicio alto y constante. | Como ejemplo de los requisitos de hardware de un despliegue más grande, se ha configurado con éxito una instalación de Server Pro para 1.000 usuarios en total con un único servidor equipado con dos procesadores de 4 núcleos y 32 GB de memoria del sistema. Esto ha sido suficiente para las necesidades del equipo durante el último año de uso. | Los clientes que superen los límites de un único servidor grande pueden consultar [Escalado horizontal](/es/on-premises/maintenance/horizontal-scaling) 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](/es/on-premises/getting-started/what-is-the-overleaf-toolkit). 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](https://docs.gitlab.com/ee/administration/nfs.html) 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`](https://nginx.org/en/docs/ngx_core_module.html#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`](https://nginx.org/en/docs/ngx_core_module.html#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`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (valor predeterminado `4`) * `NGINX_WORKER_CONNECTIONS` para [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (valor predeterminado `768`) * `NGINX_KEEPALIVE_TIMEOUT` para [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#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`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valor predeterminado en upstream) en **nginx-host** * Valor personalizado `NGINX_KEEPALIVE_TIMEOUT=100s`: usa [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.