Dolda resursgränser som stryper WordPress (inoder, EP, 508)

Sajten dör vid trafik trots att paketet "ser stort ut"

Det är ett av de vanligaste mönstren vi ser: en WordPress-sajt som fungerar perfekt i vardagstrafik men plötsligt ger fel när nyhetsbrevsutskicket går ut, när en produkt hamnar i sociala medier eller när WooCommerce kör sin nattliga lagersynk. Paketet marknadsförs med "obegränsad bandbredd" och 10 GB lagring. Ändå kraschar sajten. Felet är inte vad du tror.

Det som stryper sajten är nästan aldrig bandbredden. Det är resursgränser som aldrig nämns på prissidan, verkställda av ett system som heter CloudLinux LVE, och de ser likadana ut oavsett om du betalar 29 kronor eller 99 kronor i månaden för ditt delade webbhotell. Den här artikeln ger dig ramverket för att förstå dem, hitta dem och avgöra vad du ska göra åt saken.

CloudLinux och LVE: mekanismen bakom gränserna

De allra flesta svenska delade webbhotell (och många VPS-planer med cPanel) kör CloudLinux som operativsystem. CloudLinux är byggd specifikt för hosting-miljöer och innehåller ett system kallat LVE (Lightweight Virtual Environment). Varje kundkonto på servern lever inuti sin egen LVE-container, isolerad från grannarna.

Det är faktiskt bra: din sajt påverkas inte av att grannen kör ett dåligt optimerat skript. Men LVE-containern har också tak, och de taken är vad hostingleverantören sällan berättar om i onboarding-mailet. De gäller alltid, oavsett hur mycket diskutrymme paketet inkluderar.

Gränserna som LVE typiskt verkställer är inoder, entry processes, CPU-tid och I/O-bandbredd. Vi går igenom dem en i taget, med fokus på hur de samverkar med WordPress.

Inoder: varje fil räknas

En inod (inode) är ett filsystembegrepp: varje fil, varje katalog och varje symbolisk länk på ditt konto tar upp exakt en inod. Storleken på filen spelar ingen roll, en textfil på 1 kB och en videofil på 1 GB tar lika stor "inod-plats".

Typiska inod-tak på delade webbhotell varierar, men 50 000 till 250 000 per konto är vanliga storleksordningar. Det låter som mycket tills man börjar räkna vad WordPress faktiskt innehåller.

En ren WordPress-installation med tjugo plugins kan lätt innehålla 30 000 till 50 000 filer. Lägg till ett cacheplugin som skriver statiska HTML-filer för varje URL, en säkerhetskopia som lagras lokalt på kontot, uppladdade bilder i fem olika storlekar (WordPress standard) och loggar från din webbserver. Det är inte ovanligt att ett medelstort WordPress-projekt med aktiv WooCommerce-butik och ett par hundra produkter nuddar inod-taket utan att ägaren vet om det.

Märk att det inte händer något dramatiskt omedelbart. Sajten fungerar. Men när inod-taket nås kan inga nya filer skapas på kontot. Cachepluginets skrivningar misslyckas tyst. Formulärspluginat kan inte spara uppladdade filer. WordPress kanske inte kan skriva sina egna temporärfiler. Felsymptomen ser slumpmässiga ut, och ingenting i WordPress egna felloggar pekar mot orsaken.

Hur du hittar din inodanvändning

Logga in i cPanel och leta efter sektionen Files eller Statistik i sidopanelen. Där visas "Inode Usage" som en stapel eller ett tal. Är du på 80 procent eller mer, börjar det bli dags att agera. Undersök vilka kataloger som äter flest inoder med filhanterarens detaljer eller via SSH. Cachekatalogerna och uppladdningsmappen brukar peka ut sig själva.

Entry processes: gränsen som slår till vid trafiktoppar

Entry processes (EP) är antalet PHP-processer som din LVE-container får köra samtidigt. Det är den gräns som oftast orsakar 508-felet och som förklarar varför sajten klarar vardagstrafiken men faller samman vid toppar.

