> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/pt/primeiros-passos/requirements/hardware-requirements.md). # Requisitos de hardware ## Requisitos de hardware Ao provisionar hardware para executar o Overleaf, o principal fator a considerar é quantos utilizadores em simultâneo 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 percentagem maior esteja a trabalhar (e a compilar) em simultâneo, deve considerar provisionar um servidor com uma especificação superior. ### Instalação mínima É necessário um requisito mínimo base de 2 núcleos e 3 GB de memória para operações básicas com cerca de 5 utilizadores em simultâneo. Este requisito mínimo também será suficiente para grupos maiores, onde há menos utilização simultânea, ou onde não há problema em os tempos de compilação serem 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 pequena instância, consulte esta secção na [Resolução de problemas](/on-premises/pt/suporte/troubleshooting.md) secção. {% endhint %} ### Escalamento Como regra prática, para fornecer um nível de serviço elevado e consistente, deve adicionar 1 núcleo de CPU e 1 GB de memória à instalação mínima por cada 5 a 10 utilizadores em simultâneo. Isto deve ser encarado apenas como um guia, uma vez que fatores como o tamanho dos documentos típicos (documentos maiores utilizam mais recursos de compilação), a frequência com que os utilizadores compilam 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. Nessas situações, é difícil 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 do Server Pro para 300 utilizadores no total e esperar regularmente que 30 a 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 do 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 de 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 [escalamento horizontal](/on-premises/pt/manutencao/horizontal-scaling.md) para o Server Pro. ### Armazenamento Desaconselhamos a utilização de Network File System (NFS)/Amazon EFS/Amazon EBS para armazenamento de projetos/histórico em configurações maiores e explicitamente **não o suportamos** para escalamento horizontal. O comportamento destes sistemas de ficheiros não oferece o desempenho e a fiabilidade necessários de que o Server Pro precisa ao operar em grande escala. Quando o sistema de ficheiros não consegue acompanhar a carga, a aplicação fica bloqueada devido a demasiadas operações de E/S em espera. Estes bloqueios podem levar à ultrapassagem de locks baseados em Redis, o que por sua vez pode resultar em dados de projeto corrompidos. Recomendamos a utilização de [armazenamento de objetos compatível com S3](/on-premises/pt/primeiros-passos/what-is-the-overleaf-toolkit.md) em vez disso. Um desempenho lento do S3, por sua vez, apenas afeta o carregamento/descarregamento de ficheiros, o que apenas leva a um número mais 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 implementações grandes Por predefinição, a instância do Overleaf Server limita o número de ligações a 768. Isto inclui ligações persistentes WebSocket, navegação HTML de nível superior e pedidos AJAX. Assim que o limite for atingido, o editor poderá não conseguir ligar-se, a página do editor poderá não carregar na totalidade 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 limite do número de ligações em simultâneo 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 como 4 por predefinição na nossa configuração do nginx. O Nginx não faz muito trabalho em comparação com outras partes do sistema, por isso estes limites funcionam como uma salvaguarda para impedir que demasiadas ligações sobrecarreguem o sistema. É preferível rejeitar cedo algumas ligações em excesso 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 no Overleaf Server instance precisa de ser maior do que o do 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 no upstream) 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 no upstream) em **nginx-host** ### Velocidade da CPU O LaTeX é um programa de um único thread, 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ápido for o desempenho de um único núcleo da sua CPU, mais rapidamente conseguirá compilar um documento. Mais núcleos só ajudarão se estiver a tentar compilar mais documentos do que núcleos de CPU livres tiver. --- # 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://ayakaleaf-pro.ayaka.space/on-premises/pt/primeiros-passos/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.