> 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/it/per-iniziare/requirements/hardware-requirements.md). # Requisiti hardware ## Requisiti hardware Quando si predispone l'hardware per eseguire Overleaf, il fattore principale da considerare è quanti utenti concorrenti eseguiranno compilazioni. Ad esempio, se avete una licenza per 100 utenti totali, ma vi aspettate che solo circa 5 lavorino contemporaneamente, l'installazione minima sarà sufficiente. Se vi aspettate che una percentuale più alta lavori (e compili) simultaneamente, dovreste considerare di predisporre un server con specifiche più elevate. ### Installazione minima Un requisito base minimo di 2 core e 3 GB di memoria è necessario per le operazioni di base con circa 5 utenti concorrenti. Questo requisito minimo sarà inoltre sufficiente per gruppi più grandi in cui l'uso simultaneo è inferiore, o dove va bene che i tempi di compilazione siano più lunghi durante un utilizzo più intenso. {% hint style="danger" %} Se state valutando di usare un file system basato su NFS (Network File System) per la vostra piccola istanza, date un'occhiata a questa sezione nella [Risoluzione dei problemi](/on-premises/it/supporto/troubleshooting.md) sezione. {% endhint %} ### Scalabilità Come regola generale, per offrire un livello di servizio elevato e costante, andrebbero aggiunti 1 core CPU e 1 GB di memoria all'installazione minima per ogni 5-10 utenti concorrenti. Questo dovrebbe essere considerato solo come una guida, poiché fattori come la dimensione dei documenti tipici (documenti più grandi consumano 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 distribuire Server Pro a livello aziendale o su team di grandi dimensioni. 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 state eseguendo un'installazione Server Pro per 300 utenti totali e vi aspettate regolarmente che 30-60 di questi 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 vostri utenti abbiano un livello di servizio costantemente elevato. | Per fornire 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 predisposto con 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 Sconsigliamo di usare Network File System (NFS)/Amazon EFS/Amazon EBS per l'archiviazione di progetti/storico in configurazioni più grandi e non lo **supportiamo esplicitamente** 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 I/O bloccanti. Questi blocchi possono portare a lock basati su Redis in overrun, che a loro volta possono causare dati di progetto corrotti. Si consiglia di usare [storage a oggetti compatibile con S3](/on-premises/it/per-iniziare/what-is-the-overleaf-toolkit.md) invece. Le prestazioni lente di S3 a loro volta influiscono solo sul caricamento/scaricamento dei file, il che porta solo a un numero elevato di connessioni aperte al provider S3 e, di conseguenza, 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 di applicazione. {% hint style="info" %} Per riferimento, GitLab segue una posizione simile di [non supportare NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) con la sua offerta autogestita. {% endhint %} ### Configurazione specifica di Nginx per grandi distribuzioni Per impostazione predefinita, le istanze di Overleaf Server limitano il numero di connessioni a 768. Ciò 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 completamente e le richieste di compilazione possono fallire. Nginx restituirà risposte con stato 500 e registrerà `worker_connections non sono sufficienti durante la connessione all'upstream` in `var/log/nginx/error`.log all'interno del `sharelatex` contenitore. Il [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) impostazione limita il numero di connessioni simultanee 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) ed è impostato a 4 per impostazione predefinita nella nostra configurazione nginx. Nginx non svolge molto lavoro rispetto ad altre parti del sistema, quindi questi limiti fungono da misura di sicurezza per impedire che troppe connessioni sovraccarichino il sistema. È preferibile eliminare in anticipo alcune connessioni in eccesso piuttosto che rallentare ogni connessione. Le istanze di Overleaf Server espongono variabili d'ambiente per regolare queste impostazioni 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 contenitore (ad esempio per la terminazione TLS), il NGINX_KEEPALIVE_TIMEOUT nell'istanza di Overleaf Server deve essere maggiore di quello del proxy precedente. Ad esempio, con un altro processo nginx sull'host Docker nginx-host, ecco due esempi:

* Valore predefinito `NGINX_KEEPALIVE_TIMEOUT`, usare [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore predefinito nell'upstream) in **nginx-host** * Valore personalizzato `NGINX_KEEPALIVE_TIMEOUT=100s`, usare [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (valore personalizzato nell'upstream) in **nginx-host** ### Velocità della CPU LaTeX è un programma a thread singolo, il che significa che può utilizzare solo un core della CPU alla volta. La CPU è anche il principale limite durante la compilazione di un documento. Pertanto, più veloce è la prestazione single-core della vostra CPU, più velocemente potrete compilare un documento. Più core aiuteranno solo se state cercando di compilare più documenti di quanti core CPU liberi abbiate. --- # 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/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.