> 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/pt/comecar/requirements/hardware-requirements.md). # Requisitos de hardware ## Requisitos de hardware Ao provisionar hardware para executar o Overleaf, o principal fator a considerar é quantos utilizadores simultâneos estarão a executar compilações. Por exemplo, se tiver uma licença para 100 utilizadores no total, mas apenas esperar que \~5 estejam a trabalhar ao mesmo tempo, a instalação mínima será suficiente. Se esperar que uma proporção maior esteja a trabalhar (e a compilar) em simultâneo, deverá considerar provisionar um servidor com uma especificação superior. ### Instalação mínima É necessário um requisito base mínimo de 2 núcleos e 3 GB de memória para operações básicas com cerca de 5 utilizadores simultâneos. Este requisito mínimo também será suficiente para grupos maiores em que exista menos utilização simultânea, ou em que seja aceitável que os tempos de compilação sejam mais longos durante períodos de maior utilização. {% hint style="danger" %} Se estiver a considerar usar um sistema de ficheiros baseado em NFS (Network File System) para a sua instância pequena, consulte esta secção em [Resolução de problemas](/on-premises/pt/suporte/troubleshooting.md) secção. {% endhint %} ### Escalabilidade Como regra geral, para fornecer um nível de serviço elevado e consistente, devem ser adicionados 1 núcleo de CPU e 1 GB de memória à instalação mínima por cada 5-10 utilizadores simultâneos. Isto deve ser tomado apenas como um guia, uma vez que fatores como o tamanho dos documentos típicos (documentos maiores consomem mais recursos de compilação), a frequência com que os utilizadores compõem, e a tolerância para tempos de compilação mais longos durante períodos de maior utilização, afetam todos o nível de provisionamento necessário. Muitos dos nossos clientes procuram implementar o Server Pro em toda a organização, ou em equipas grandes. Nesses casos, é difícil para nós aconselharmos requisitos de configuração específicos, porque os casos de utilização e o hardware subjacente disponível podem variar bastante. | Exemplo 1 | Exemplo 2 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Se estiver a executar uma instalação Server Pro para 300 utilizadores no total, e esperar regularmente que 30-60 desses utilizadores estejam a compilar documentos ao mesmo tempo, 8 GB e 7 núcleos (5 núcleos + 5 GB + base de 2 núcleos e 3 GB) deverão fornecer recursos suficientes para que os seus utilizadores tenham um nível de serviço consistentemente elevado. | Para dar um exemplo dos requisitos de hardware para uma implementação maior, uma instalação Server Pro para 1 000 utilizadores no total foi configurada com sucesso usando um único servidor provisionado com dois processadores de 4 núcleos e 32 GB de memória do sistema. Isto foi suficiente para as necessidades da equipa ao longo do último ano de utilização. | Os clientes que estão a exceder os limites de um único servidor grande podem consultar [Escalonamento horizontal](/on-premises/pt/manutencao/horizontal-scaling.md) para o Server Pro. ### Armazenamento Não recomendamos o uso de Network File System (NFS)/Amazon EFS/Amazon EBS para armazenamento de projetos/histórico em configurações maiores e, de forma explícita, **não o suportamos** para escalonamento horizontal. O comportamento destes sistemas de ficheiros não oferece o desempenho e a fiabilidade necessários de que o Server Pro precisa quando está a ser executado em grande escala. Quando o sistema de ficheiros não consegue acompanhar a carga, a aplicação bloqueia devido a demasiadas operações de E/S em espera. Esses bloqueios podem levar a ultrapassar os bloqueios baseados em Redis, o que por sua vez pode resultar em dados de projeto corrompidos. Recomendamos o uso de [armazenamento de objetos compatível com S3](/on-premises/pt/comecar/what-is-the-overleaf-toolkit.md) em vez disso. Um desempenho lento do S3, por sua vez, afeta apenas o envio/transferência de ficheiros, o que apenas leva a um número elevado de ligações abertas ao seu fornecedor S3 e, por sua vez, não afeta o comportamento do resto da aplicação. Além disso, o Server Pro pode especificar tempos limite razoáveis para pedidos S3, o que não é possível para operações de sistema de ficheiros/E/S ao nível da aplicação. {% hint style="info" %} Como referência, o GitLab segue uma posição semelhante de [não suportar NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) na sua oferta autogerida. {% endhint %} ### Configuração específica do Nginx para grandes implementações Por predefinição, a instância do Overleaf Server limita o número de ligações a 768. Isto inclui ligações WebSocket persistentes, navegação HTML de nível superior e pedidos ajax. Quando o limite é atingido, o editor pode não conseguir ligar-se, a página do editor pode não carregar completamente e os pedidos de compilação podem falhar. O Nginx devolverá respostas com estado 500 e registará `worker_connections are not enough while connecting to upstream` em `var/log/nginx/error`.log dentro do `sharelatex` contentor. O [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) define o número de ligações simultâneas que o nginx aceitará por worker. O número de workers é controlado pela definição [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) e está definido para 4 por predefinição na nossa configuração do nginx. O Nginx não faz muito trabalho comparado com outras partes do sistema, pelo que estes limites atuam como uma proteção para evitar que demasiadas ligações sobrecarreguem o sistema. É preferível rejeitar algumas ligações em excesso mais cedo do que abrandar todas as ligações. As instâncias do Overleaf Server expõem variáveis de ambiente para ajustar estas definições do nginx: * `NGINX_WORKER_PROCESSES` para [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (predefinição `4`) * `NGINX_WORKER_CONNECTIONS` para [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (predefinição `768`) * `NGINX_KEEPALIVE_TIMEOUT` para [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (predefinição `65`)

Ao executar outro proxy à frente do sharelatex contentor (por exemplo, para terminação TLS), o NGINX_KEEPALIVE_TIMEOUT na instância do Overleaf Server precisa de ser maior do que o proxy anterior. Por exemplo, com outro processo nginx no anfitrião Docker nginx-host, aqui estão dois exemplos:

* Valor predefinido `NGINX_KEEPALIVE_TIMEOUT`, use [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valor predefinido a montante) em **nginx-host** * Valor personalizado `NGINX_KEEPALIVE_TIMEOUT=100s`, use [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valor personalizado a montante) em **nginx-host** ### Velocidade da CPU O LaTeX é um programa de thread único, o que significa que só pode utilizar um núcleo de CPU de cada vez. A CPU é também a principal limitação ao compilar um documento. Portanto, quanto mais rápida for o desempenho de núcleo único da sua CPU, mais rapidamente conseguirá compilar um documento. Mais núcleos só ajudarão se estiver a tentar compilar mais documentos do que os núcleos de CPU livres que tem. --- # 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/pt/comecar/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.