Billiga delade planer har ofta ett EP-tak på 10 till 20 samtida processer. Mellanklassen kan ligga på 25 till 40. Det är direkt kopplat till prisnivån, men sällan tydligt kommunicerat.

Tänk på vad som händer vid ett nyhetsbrevsutskick till 3 000 prenumeranter. Mailplattformen skickar länkarna, ett par hundra personer klickar inom fem minuter. Varje sidvisning startar en PHP-process. Samtidigt kör WordPress sitt inbyggda schemaläggningssystem wp-cron, som triggas av varje sidladdning och kan starta egna processer för bakgrundsjobb. WooCommerce lägger kanske ovanpå med lagerstatus-kontroller och orderbehandling. Plötsligt försöker tjugo, trettio, fyrtio processer köras inom samma LVE-container. Taket nås, och servern svarar med HTTP 508.

Det som gör EP-gränsen extra svår att felsöka är att den är omedelbar och total. Servern startar inte ens PHP-processen när taket nås, den returnerar direkt ett fel. Det finns alltså ingen PHP-logg att titta i, inget WordPress-fel att läsa. Sajten svarar med ett felkod, och alla loggposter du kan hitta i WordPress är tysta.

508-felet: inte 500, inte 503

HTTP 508 är inte ett standardiserat felkod i den ursprungliga HTTP-specifikationen. Det är en CloudLinux/LVE-specifik kod som betyder exakt en sak: resursgränsen för din container är nådd. Servern lever, Apache/Nginx svarar, men din LVE-container nekar fler processer.

Det är viktigt att skilja den från sina närmaste grannar i felkods-rymden.

En del hostingleverantörer returnerar 503 istället för 508 när EP-taket nås, beroende på hur deras konfiguration ser ut. Om du ser 503-fel som uppenbart korrelerar med trafiktoppar snarare än planerat underhåll är EP-gränsen ändå det mest troliga spåret att undersöka.

Varför WP_DEBUG inte hjälper

Det här är detaljens detalj, och det är förklaringen till varför så många fastnar i felsökning i timmar.

WordPress egna felsökningsverktyg, WP_DEBUG, WP_DEBUG_LOG och plugins som Query Monitor, fungerar alla inuti en PHP-process. De kan rapportera vad som händer när WordPress körs. Men vid en EP-gränskrasch startar aldrig PHP-processen. LVE-containern nekar HTTP-anropet innan PHP-tolken ens aktiveras. Det finns ingenting för WordPress att logga.

Det är samma sak med vit skärm ("white screen of death"). En vit skärm kan bero på ett PHP-fel med felmeddelanden dolda, ett minnesproblem inom en PHP-process, eller en EP-krascha. Symtomen ser identiska ut för slutanvändaren. Skillnaden är att de första två kan felsökas i PHP-loggen och med WP_DEBUG, medan den tredje kräver att du tittar i cPanels Resource Usage-graf istället.

Det här är felet jag sett bakom flest "mystiska" WordPress-problem: man letar i fel lager. PHP-loggarna är tomma för att PHP aldrig körde.

I/O-throttling: diskläsning som flaskhals

Utöver inoder och entry processes begränsar LVE också diskens I/O-hastighet, mätt i MB/s. Varje container har ett tak för hur snabbt den får läsa och skriva till disk.

WordPress utan cachning är disk-intensivt. Varje sidladdning utan cachning genererar ett antal databasfrågor, men läser också PHP-filer från disk: WordPress core-filer, plugin-filer, tema-filer. På en delad server med roterande hårddiskar (och en del äldre SSD-lösningar med begränsat I/O-budget per konto) kan det bli ett problem vid belastning.

Typiska I/O-gränser på budgetplaner kan ligga i storleksordningen 1 till 10 MB/s. Det låter rimligt tills man betänker att ett cacheplugin som bygger statiska HTML-filer skriver kraftigt till disk vid cache-warmup, att WooCommerce-installationer med aktiv inventariespårning gör frekventa databasskrivningar och att bildbehandling vid uppladdning (generering av miniatyrbilder i WordPress) skapar korta men intensiva I/O-burst.

