> ## 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

Ao provisionar hardware para executar o Overleaf, o principal fator a considerar é quantos usuários simultâneos estarão executando compilações.

Por exemplo, se você tiver uma licença para 100 usuários no total, mas espera que apenas \~5 trabalhem ao mesmo tempo, a instalação mínima será suficiente. Se você espera que uma proporção maior trabalhe (e compile) simultaneamente, deve considerar provisionar um servidor com especificações mais altas.

### Instalação mínima

É necessário um requisito básico mínimo de 2 núcleos e 3 GB de memória para operações básicas com cerca de 5 usuários simultâneos. Esse requisito mínimo também será suficiente para grupos maiores em que o uso simultâneo é menor, ou em que tempos de compilação mais longos durante períodos de uso intenso são aceitáveis.

<Danger>
  Se você estiver considerando usar um sistema de arquivos baseado em NFS (Network File System) para sua instância pequena, consulte esta parte da seção [Solução de problemas](/pt/on-premises/support/troubleshooting).
</Danger>

### Escalabilidade

Como regra geral, para oferecer um nível de serviço alto e consistente, deve-se adicionar 1 núcleo de CPU e 1 GB de memória à instalação mínima para cada 5 a 10 usuários simultâneos.

Isso deve ser considerado apenas uma orientação, pois fatores como o tamanho dos documentos típicos (documentos maiores consomem mais recursos de compilação), a frequência com que os usuários compilam e a tolerância a tempos de compilação mais longos durante uso intenso afetam o nível de provisionamento necessário.

Muitos de nossos clientes buscam implantar o Server Pro em toda a organização ou em equipes grandes. Nessas situações, é difícil para nós recomendar requisitos de configuração específicos, pois os casos de uso e o hardware disponível podem variar bastante.

| Exemplo 1 | Exemplo 2 |
| - | - |
| Se você estiver executando uma instalação do Server Pro para 300 usuários no total e espera regularmente que 30 a 60 desses usuários compilem documentos ao mesmo tempo, 8 GB e 7 núcleos (5 núcleos + 5 GB + a base de 2 núcleos e 3 GB) devem fornecer recursos suficientes para que seus usuários tenham um nível de serviço consistentemente alto. | Para dar um exemplo dos requisitos de hardware para uma implantação maior, uma instalação do Server Pro para 1.000 usuários 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. Isso foi suficiente para as necessidades da equipe ao longo do último ano de uso. |

Clientes que estão excedendo os limites de um único servidor grande podem consultar [Escalabilidade horizontal](/pt/on-premises/maintenance/horizontal-scaling) para o Server Pro.

### Armazenamento

Não recomendamos o uso de Network File System (NFS)/Amazon EFS/Amazon EBS para o armazenamento de projetos/histórico em instalações maiores e, explicitamente, **não oferecemos suporte** a eles na escalabilidade horizontal.

Esses sistemas de arquivos não oferecem o desempenho e a confiabilidade de que o Server Pro precisa ao operar em grande escala. Quando o sistema de arquivos não consegue acompanhar a carga, a aplicação trava devido ao excesso de operações de IO bloqueantes. Esses travamentos podem fazer com que locks baseados em Redis expirem, o que, por sua vez, pode resultar em dados de projeto corrompidos.

Recomendamos usar [armazenamento de objetos compatível com S3](/pt/on-premises/getting-started/what-is-the-overleaf-toolkit) em vez disso. Um desempenho lento do S3 afeta apenas o upload/download de arquivos, o que apenas leva a um número elevado de conexões abertas com o seu provedor S3 e não afeta o comportamento do restante da aplicação. Além disso, o Server Pro pode definir timeouts razoáveis para as requisições ao S3, o que não é possível para operações de sistema de arquivos/IO no nível da aplicação.

<Info>
  Como referência, o GitLab adota uma postura semelhante de [não oferecer suporte a NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) em sua oferta autogerenciada.
</Info>

### Configuração específica do Nginx para grandes implantações

Por padrão, a instância do Overleaf Server limita o número de conexões a 768. Isso inclui conexões Websocket persistentes, navegação HTML de nível superior e requisições ajax. Quando o limite é atingido, o editor pode não conseguir se conectar, a página do editor pode não carregar por completo e as requisições de compilação podem falhar. O Nginx retornará respostas com status 500 e registrará `worker_connections are not enough while connecting to upstream` em `var/log/nginx/error`.log dentro do contêiner `sharelatex`.

A configuração [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) limita o número de conexões simultâneas que o nginx aceitará por worker. O número de workers é controlado pela configuração [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) e é definido como 4 por padrão em nossa configuração do nginx.

O Nginx não realiza muito trabalho em comparação com outras partes do sistema, então esses limites funcionam como uma proteção que impede que conexões em excesso sobrecarreguem o sistema. É preferível descartar algumas conexões excedentes logo no início do que deixar todas as conexões mais lentas.

As instâncias do Overleaf Server expõem variáveis de ambiente para ajustar essas configurações do nginx:

* `NGINX_WORKER_PROCESSES` para [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (padrão `4`)
* `NGINX_WORKER_CONNECTIONS` para [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (padrão `768`)
* `NGINX_KEEPALIVE_TIMEOUT` para [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (padrão `65`)

  <Info>Ao executar outro proxy na frente do contêiner `sharelatex` (por exemplo, para terminação TLS), o `NGINX_KEEPALIVE_TIMEOUT` da instância do Overleaf Server precisa ser maior que o do proxy anterior. Por exemplo, com outro processo nginx no host Docker <strong>nginx-host</strong>, aqui estão dois exemplos:</Info>
* Valor padrão de `NGINX_KEEPALIVE_TIMEOUT`: use [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valor padrão no upstream) no **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) no **nginx-host**

### Velocidade da CPU

O LaTeX é um programa de thread única, o que significa que ele só pode utilizar um núcleo de CPU por vez. A CPU também é a principal limitação ao compilar um documento. Portanto, quanto mais rápido for o desempenho de núcleo único da sua CPU, mais rápido você conseguirá compilar um documento. Mais núcleos só ajudarão se você estiver tentando compilar mais documentos do que a quantidade de núcleos de CPU livres.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.