> 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/da/kom-godt-i-gang/requirements/hardware-requirements.md). # Hardwarekrav ## Hardwarekrav Når du allokerer hardware til at køre Overleaf, er den vigtigste faktor at overveje, hvor mange samtidige brugere der vil køre kompileringer. For eksempel, hvis du har en licens til i alt 100 brugere, men kun forventer, at \~5 arbejder på samme tid, vil den minimale installation være tilstrækkelig. Hvis du forventer, at en større andel arbejder (og kompilerer) samtidigt, bør du overveje at allokere en server med en højere specifikation. ### Minimal installation Et minimumskrav på 2 kerner og 3 GB hukommelse er påkrævet til grundlæggende drift med omkring 5 samtidige brugere. Dette minimumskrav vil også være tilstrækkeligt for større grupper, hvor der er mindre samtidig brug, eller hvor det er acceptabelt, at kompileringstiderne er længere ved højere belastning. {% hint style="danger" %} Hvis du overvejer at bruge et NFS (Network File System)-baseret filsystem til din lille instans, så tag et kig på dette afsnit i [Fejlfinding](/on-premises/da/support/troubleshooting.md) afsnittet. {% endhint %} ### Skalering Som en tommelfingerregel bør der for at levere et højt og konsistent serviceniveau tilføjes 1 CPU-kerne og 1 GB hukommelse til den minimale installation for hver 5-10 samtidige brugere. Dette bør kun opfattes som en rettesnor, da faktorer som størrelsen på typiske dokumenter (større dokumenter bruger flere kompilationsressourcer), hvor ofte brugerne kompilerer, og hvor stor en tolerance der er for længere kompileringstider under høj belastning, alle påvirker det nødvendige niveau af allokering. Mange af vores kunder ønsker at udrulle Server Pro på tværs af hele organisationen eller på tværs af store teams. I de situationer er det svært for os at rådgive om specifikke opsætningskrav, fordi brugsscenarierne og den underliggende hardware, der er til rådighed, kan være meget forskellige. | Eksempel 1 | Eksempel 2 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Hvis du kører en Server Pro-installation til i alt 300 brugere og jævnligt forventer, at 30-60 af disse brugere kompilerer dokumenter på samme tid, bør 8 GB og 7 kerner (5 kerner + 5 GB + basis på 2 kerner og 3 GB) give tilstrækkelige ressourcer til, at dine brugere kan have et konsekvent højt serviceniveau. | For at give et eksempel på hardwarekravene til en større udrulning er en Server Pro-installation til 1.000 brugere i alt blevet sat op med succes ved hjælp af en enkelt server med to 4-kerneprocessorer og 32 GB systemhukommelse. Dette har været tilstrækkeligt til teamets behov gennem det seneste års brug. | Kunder, der overskrider grænserne for en enkelt stor server, kan se på [Horisontal skalering](/on-premises/da/vedligeholdelse/horizontal-scaling.md) for Server Pro. ### Lagerplads Vi fraråder at bruge Network File System (NFS)/Amazon EFS/Amazon EBS til projekt-/historikelagring i større opsætninger og understøtter det eksplicit **understøtter det ikke** til horisontal skalering. Adfærden for disse filsystemer leverer ikke den nødvendige ydeevne og pålidelighed, som Server Pro har brug for ved drift i stor skala. Når filsystemet ikke kan følge med belastningen, går applikationen i stå på grund af for mange blokerende IO-operationer. Disse stop kan føre til overskrevne Redis-baserede låse, hvilket igen kan resultere i beskadigede projektdata. Vi anbefaler at bruge [S3-kompatibel objektlagring](/on-premises/da/kom-godt-i-gang/what-is-the-overleaf-toolkit.md) i stedet. Langsom S3-ydeevne påvirker kun upload/download af filer, hvilket kun fører til et øget antal åbne forbindelser til din S3-udbyder og derfor ikke påvirker adfærden i resten af applikationen. Derudover kan Server Pro angive rimelige timeouts på S3-anmodninger, hvilket ikke er muligt for filsystem-/IO-operationer på applikationsniveau. {% hint style="info" %} Til orientering har GitLab en lignende holdning med [ikke at understøtte NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) i deres selvhostede tilbud. {% endhint %} ### Nginx-specifik konfiguration til store udrulninger Som standard begrænser Overleaf Server-instansen antallet af forbindelser til 768. Dette inkluderer vedvarende WebSocket-forbindelser, HTML-navigation på øverste niveau og ajax-anmodninger. Når grænsen nås, kan editoren muligvis ikke oprette forbindelse, editorsiden indlæses muligvis ikke helt, og kompileringsanmodninger kan fejle. Nginx vil returnere status 500-svar og logge `worker_connections er ikke tilstrækkelige under forbindelse til upstream` i `var/log/nginx/error`.log inde i `sharelatex` containeren. Den [`worker_connections`](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) indstillingen begrænser antallet af samtidige forbindelser, som nginx vil acceptere pr. worker. Antallet af workers styres af indstillingen [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) og er som standard sat til 4 i vores nginx-konfiguration. Nginx udfører ikke særlig meget arbejde sammenlignet med andre dele af systemet, så disse grænser fungerer som en sikkerhed, der forhindrer for mange forbindelser i at overvælde systemet. Det er bedre at afvise nogle overskydende forbindelser tidligt end at gøre hver eneste forbindelse langsommere. Overleaf Server-instansen stiller miljøvariabler til justering af disse nginx-indstillinger: * `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 der kører en anden proxy foran sharelatex containeren (f.eks. til TLS-terminering), skal NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen være større end den forrige proxy. F.eks. med en anden nginx-proces på Docker-værten nginx-host, er her to eksempler:

* Standardværdi `NGINX_KEEPALIVE_TIMEOUT`, brug [`keepalive_timeout 60s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (standardværdi i upstream) i **nginx-host** * Brugerdefineret værdi `NGINX_KEEPALIVE_TIMEOUT=100s`, brug [`keepalive_timeout 90s`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout) (brugerdefineret værdi i upstream) i **nginx-host** ### CPU-hastighed LaTeX er et enkelttrådet program, hvilket betyder, at det kun kan udnytte én CPU-kerne ad gangen. CPU'en er også den primære begrænsning ved kompilering af et dokument. Derfor gælder det, at jo hurtigere din CPUs single-core-ydeevne er, desto hurtigere vil du kunne kompilere et dokument. Flere kerner hjælper kun, hvis du prøver at kompilere flere dokumenter, end du har ledige CPU-kerner. --- # 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/da/kom-godt-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.