> 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/on-premises-no/kom-i-gang/requirements/hardware-requirements.md). # Maskinvarekrav ## Maskinvarekrav Når du setter opp maskinvare for å kjøre Overleaf, er hovedfaktoren å vurdere hvor mange samtidige brukere som vil kjøre kompileringer. For eksempel, hvis du har en lisens for totalt 100 brukere, men bare forventer at omtrent 5 jobber samtidig, vil den minimale installasjonen være tilstrekkelig. Hvis du forventer at en større andel jobber (og kompilerer) samtidig, bør du vurdere å sette opp en server med høyere spesifikasjoner. ### Minimal installasjon Et minimumskrav på 2 kjerner og 3 GB minne er nødvendig for grunnleggende drift med rundt 5 samtidige brukere. Dette minimumskravet vil også være tilstrekkelig for større grupper der det er mindre samtidig bruk, eller der det er greit at kompileringstiden er lengre under høyere belastning. {% hint style="danger" %} Hvis du vurderer å bruke et NFS-basert filsystem (Network File System) for den lille instansen din, ta en titt på denne delen i den [Feilsøking](/on-premises/on-premises-no/stotte/troubleshooting.md) delen. {% endhint %} ### Skalering Som en tommelfingerregel bør det legges til 1 CPU-kjerne og 1 GB minne til den minimale installasjonen for hver 5–10 samtidige brukere for å tilby et høyt og jevnt servicenivå. Dette bør bare sees på som en rettesnor, siden faktorer som størrelsen på typiske dokumenter (større dokumenter bruker mer kompilasjonsressurser), hvor ofte brukerne kompilerer, og hvor stor toleranse det er for lengre kompileringstider under høy belastning, alle påvirker hvor mye kapasitet som kreves. Mange av kundene våre ønsker å rulle ut Server Pro på tvers av hele organisasjonen, eller på tvers av store team. I slike situasjoner er det vanskelig for oss å gi råd om spesifikke oppsettskrav, fordi brukstilfellene og den underliggende maskinvaren som er tilgjengelig kan variere mye. | Eksempel 1 | Eksempel 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Hvis du kjører en Server Pro-installasjon for 300 brukere totalt, og regelmessig forventer at 30–60 av disse brukerne kompilerer dokumenter samtidig, bør 8 GB og 7 kjerner (5 kjerner + 5 GB + basis på 2 kjerner og 3 GB) gi tilstrekkelige ressurser til at brukerne dine kan ha et konsekvent høyt servicenivå. | For å gi et eksempel på maskinvarekravene for en større utrulling, ble en Server Pro-installasjon for 1 000 brukere totalt satt opp vellykket ved å bruke en enkelt server konfigurert med to 4-kjerners prosessorer og 32 GB systemminne. Dette har vært tilstrekkelig for teamets behov det siste året med bruk. | Kunder som overskrider grensene til én stor server kan ta en titt på [Horisontal skalering](/on-premises/on-premises-no/vedlikehold/horizontal-scaling.md) for Server Pro. ### Lagring Vi fraråder bruk av Network File System (NFS)/Amazon EFS/Amazon EBS for prosjekt-/historielagring i større oppsett og uttrykkelig **støtter det ikke** for horisontal skalering. Oppførselen til disse filsystemene gir ikke den nødvendige ytelsen og påliteligheten som Server Pro trenger når den kjører i stor skala. Når filsystemet ikke klarer å holde tritt med belastningen, stopper applikasjonen opp på grunn av for mange blokkerende I/O-operasjoner. Disse stoppene kan føre til at Redis-baserte låser overskrides, noe som igjen kan resultere i ødelagte prosjektdata. Vi anbefaler å bruke [S3-kompatibel objektlagring](/on-premises/on-premises-no/kom-i-gang/what-is-the-overleaf-toolkit.md) i stedet. Langsom S3-ytelse påvirker på sin side bare opplasting/nedlasting av filer, noe som bare fører til et økt antall åpne forbindelser til S3-leverandøren din og på sin side ikke påvirker oppførselen til resten av applikasjonen. I tillegg kan Server Pro angi rimelige tidsavbrudd på S3-forespørsler, noe som ikke er mulig for filsystem-/I/O-operasjoner på applikasjonsnivå. {% hint style="info" %} Til referanse følger GitLab en lignende linje med å [ikke støtte NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) i sitt selvhostede tilbud. {% endhint %} ### Nginx-spesifikk konfigurasjon for store distribusjoner Som standard begrenser Overleaf Server-instansen antall tilkoblinger til 768. Dette inkluderer vedvarende WebSocket-tilkoblinger, HTML-navigasjon på toppnivå og ajax-forespørsler. Når grensen er nådd, kan det hende at editoren ikke kan koble til, at editorsiden ikke lastes helt inn, og at kompileringsforespørsler kan feile. Nginx vil returnere status 500-svar og logge `worker_connections er ikke tilstrekkelig ved tilkobling til upstream` inn i `var/log/nginx/error`.log i `sharelatex` beholderen. Den [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) begrenser antall samtidige tilkoblinger nginx vil akseptere per worker. Antallet workers styres av innstillingen [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) og er satt til 4 som standard i nginx-konfigurasjonen vår. Nginx gjør ikke særlig mye arbeid sammenlignet med andre deler av systemet, så disse grensene fungerer som en sikkerhet som hindrer at for mange tilkoblinger overvelder systemet. Det er bedre å slippe noen overflødige tilkoblinger tidlig enn å gjøre alle tilkoblingene tregere. Overleaf Server-instansene eksponerer miljøvariabler for å justere disse nginx-innstillingene: * `NGINX_WORKER_PROCESSES` for [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) (standard `4`) * `NGINX_WORKER_CONNECTIONS` for [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) (standard `768`) * `NGINX_KEEPALIVE_TIMEOUT` for [`keepalive_timeout`](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) (standard `65`)

Når du kjører en annen proxy foran sharelatex containeren (f.eks. for TLS-terminering), må NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen være større enn den forrige proxyen. F.eks. med en annen nginx-prosess på Docker-verten nginx-host, her er to eksempler:

* Standardverdi `NGINX_KEEPALIVE_TIMEOUT`, bruk [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (standardverdi oppstrøms) i **nginx-host** * Egendefinert verdi `NGINX_KEEPALIVE_TIMEOUT=100s`, bruk [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (egendefinert verdi oppstrøms) i **nginx-host** ### CPU-hastighet LaTeX er et enkelttrådet program, noe som betyr at det bare kan utnytte én CPU-kjerne om gangen. CPU-en er også den viktigste begrensningen når et dokument kompileres. Derfor vil jo raskere enkeltkjerneytelsen til CPU-en din er, desto raskere vil du kunne kompilere et dokument. Flere kjerner vil bare hjelpe hvis du prøver å kompilere flere dokumenter enn du har ledige CPU-kjerner. --- # 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/on-premises-no/kom-i-gang/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.