> 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/sv/kom-igang/requirements/hardware-requirements.md). # Hårdvarukrav ## Hårdvarukrav När du tillhandahåller hårdvara för att köra Overleaf är den viktigaste faktorn att ta hänsyn till hur många samtidiga användare som kommer att köra kompileringar. Till exempel, om du har en licens för 100 användare totalt, men bara förväntar dig att cirka 5 arbetar samtidigt, räcker den minimala installationen. Om du förväntar dig att en större andel arbetar (och kompilerar) samtidigt bör du överväga att tillhandahålla en server med högre specifikationer. ### Minimal installation Ett minimikrav på 2 kärnor och 3 GB minne krävs för grundläggande operationer med omkring 5 samtidiga användare. Detta minimikrav kommer också att räcka för större grupper där den samtidiga användningen är lägre, eller där det är okej att kompileringstiderna blir längre under hög belastning. {% hint style="danger" %} Om du överväger att använda ett filsystem baserat på NFS (Network File System) för din lilla instans, ta gärna en titt på den här delen i [Felsökning](/on-premises/sv/support/troubleshooting.md) sektionen. {% endhint %} ### Skalning Som tumregel bör 1 CPU-kärna och 1 GB minne läggas till den minimala installationen för varje 5–10 samtidiga användare för att ge en hög och jämn servicenivå. Detta bör endast ses som en vägledning, eftersom faktorer som storleken på typiska dokument (större dokument använder mer kompilationsresurser), hur ofta användare kompilerar och vilken tolerans det finns för längre kompileringstider under hög belastning alla påverkar vilken nivå av provisionering som krävs. Många av våra kunder vill driftsätta Server Pro i hela organisationen eller över stora team. I sådana situationer är det svårt för oss att ge råd om specifika krav på installationen, eftersom användningsfallen och den underliggande hårdvaran som finns tillgänglig kan variera mycket. | Exempel 1 | Exempel 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Om du kör en Server Pro-installation för totalt 300 användare och regelbundet förväntar dig att 30–60 av dessa användare kompilerar dokument samtidigt, bör 8 GB och 7 kärnor (5 kärnor + 5 GB + en bas på 2 kärnor och 3 GB) ge tillräckliga resurser för att dina användare ska få en konsekvent hög servicenivå. | Som exempel på hårdvarukraven för en större driftsättning har en Server Pro-installation för totalt 1 000 användare satts upp framgångsrikt med en enda server som försågs med två 4-kärniga processorer och 32 GB systemminne. Detta har varit tillräckligt för teamets behov under det senaste årets användning. | Kunder som överskrider gränserna för en enda stor server kan ta en titt på [Horisontell skalning](/on-premises/sv/underhall/horizontal-scaling.md) för Server Pro. ### Lagring Vi avråder från att använda nätverksfilsystem (NFS)/Amazon EFS/Amazon EBS för projekt-/historiklagring i större installationer och stöder uttryckligen **inte det** för horisontell skalning. Beteendet hos dessa filsystem ger inte den nödvändiga prestanda och tillförlitlighet som Server Pro behöver vid drift i stor skala. När filsystemet inte kan hålla jämna steg med belastningen stannar applikationen på grund av för många blockerande I/O-operationer. Dessa stopp kan leda till att Redis-baserade lås överskrids, vilket i sin tur kan resultera i korrupt projektdata. Vi rekommenderar att använda [S3-kompatibel objektlagring](/on-premises/sv/kom-igang/what-is-the-overleaf-toolkit.md) i stället. Långsam S3-prestanda påverkar i sin tur endast uppladdning/nedladdning av filer, vilket bara leder till ett ökat antal öppna anslutningar till din S3-leverantör och i sin tur inte påverkar beteendet hos resten av applikationen. Dessutom kan Server Pro ange rimliga tidsgränser för S3-förfrågningar, vilket inte är möjligt för filsystems-/I/O-operationer på applikationsnivå. {% hint style="info" %} Som referens har GitLab en liknande hållning och [stöder inte NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) i sitt självhanterade erbjudande. {% endhint %} ### Nginx-specifik konfiguration för stora driftsättningar Som standard begränsar Overleaf Server-instansen antalet anslutningar till 768. Detta inkluderar permanenta WebSocket-anslutningar, HTML-navigering på toppnivå och ajax-förfrågningar. När gränsen nås kanske editorn inte kan ansluta, redigeringssidan kanske inte laddas fullt ut och kompileringsförfrågningar kan misslyckas. Nginx returnerar status 500-svar och loggar `worker_connections are not enough while connecting to upstream` till `var/log/nginx/error`.log i `sharelatex` containern. Inställningen [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) begränsar antalet samtidiga anslutningar som nginx accepterar per worker. Antalet workers styrs av inställningen [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) och är satt till 4 som standard i vår nginx-konfiguration. Nginx gör inte särskilt mycket arbete jämfört med andra delar av systemet, så dessa gränser fungerar som ett skydd som hindrar för många anslutningar från att överbelasta systemet. Det är bättre att släppa vissa överskottsanslutningar tidigt än att sakta ner varje anslutning. Overleaf Server-instansen exponerar miljövariabler för att justera dessa nginx-inställningar: * `NGINX_WORKER_PROCESSES` för [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (standard `4`) * `NGINX_WORKER_CONNECTIONS` för [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (standard `768`) * `NGINX_KEEPALIVE_TIMEOUT` för [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (standard `65`)

När du kör en annan proxy framför containern sharelatex (t.ex. för TLS-avslutning), måste NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen vara större än den föregående proxyn. T.ex. med en annan nginx-process på Docker-värden nginx-host, här är två exempel:

* Standardvärde `NGINX_KEEPALIVE_TIMEOUT`, använd [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (standardvärde i upstream) i **nginx-host** * Anpassat värde `NGINX_KEEPALIVE_TIMEOUT=100s`, använd [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (anpassat värde i upstream) i **nginx-host** ### CPU-hastighet LaTeX är ett enkeltrådat program, vilket betyder att det bara kan använda en CPU-kärna åt gången. CPU:n är också den huvudsakliga begränsningen vid kompilering av ett dokument. Därför gäller att ju snabbare din CPU:s enkelkärniga prestanda är, desto snabbare kommer du att kunna kompilera ett dokument. Fler kärnor hjälper bara om du försöker kompilera fler dokument än du har lediga CPU-kärnor. --- # 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/sv/kom-igang/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.