> 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/it/per-iniziare/requirements/hardware-requirements.md). # Requisiti hardware ## Requisiti hardware Quando si dimensiona l'hardware per eseguire Overleaf, il fattore principale da considerare è quanti utenti contemporanei eseguiranno compilazioni. Ad esempio, se hai una licenza per 100 utenti totali, ma ti aspetti che solo \~5 lavorino allo stesso tempo, l'installazione minima sarà sufficiente. Se prevedi che una percentuale più alta lavori (e compili) simultaneamente, dovresti considerare di configurare un server con specifiche più elevate. ### Installazione minima Per operazioni di base con circa 5 utenti contemporanei è richiesto un requisito minimo di base di 2 core e 3 GB di memoria. Questo requisito minimo sarà sufficiente anche per gruppi più grandi in cui l'uso contemporaneo è inferiore, o in cui va bene che i tempi di compilazione siano più lunghi durante un utilizzo più intenso. {% hint style="danger" %} Se stai considerando di usare un file system basato su NFS (Network File System) per la tua piccola istanza, dai un'occhiata a questa sezione nella [Risoluzione dei problemi](/on-premises/it/supporto/troubleshooting.md) sezione. {% endhint %} ### Scalabilità Come regola generale, per fornire un livello di servizio elevato e costante, a ogni 5-10 utenti contemporanei dovrebbero essere aggiunti 1 core CPU e 1 GB di memoria all'installazione minima. Questo dovrebbe essere considerato solo come una guida, poiché fattori come le dimensioni dei documenti tipici (documenti più grandi utilizzano più risorse di compilazione), la frequenza con cui gli utenti compilano e la tolleranza per tempi di compilazione più lunghi durante un uso intenso influenzano tutti il livello di provisioning richiesto. Molti dei nostri clienti cercano di implementare Server Pro a livello di organizzazione o in grandi team. In quelle situazioni, per noi è difficile consigliare requisiti di configurazione specifici, perché i casi d'uso e l'hardware sottostante disponibile possono essere molto vari. | Esempio 1 | Esempio 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Se stai eseguendo un'installazione Server Pro per 300 utenti totali e ti aspetti regolarmente che 30-60 di quegli utenti compilino documenti contemporaneamente, 8 GB e 7 core (5 core + 5 GB + base di 2 core e 3 GB) dovrebbero fornire risorse sufficienti affinché i tuoi utenti abbiano un livello di servizio costantemente elevato. | Per dare un esempio dei requisiti hardware per una distribuzione più ampia, un'installazione Server Pro per 1.000 utenti totali è stata configurata con successo utilizzando un singolo server dotato di due processori a 4 core e 32 GB di memoria di sistema. Questo è stato sufficiente per le esigenze del team nell'ultimo anno di utilizzo. | I clienti che superano i limiti di un singolo grande server possono dare un'occhiata a [Scalabilità orizzontale](/on-premises/it/manutenzione/horizontal-scaling.md) per Server Pro. ### Archiviazione Si sconsiglia di usare Network File System (NFS)/Amazon EFS/Amazon EBS per l'archiviazione dei progetti/della cronologia in configurazioni più grandi e, esplicitamente, **non lo supportiamo** per la scalabilità orizzontale. Il comportamento di questi file system non offre le prestazioni e l'affidabilità necessarie a Server Pro quando viene eseguito su larga scala. Quando il file system non riesce a tenere il passo con il carico, l'applicazione si blocca a causa di troppe operazioni di I/O bloccanti. Questi blocchi possono portare a lock basati su Redis che vanno in timeout, il che a sua volta può causare dati di progetto danneggiati. Consigliamo di usare [archiviazione a oggetti compatibile con S3](/on-premises/it/per-iniziare/what-is-the-overleaf-toolkit.md) Invece, le prestazioni lente di S3 influenzano solo il caricamento/scaricamento dei file, il che porta solo a un numero maggiore di connessioni aperte al provider S3 e, a sua volta, non influisce sul comportamento del resto dell'applicazione. Inoltre, Server Pro può specificare timeout ragionevoli sulle richieste S3, cosa che non è possibile per le operazioni di file system/I/O a livello dell'applicazione. {% hint style="info" %} Come riferimento, GitLab adotta una posizione simile di [non supportare NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) con la sua offerta self-managed. {% endhint %} ### Configurazione specifica di Nginx per grandi distribuzioni Per impostazione predefinita, l'istanza Overleaf Server limita il numero di connessioni a 768. Questo include le connessioni WebSocket persistenti, la navigazione HTML di primo livello e le richieste ajax. Una volta raggiunto il limite, l'editor potrebbe non riuscire a connettersi, la pagina dell'editor potrebbe non caricarsi interamente e le richieste di compilazione potrebbero fallire. Nginx restituirà risposte con stato 500 e registrerà `worker_connections non sono sufficienti durante la connessione a upstream` in `var/log/nginx/error`.log all'interno del container `sharelatex` container. Il [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) impostazione limita il numero di connessioni contemporanee che nginx accetterà per worker. Il numero di worker è controllato dall'impostazione [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) e, nella nostra configurazione nginx, è impostato a 4 per impostazione predefinita. Nginx non esegue molto lavoro rispetto ad altre parti del sistema, quindi questi limiti fungono da salvaguardia per evitare che troppe connessioni sovraccarichino il sistema. È preferibile scartare in anticipo alcune connessioni in eccesso piuttosto che rallentare ogni connessione. Le istanze di Overleaf Server espongono variabili d'ambiente per regolare queste impostazioni di nginx: * `NGINX_WORKER_PROCESSES` per [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (predefinito `4`) * `NGINX_WORKER_CONNECTIONS` per [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (predefinito `768`) * `NGINX_KEEPALIVE_TIMEOUT` per [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (predefinito `65`)

Quando si esegue un altro proxy davanti al sharelatex container (ad es. per la terminazione TLS), il NGINX_KEEPALIVE_TIMEOUT nell'istanza Overleaf Server deve essere maggiore di quello del proxy precedente. Ad es. con un altro processo nginx sull'host Docker nginx-host, ecco due esempi:

* Valore predefinito `NGINX_KEEPALIVE_TIMEOUT`, usa [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore predefinito a monte) in **nginx-host** * Valore personalizzato `NGINX_KEEPALIVE_TIMEOUT=100s`, usa [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore personalizzato a monte) in **nginx-host** ### Velocità della CPU LaTeX è un programma single-thread, il che significa che può utilizzare solo un core CPU alla volta. La CPU è anche il principale limite quando si compila un documento. Pertanto, quanto più veloce è la prestazione su singolo core della tua CPU, tanto più velocemente potrai compilare un documento. Più core saranno utili solo se stai cercando di compilare più documenti di quanti core CPU liberi tu abbia. --- # 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/it/per-iniziare/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.