> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/es/primeros-pasos/requirements/hardware-requirements.md). # Requisitos de hardware ## Requisitos de hardware Al aprovisionar hardware para ejecutar Overleaf, el principal factor a considerar es cuántos usuarios concurrentes estarán realizando compilaciones. Por ejemplo, si tienes una licencia para 100 usuarios en total, pero solo esperas que \~5 trabajen al mismo tiempo, la instalación mínima será suficiente. Si esperas que una proporción mayor esté trabajando (y compilando) simultáneamente, deberías considerar aprovisionar un servidor con una especificación superior. ### Instalación mínima Se requiere un requisito mínimo básico de 2 núcleos y 3 GB de memoria para las operaciones básicas con alrededor de 5 usuarios concurrentes. Este requisito mínimo también será suficiente para grupos más grandes donde haya menos uso concurrente, o donde esté bien que los tiempos de compilación sean más largos durante un uso intensivo. {% hint style="danger" %} Si estás considerando usar un sistema de archivos basado en NFS (Network File System) para tu instancia pequeña, por favor consulta esta sección en la [Solución de problemas](/on-premises/es/soporte/troubleshooting.md) sección. {% endhint %} ### Escalado Como regla general, para proporcionar un nivel de servicio alto y constante, se debería añadir 1 núcleo de CPU y 1 GB de memoria a la instalación mínima por cada 5-10 usuarios concurrentes. Esto solo debe tomarse como una guía, ya que factores como el tamaño de los documentos típicos (los documentos más grandes consumen más recursos de compilación), con qué frecuencia compilan los usuarios y qué tolerancia existe para tiempos de compilación más largos durante un uso intensivo, afectan al nivel de aprovisionamiento requerido. 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 específicos de configuración, porque los casos de uso y el hardware subyacente disponible pueden variar bastante. | Ejemplo 1 | Ejemplo 2 | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Si estás ejecutando una instalación de Server Pro para 300 usuarios en total, y esperas regularmente que 30-60 de esos usuarios estén compilando documentos al mismo tiempo, 8 GB y 7 núcleos (5 núcleos + 5 GB + base de 2 núcleos y 3 GB) deberían proporcionar recursos suficientes para que tus usuarios tengan un nivel de servicio alto de forma constante. | Para dar un ejemplo de los requisitos de hardware para una implementación más grande, una instalación de Server Pro para 1.000 usuarios en total se ha configurado con éxito usando un solo servidor aprovisionado 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 estén superando los límites de un solo servidor grande pueden echar un vistazo a [Escalado horizontal](/on-premises/es/mantenimiento/horizontal-scaling.md) para Server Pro. ### Almacenamiento Desaconsejamos usar Network File System (NFS)/Amazon EFS/Amazon EBS para el almacenamiento de proyectos/historial en configuraciones más grandes y explícitamente **no lo admitimos** para el escalado horizontal. El comportamiento de estos sistemas de archivos no proporciona el rendimiento y la fiabilidad necesarios que Server Pro necesita al ejecutarse a gran escala. Cuando el sistema de archivos no puede seguir el ritmo de la carga, la aplicación se bloquea debido a demasiadas operaciones de E/S bloqueantes. Estos bloqueos pueden provocar que las cerraduras basadas en Redis se sobrepasen, lo que a su vez puede dar lugar a datos de proyecto corruptos. Recomendamos usar [almacenamiento de objetos compatible con S3](/on-premises/es/primeros-pasos/what-is-the-overleaf-toolkit.md) en su lugar. El bajo rendimiento de S3 solo afecta a la subida/descarga de archivos, lo que solo provoca un número elevado de conexiones abiertas a tu proveedor de S3 y, a su vez, 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 operaciones de sistema de archivos/E/S a nivel de aplicación. {% hint style="info" %} Como referencia, GitLab sigue una postura similar de [no admitir NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) con su oferta autogestionada. {% endhint %} ### Configuración específica de Nginx para implementaciones grandes De forma predeterminada, la instancia de Overleaf Server limita el número de conexiones a 768. Esto incluye conexiones persistentes WebSocket, navegación HTML de nivel superior y solicitudes ajax. Una vez alcanzado el límite, es posible que el editor no pueda conectarse, que la página del editor no cargue por completo y que las solicitudes de compilación fallen. Nginx devolverá respuestas con estado 500 y registrará `worker_connections no son suficientes mientras se conecta a upstream` en `var/log/nginx/error`.log dentro del `sharelatex` contenedor. La configuración de [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) limita el número de conexiones concurrentes que nginx aceptará por worker. El número de workers está controlado por la configuración de [`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 hace mucho trabajo en comparación con otras partes del sistema, así que estos límites actúan como una protección para evitar que demasiadas conexiones sobrecarguen el sistema. Es preferible descartar algunas conexiones sobrantes pronto que ralentizar cada conexión. Las instancias de Overleaf Server exponen variables de entorno para ajustar estos valores de nginx: * `NGINX_WORKER_PROCESSES` para [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (predeterminado `4`) * `NGINX_WORKER_CONNECTIONS` para [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (predeterminado `768`) * `NGINX_KEEPALIVE_TIMEOUT` para [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (predeterminado `65`)

Al ejecutar otro proxy delante del sharelatex contenedor (por ejemplo, para la terminación TLS), el NGINX_KEEPALIVE_TIMEOUT en la instancia de Overleaf Server necesita ser mayor que el del proxy anterior. Por ejemplo, con otro proceso de nginx en el host Docker nginx-host, aquí hay dos ejemplos:

* Valor predeterminado `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 también es la principal limitación al compilar un documento. Por lo tanto, cuanto más rápido 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 de los que tienes núcleos de CPU libres. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/es/primeros-pasos/requirements/hardware-requirements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.