> 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/da/kom-godt-i-gang/requirements/hardware-requirements.md). # Hardwarekrav ## Hardwarekrav Når du klargør 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 100 brugere i alt, men kun forventer, at ca. 5 vil arbejde på samme tid, vil den minimale installation være tilstrækkelig. Hvis du forventer, at en større andel arbejder (og kompilerer) samtidig, bør du overveje at klargøre en server med en højere specifikation. ### Minimal installation Et minimumskrav på 2 kerner og 3 GB hukommelse er nødvendigt for 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 tungere brug. {% hint style="danger" %} Hvis du overvejer at bruge et NFS-baseret (Network File System) filsystem til din lille instans, så tag venligst et kig på dette afsnit i [Fejlfinding](/on-premises/da/support/troubleshooting.md) afsnittet. {% endhint %} ### Skalering Som tommelfingerregel bør der for at levere et højt og ensartet serviceniveau tilføjes 1 CPU-kerne og 1 GB hukommelse til den minimale installation for hver 5-10 samtidige brugere. Dette bør kun tages som en vejledning, da faktorer som størrelsen på typiske dokumenter (større dokumenter bruger flere kompileringressourcer), hvor ofte brugerne kompilerer, og hvor stor tolerance der er for længere kompileringstider ved tung brug, alle påvirker det nødvendige klargøringsniveau. Mange af vores kunder ønsker at implementere Server Pro på tværs af hele organisationen eller store teams. I de situationer er det svært for os at rådgive om specifikke opsætningskrav, fordi anvendelsesscenarierne og den tilgængelige underliggende hardware kan variere meget. | Eksempel 1 | Eksempel 2 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Hvis du kører en Server Pro-installation til 300 brugere i alt og regelmæssigt 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. | Som 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 udstyret med to 4-kernede processorer og 32 GB systemhukommelse. Dette har været tilstrækkeligt til teamets behov i det seneste års brug. | Kunder, der overskrider grænserne for en enkelt stor server, kan se på [Vandret skalering](/on-premises/da/vedligeholdelse/horizontal-scaling.md) for Server Pro. ### Lagring Vi fraråder at bruge Network File System (NFS)/Amazon EFS/Amazon EBS til projekt-/historiklagring i større opsætninger og **understøtter det ikke** til vandret 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 I/O-operationer. Disse stop kan føre til, at Redis-baserede låse overskrides, 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 dermed ikke påvirker adfærden for resten af applikationen. Derudover kan Server Pro angive rimelige tidsgrænser for S3-anmodninger, hvilket ikke er muligt for filsystem-/I/O-operationer på applikationsniveau. {% hint style="info" %} Til reference følger GitLab en lignende linje med [ikke at understøtte NFS/Amazon EFS](https://docs.gitlab.com/ee/administration/nfs.html) i sit 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 kompileringanmodninger 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 accepterer pr. worker. Antallet af workers styres af [`worker_processes`](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) indstillingen og er som standard sat til 4 i vores nginx-konfiguration. Nginx udfører ikke meget arbejde sammenlignet med andre dele af systemet, så disse grænser fungerer som en sikkerhed, der forhindrer, at for mange forbindelser overbelaster systemet. Det er bedre at afvise nogle overskydende forbindelser tidligt end at sænke hastigheden på hver eneste forbindelse. Overleaf Server-instanser eksponerer miljøvariabler til at justere 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-afslutning), skal NGINX_KEEPALIVE_TIMEOUT i Overleaf Server-instansen være større end den foregående 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 enkeltkerne-ydeevne er, desto hurtigere vil du kunne kompilere et dokument. Flere kerner hjælper kun, hvis du forsøger 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://overleaf-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.