> 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/sv/komma-igang/requirements/hardware-requirements.md). # Hårdvarukrav ## Maskinvarukrav När du tilldelar maskinvara för att köra Overleaf är den viktigaste faktorn att ta hänsyn till hur många samtidiga användare som kommer att kompilera. Om du till exempel har en licens för 100 användare totalt, men bara räknar med 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 tilldela en server med högre specifikation. ### Minimal installation Ett minimikrav på 2 kärnor och 3 GB minne krävs för grundläggande drift med omkring 5 samtidiga användare. Detta minimikrav räcker också för större grupper där det är mindre samtidig användning, eller där det är okej att kompileringstiderna blir längre vid högre 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 då en titt på detta avsnitt i [Felsökning](/on-premises/sv/support/troubleshooting.md) avsnittet. {% 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. Detta bör endast ses som en vägledning, eftersom faktorer som storleken på typiska dokument (större dokument använder mer kompileringresurser), hur ofta användare kompilerar och vilken tolerans det finns för längre kompileringstider vid hög belastning, alla påverkar vilken nivå av tilldelning 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 installationskrav, eftersom användningsfallen och den underliggande maskinvaran som finns tillgänglig kan variera mycket. | Exempel 1 | Exempel 2 | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Om du kör en Server Pro-installation för 300 användare totalt och regelbundet förväntar dig att 30–60 av dessa användare ska kompilera dokument samtidigt, bör 8 GB och 7 kärnor (5 kärnor + 5 GB + basen på 2 kärnor och 3 GB) ge tillräckliga resurser för att dina användare ska ha en genomgående hög servicenivå. | För att ge ett exempel på maskinvarukraven för en större driftsättning har en Server Pro-installation för 1 000 användare totalt satts upp framgångsrikt med en enda server utrustad 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 titta på [Horisontell skalning](/on-premises/sv/underhall/horizontal-scaling.md) för Server Pro. ### Lagring Vi avråder från att använda Network File System (NFS)/Amazon EFS/Amazon EBS för projekt-/historiklagring i större installationer och stöder uttryckligen inte **stöder det inte** för horisontell skalning. Beteendet hos dessa filsystem ger inte den nödvändiga prestanda och tillförlitlighet som Server Pro behöver när den körs i stor skala. När filsystemet inte hinner med belastningen låser sig applikationen på grund av för många blockerande IO-operationer. Dessa låsningar kan leda till att Redis-baserade lås överskrids, vilket i sin tur kan resultera i skadad projektdata. Vi rekommenderar att använda [S3-kompatibel objektlagring](/on-premises/sv/komma-igang/what-is-the-overleaf-toolkit.md) i stället. Långsam S3-prestanda påverkar i sin tur bara uppladdning och nedladdning av filer, vilket endast 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-begäranden, vilket inte är möjligt för filsystem-/IO-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 egenhanterade erbjudande. {% endhint %} ### Nginx-specifik konfiguration för stora driftsättningar Som standard begränsar Overleaf Server-instansen antalet anslutningar till 768. Detta inkluderar beständiga WebSocket-anslutningar, HTML-navigering på toppnivå och AJAX-begäranden. När gränsen nås kanske editorn inte kan ansluta, editorsidan kanske inte laddas بالكامل och kompileringförfrågningar kan misslyckas. Nginx kommer att returnera status 500-svar och logga `worker_connections räcker inte vid anslutning till 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 [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) och är inställt på 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 mot att för många anslutningar överbelastar systemet. Det är bättre att släppa några överskottsanslutningar tidigt än att sakta ner varje anslutning. Overleaf Server-instanser 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 sharelatex containern (t.ex. för TLS-terminering), 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 program med en enda tråd, vilket betyder att det bara kan utnyttja en CPU-kärna åt gången. CPU:n är också den huvudsakliga begränsningen när ett dokument kompileras. Därför gäller att ju snabbare din CPU är per kärna, 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://ayakaleaf-pro.ayaka.space/on-premises/sv/komma-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.