Tecknet på I/O-throttling är ofta att sajten svarar långsamt snarare än att den kraschar helt, och att det är värst direkt efter att cachen rensats eller när många produktbilder laddas upp simultant.

Hur du läser Resource Usage i cPanel

På servrar som kör CloudLinux med cPanel finns ett avsnitt som heter Resource Usage (ibland under etiketten "CPU and Concurrent Connection Usage"). Här ser du historik över ditt kontos resursförbrukning uppdelat på CPU-procent, entry processes, I/O och minnesgräns.

Det viktigaste att leta efter är inte medelnivåerna utan topparna. En graf som visar normalt EP-tal på 3 till 5 men med regelbundna toppar som slår i taket berättar historien klart. Korrelera topparna mot tidpunkter för schemalagda jobb, nyhetsbrevsutskick eller kändistrafik-toppar.

Om grafen visar att du regelbundet träffar EP-gränsen och ditt cacheplugin är korrekt konfigurerat, är det ett konkret tecken på att du vuxit ur den aktuella planen. Om gränsen bara träffas enstaka gånger vid extrema toppar är optimering ofta rätt väg.

Vad du kan göra: optimera, cachea eller flytta

Åtgärderna delar sig i tre nivåer.

Optimera WordPress-installationen

Börja med inoderna. Rensa gamla versioner av plugins och teman. Konfigurera ditt cacheplugin att inte skriva statiska filer för inloggade användare och kundvagn-sidor. Lagra backup-filer externt, inte på hostingkontot.

För entry processes är den starkaste åtgärden att konfigurera full sidcachning. En begäran som besvaras av en cachad statisk HTML-fil behöver inte starta en PHP-process alls. Med ett väl konfigurerat cacheplugin kan sajten hantera tiofaldig trafik utan att EP-taket ens märks. LiteSpeed Cache, WP Super Cache och W3 Total Cache kan alla konfigureras för att undvika onödiga cache-missar.

Inaktivera wp-crons standard HTTP-trigger och kör istället WordPress cron via en riktig server-cron (crontab). Det förhindrar att bakgrundsjobb startas av slumpmässiga sidladdningar, vilket kan skapa oväntade EP-toppar.

Uppgradera planen

Om optimering inte räcker och Resource Usage-grafen visar att du konsekvent träffar gränserna är nästa steg att uppgradera inom samma leverantör. Många erbjuder mellanklassplaner med högre EP-tak och I/O-budget. Fråga leverantören direkt vilka LVE-gränser som gäller för varje plan, och kräv ett svar i siffror, inte marknadsföring.

Flytta till VPS eller managed WordPress-hosting

Om du regelbundet träffar resursgränserna trots ett optimerat WordPress är det ett tydligt tecken på att delad hosting inte längre passar. En VPS ger dedikerade resurser utan LVE-begränsningar. Managed WordPress-hosting löser ofta problemet annorlunda, med arkitekturer byggda för PHP-processer och cachning på servernivå. Det är ett eget ämne som vi går igenom djupare i vår artikel om när WordPress växt ur delad hosting.

Sammanfattning: det som prissidan inte berättar

De gränser som faktiskt avgör hur din WordPress-sajt beter sig under last syns sällan på prissidan. Inod-taket avgör om du kan skapa nya filer. Entry process-taket avgör hur mycket trafik du kan ta emot simultant. I/O-budgeten avgör hur snabbt sajten kan läsa filer och skriva cache. Och 508-felet är serverns sätt att berätta att en av dessa gränser är nådd, inte ett PHP-fel, inte ett WordPress-fel, utan ett infrastruktur-fel som kräver ett helt annat felsökningsspår.

Nästa gång WordPress kraschar vid trafik och PHP-loggarna är tomma: öppna cPanels Resource Usage-graf och titta på vad som händer vid topptiderna. Svaret finns sällan i koden.