> 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/on-premises-no/kom-i-gang/requirements/hardware-requirements.md). # Maskinvarekrav ## Maskinvarekrav Når du skaffer maskinvare for å kjøre Overleaf, er den viktigste faktoren å vurdere hvor mange samtidige brukere som skal kjøre kompileringer. Hvis du for eksempel har en lisens for 100 brukere totalt, men bare forventer at rundt 5 jobber samtidig, vil den minste installasjonen være tilstrekkelig. Hvis du forventer at en større andel jobber (og kompilerer) samtidig, bør du vurdere å klargjøre en server med høyere spesifikasjon. ### Minimal installasjon Et minimumskrav på 2 kjerner og 3 GB minne er nødvendig for grunnleggende operasjoner 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 blir lengre ved høyere belastning. {% hint style="danger" %} Hvis du vurderer å bruke et filsystem basert på NFS (Network File System) for din lille instans, bør du ta en titt på denne delen i [Feilsøking](/on-premises/on-premises-no/stotte/troubleshooting.md) seksjonen. {% endhint %} ### Skalering Som en tommelfingerregel bør du for å gi et høyt og jevnt servicenivå legge til 1 CPU-kjerne og 1 GB minne til den minimale installasjonen for hver 5–10 samtidige brukere. Dette bør bare ses på som en veiledning, ettersom faktorer som størrelsen på typiske dokumenter (større dokumenter bruker opp flere kompilasjonsressurser), hvor ofte brukerne kompilerer, og hvor stor toleranse det er for lengre kompileringstid ved høy belastning, alt påvirker hvilket nivå av klargjøring som kreves. Mange av kundene våre ønsker å rulle ut Server Pro i hele organisasjonen eller på tvers av store team. I slike situasjoner er det vanskelig for oss å gi råd om spesifikke krav til oppsett, fordi bruksområdene 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 forventer at 30–60 av disse brukerne regelmessig skal kompilere dokumenter samtidig, bør 8 GB og 7 kjerner (5 kjerner + 5 GB + grunnlag på 2 kjerner og 3 GB) gi tilstrekkelige ressurser for at brukerne skal ha et jevnt høyt servicenivå. | For å gi et eksempel på maskinvarekravene for en større utrulling, er en Server Pro-installasjon for 1 000 brukere totalt satt opp med suksess ved bruk av én enkelt server utstyrt med to 4-kjerners prosessorer og 32 GB systemminne. Dette har vært tilstrekkelig for teamets behov gjennom det siste året med bruk. | Kunder som overstiger 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 å bruke Network File System (NFS)/Amazon EFS/Amazon EBS til lagring av prosjekt/historikk i større oppsett og støtter det uttrykkelig **ikke** for horisontal skalering. Oppførselen til disse filsystemene gir ikke den nødvendige ytelsen og påliteligheten som Server Pro trenger når det kjøres 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. Treg S3-ytelse påvirker bare opplasting/nedlasting av filer, noe som bare fører til et økt antall åpne forbindelser til S3-leverandøren din og igjen ikke påvirker oppførselen til resten av applikasjonen. I tillegg kan Server Pro angi rimelige tidsavbrudd for S3-forespørsler, noe som ikke er mulig for filsystem-/I/O-operasjoner på applikasjonsnivå. {% hint style="info" %} Som referanse har GitLab en lignende holdning 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 utrullinger Som standard begrenser Overleaf Server-instansen antallet tilkoblinger til 768. Dette inkluderer vedvarende WebSocket-tilkoblinger, HTML-navigasjon på toppnivå og ajax-forespørsler. Når grensen nås, kan det hende at redigeringsprogrammet ikke klarer å koble til, redigeringssiden lastes kanskje ikke helt inn, og kompileringforespørsler kan feile. Nginx vil returnere status 500-svar og logge `worker_connections er ikke nok ved tilkobling til upstream` i `var/log/nginx/error`.log inne i `sharelatex` containeren. The [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) -innstillingen begrenser antallet samtidige tilkoblinger nginx vil akseptere per worker. Antallet workers styres av [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) -innstillingen og er satt til 4 som standard i vår nginx-konfigurasjon. 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 hver tilkobling 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. For eksempel 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 i upstream) i **nginx-host** * Tilpasset verdi `NGINX_KEEPALIVE_TIMEOUT=100s`, bruk [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (tilpasset verdi i upstream) i **nginx-host** ### CPU-hastighet LaTeX er et program med én tråd, noe som betyr at det bare kan bruke én CPU-kjerne om gangen. CPU-en er også den viktigste begrensningen når et dokument kompileres. Derfor gjelder det at jo raskere enkeltkjernesytelsen 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://ayakaleaf-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.