Din Hostingpakke: Hvorfor 3 GB RAM Bliver til 640 MB og Timeouts
Oplever du, at din hjemmeside pludselig går ned, udløser “Page Faults” og timer ud i timevis, selvom dine hostingstatistikker viser et lavt forbrug på kun 20% RAM og 5% CPU?
Dette er en frustrerende og alt for almindelig situation i Shared Hosting-verdenen. Forklaringen ligger i et misforhold mellem, hvad din host markedsfører (f.eks. 3 GB RAM), og de usynlige, hårde begrænsninger – især CloudLinux’s LVE-system – der i virkeligheden styrer din servers ydeevne.
Denne artikel forklarer, hvorfor din server fejler ved et lavt forbrug (f.eks. 640 MB ud af 3 GB) og giver dig den tekniske indsigt i, hvordan CloudLinux prioriterer serverstabilitet over dine tildelte ressourcer.
Myten om Det Lave Forbrug
Det er intuitivt at tænke: Hvis jeg kun bruger 5% CPU og 20% af min RAM, er der masser af overskud, og serveren burde ikke have problemer. Desværre er dette en fejlslutning i et Shared Hosting-miljø.De tal, du ser (CPU-procent og RAM-gennemsnit), er misvisende af to årsager:
1. Gennemsnit vs. Spidsbelastning (Spikes)
Dit gennemsnitlige forbrug på 5% CPU kan dække over en sandhed, hvor din server i et millisekund rammer 100% CPU, mens den behandler en kompleks forespørgsel, hvorefter den falder til 0% igen. Din overvågningssoftware viser kun gennemsnittet, men CloudLinux registrerer spidsbelastningen, der udløser fejlen (fault).
2. De Sande Flaskehalse er Usynlige
I Shared Hosting er CPU og RAM sjældent de virkelige begrænsninger. Den reelle grænse for ydeevnen sættes af to andre, ofte usynlige, ressourcer:Entry Processes (EP): Antallet af samtidige anmodninger (PHP-scripts) din konto må behandle. Dette er den mest almindelige årsag til, at servere går ned i timevis.I/O (Input/Output): Grænsen for, hvor hurtigt data må læses fra eller skrives til disken (f.eks. i MB/s).Eksempel: Hvis din I/O-grænse er meget lav, vil en databaseforespørgsel, der normalt tager 0,1 sekund, pludselig tage 5 sekunder, fordi den skal vente på diskadgang. I ventetiden hober nye Entry Processes sig op og rammer EP-loftet, hvilket udløser den langvarige timeout.
Den Største Fejlkilde – Låste Entry Processer
Når du oplever en timeout, der varer i timevis, selvom dit RAM-forbrug er lavt (f.eks. kun 620 MB ud af 3 GB), er dit problem næsten helt sikkert relateret til Entry Processes (EP).
Hvorfor EP Får Serveren til at gå i knæ:
- EP-Grænsen Nås: Din host har sat en hård grænse (f.eks. 25) for samtidige anmodninger. Hvis 26 besøgende kommer samtidig, afvises den 26.
- Processerne Bliver Låst: Hvis blot én af de 25 tilladte processer hænger fast (f.eks. venter på en langsom databaseforespørgsel eller en ekstern API-kald), bliver den låst.
- Køen Blokeres: De låste processer frigiver ikke Entry Process-pladsen. Nye besøgende afvises eller tidsbegrænses.
- Langvarig Timeout: Serveren forbliver i “knæ”, indtil de låste processer automatisk dræbes af systemet (hvilket kan tage minutter eller timer) eller manuelt genstartes af din host.
Virkelighedens scenario: RAM-forbruget (de 640 MB) er simpelthen den sum af RAM, som de 25 låste, hængende processer brugte. RAM er ikke årsagen til fejlen; det er de låste processer, der forårsager at siden timer ud og serveren ikke længere svarer på forespørgsler.
Den Tekniske Sandhed – CloudLinux LVE vs. Tildelt RAM
Her går vi i dybden med, hvorfor de 3 GB RAM, du betaler for, i virkeligheden kun er en teoretisk mulighed, og hvorfor du fejler ved 620 MB.
CloudLinux og LVE (Lightweight Virtual Environment)
CloudLinux er operativsystemet, der bruges af de fleste Shared Hosting-udbydere. Det er designet til at isolere hver kunde i sin egen virtuelle beholder kaldet en LVE. Formålet er at forhindre, at én ustabil kunde (en “bad neighbor”) vælter hele serveren.
PMEM (Physical Memory) – Forskellen Mellem To Grænser
Når din host tildeler dig 3 GB RAM, taler de ofte om en Burst Limit eller den Maksimale Allokering. Men CloudLinux håndhæver en anden, langt mere aggressiv grænse: PMEM Hard Limit.
Burst Limit er den Maksimale Allokering af RAM: Den teoretiske mængde RAM, din konto kan bruge, hvis den er ledig, og alle andre grænser er i orden. F.eks 3072 MB (3 GB) som din udbydere annoncerer med.
Hard Limit er PMEM Current Limit: Den absolutte, hårdt håndhævede grænse, din konto aldrig må overskride i et splitsekund. Sandsynligvis 640 MB. Den grænse varierer, men er altid væsentligt lavere end Burst Limit.
1. Page Fault som LVE-Håndhævelse
I CloudLinux betyder en RAM-relateret “Page Fault” (eller en “LVE Fault”) ikke nødvendigvis, at hele serveren har brugt al sin RAM. Det betyder, at din konto har ramt sin PMEM Hard Limit.
Hvis din Hard Limit er 640 MB:
- Hvis du bruger 620 MB, er du tæt på.
- Hvis ét enkelt script forsøger at allokere kun 30 MB mere (totalt 650 MB), udløser CloudLinux øjeblikkeligt en PMEM Fault.
- Processen dræbes, og systemet nægter at fortsætte, da den har overskredet den Hard Limit, der er sat for stabilitet.
Konklusion: Din host har sat din PMEM Hard Limit væsentligt lavere (måske 640 MB) end din Burst Limit (3 GB). Dette er ikke nødvendigvis teknisk snyd, men en måde at prioritere serverens overordnede stabilitet på bekostning af dine tildelte ressourcer.
2. Den Sande Flaskehals Er Entry Processes (EP)
Som beskrevet i Del 2, er det EP-grænsen, der forårsager de langvarige timeouts og det lave, men fastlåste RAM-forbrug (620 MB).Hvis din EP-grænse er 25, og den overskrides, afviser LVE simpelthen nye HTTP-anmodninger, hvilket fører til din timeout. Dette er, hvad der får serveren til at føles “i knæ” i timevis, selvom den tildelte RAM stadig har over 2 GB ubrugt potentiale.
Hvad du skal gøre for at slippe fri?
For at løse problemet skal du gå væk fra de Shared Hosting-begrænsninger, der pålægges af CloudLinux LVE:
- Tal med din Host: Bed dem om at oplyse din faktiske PMEM Hard Limit og din Entry Processes (EP) grænse.
- Optimer din Side: Hvis du ikke vil opgradere, skal du fokusere på at reducere Entry Processes (f.eks. bedre caching, begrænsning af bots og optimering af tunge SQL-forespørgsler).
- Opgrader til VPS: Hvis din hjemmeside har brug for de fulde 3 GB RAM og et højt antal samtidige besøgende, er skiftet til en Virtual Private Server (VPS) nødvendigt. En VPS giver dig garanterede ressourcer, hvor de 3 GB RAM er dine alene, uden de stramme EP- og PMEM Hard Limits.
Hvor Shared Hosting er Ideel
Shared Hosting er den perfekte og mest omkostningseffektive løsning til projekter, der har:
- Lav, stabil trafik: Få lokale besøg, hvor trafikken sjældent spiker.
- Enkle tekniske krav: Hjemmesiden har ingen tunge beregninger, komplekse databasetransaktioner eller tunge tredjeparts-API-kald.
- Lave forventninger til samtidighed: Kun få besøgende er online på samme tid (typisk under 5-10 Entry Processes).
- Budgetfokus: Prioritering af lav pris over ultimativ ydeevne og skalerbarhed.
Eksempler: Terapeutens informationsside, en lille blog uden stor mediebevågenhed, en privat persons CV-side, eller et lille foreningswebsite. En meget lille webshop nærmer sig grænsen.