Mit websted er langsomt/CPU-forbruget er for højt/antal processer
Det kan være, at du har fået besked fra os om, at dit websted belaster CPU'en (processorerne i serverne) for meget eller bruger for mange processer. Det kan ganske enkelt skyldes et stort antal besøgende, men i 99,9 % af tilfældene er det ikke årsagen.
Nogle store/tunge websteder (som webshops) har allerede ved normal brug brug for mere regnekraft end andre websteder. Er du overbevist om, at webstedet fungerer korrekt, gælder nedenstående ikke. I så fald er det en mulighed at opgradere til en stærkere hostingpakke med mere regnekraft. Se vores hostingpakker her.
Herunder gennemgår vi kort, hvad der kan være årsager til et højt CPU-forbrug. Hvis et for højt CPU-forbrug ikke bliver løst (i tide), kan det betyde, at din konto/dit websted bliver begrænset (automatisk). Så snart CPU-forbruget er i orden igen, bliver dit websted automatisk slået til igen. Bliver det dog ved med at gentage sig inden for kort tid, bliver det til sidst ikke længere slået til automatisk
Disse foranstaltninger er nødvendige for at beskytte serverne mod overbelastning. Ved at tage fat på overbelastningen sænker du ikke kun CPU-forbruget, men dit websted bliver også betydeligt hurtigere og dermed meget mere behageligt at besøge.
Langsomt websted og plugins
Websteder, der er lavet i for eksempel WordPress eller Joomla, kan godt have problemer med langsomhed. Næsten altid ligger årsagen i plugins, der ikke fungerer godt eller simpelthen er dårligt udviklet. Har du problemer med langsomhed, er rådet at slå alle dine plugins fra et øjeblik og så se, om webstedet så er hurtigt. Er det tilfældet, slår du plugins til igen én ad gangen og tjekker hver gang, om webstedet stadig er hurtigt, indtil synderen er fundet.
Langsomt websted på grund af mange databaserecords
En anden årsag til langsomhed kan være, at der er kommet så mange records i databasen (vi ser nogle gange mange millioner records), at webstedet får problemer. Det er ofte statistiktabeller eller tabeller, hvor ting bliver logget. Det burde normalt ikke være et problem, men hvis databasetabellen ikke er designet godt, og der søges i mange data, uden at der er oprettet et korrekt indeks, kan det give stor langsomhed.
Cache i din lokale browser
Det sker jævnligt, at det ikke er serveren, men din egen browser, der er blevet langsom på grund af en cache, der er for fuld. Tøm cachen, og/eller prøv en anden browser for at se, om det også er langsomt der. Se for eksempel http://www.ehow.com/how_8618453_fix-slow-firefox-ie8-browsers.html
Apache-logfiler / liste over processer
Har du fået besked fra os om CPU'en, kan der nederst i e-mailen være vist en liste over processer og IP-adresser. Ud fra listen kan man måske udlede noget, men det kan også være, at der ikke er nogen liste, eller at den ikke indeholder meget. I sådanne tilfælde kan logfilerne måske hjælpe. Der finder du nemlig information om alle besøgende på dit websted, og hvilke filer de har hentet hvornår. Det er en god idé at gennemgå disse filer omkring tidspunktet for meddelelsen, og det kan give et godt indtryk af mulige problemer. Du finder denne information i de såkaldte Apache-logfiler. Dem kan du se via kontrolpanelet under Webstedsoversigt / Statistik / Logs og så Fuld fejllog/brugslog for dagens logfil. Logfilerne fra tidligere dage finder du under Gemte Apache-logs. Du kan også se logfilerne via FTP eller filhåndteringen i mappen /domains/ditdomæne.xx/logs. Bemærk, at der er separate logfiler for subdomænerne i subdomænemenuen.
Skal jeg være bekymret?
Ikke umiddelbart. Først hvis du får disse advarsler meget ofte, er der sandsynligvis noget strukturelt galt. Falske meldinger forekommer som regel ikke rigtig, men forholdene varierer fra øjeblik til øjeblik. Et script eller en forespørgsel, der ikke er godt opbygget, kan for eksempel normalt altid gå godt, men på et tidspunkt, hvor der er travlt på den pågældende server, alligevel udløse en advarsel.
Mulige årsager til for højt CPU-forbrug
- Du har et fotoalbum på webstedet, og i stedet for den lille version af billederne har du den fulde version på webstedet. Når du så viser billedet, skal CPU'en først skalere det originale billede på nogle gange mange MB ned, før det kan vises. Gør et par besøgende det samtidig, kan det give et stort CPU-forbrug.
- Mulige løsninger: Læg kun formindskede billeder på dit websted, og sørg for (det er det vigtigste), at det format, du viser billederne i, også svarer til billedernes rigtige format, så serveren ikke skal formindske noget, men kun vise det. Læg om nødvendigt flere versioner på webstedet. At bruge mere diskplads er mindre slemt end at bruge mere CPU.
- I forlængelse af den første årsag: at vise billeder via et PHP-program (streaming) er mange gange langsommere end at indsætte billedets URL direkte.
- Mulige løsninger: Indsæt den direkte URL til billeder, grafik osv., og lad det ikke gå via et PHP-program. Det er langsommere og belaster CPU'en unødigt.
- Du giver besøgende mulighed for at kommentere en artikel, et billede eller lignende. Hvis du ikke beskytter det med en såkaldt captcha eller begrænser det til brugere, der har registreret sig, kan spammere begynde at misbruge det, så CPU'en kan stige (ekstremt).
- Du lader en webside automatisk genopbygge / opdatere hvert X. sekund, så CPU'en belastes unødigt.
- Mulige løsninger: Fjern refresh fra siden. Som regel sidder det i headeren eller eventuelt i JavaScript.
- Du bruger en database til dit websted. Så er det vigtigt, at databasen også er helt optimeret. Med det menes især, at der findes tilstrækkelige og korrekte indekser. En database med nogle (ti)tusinde records/rækker kan med et par besøgende og dårlig eller ingen indeksering meget hurtigt give ydeevneproblemer.
- Mulige løsninger: Optimér din database. OGSÅ hvis det er en standarddatabase. Bruger du for eksempel OScommerce med få records, er der ikke noget problem. Gør du det med mange records, skal der virkelig optimeres. Ikke kun CPU-forbruget falder markant, dit websted bliver også betydeligt hurtigere og dermed mere behageligt at besøge.
- Dit websted har kørt i lang tid uden problemer, og pludselig bliver det langsomt, og du får CPU-meldinger.
- Mulige løsninger: Der er stor sandsynlighed for, at problemet findes i databasen. Med tiden kommer der flere og flere records/rækker i den, og så ender vi hurtigt ved det foregående punkt, at databasen ikke er indekseret godt. Det er vigtigt at optimere databasen godt.
- Du har et websted med rigtig mange enkeltfiler. Hvis du starter filhåndteringen i DirectAdmin, får du sandsynligvis endda en timeout, fordi den først vil læse hele mappestrukturen, og det tager for lang tid. I så fald kan du ikke bruge filhåndteringen i DA og er henvist til FTP. Det er dog aldrig en god idé at gemme mere end 1.000 filer i 1 mappe. Et operativsystem får hurtigt problemer med det, backups bliver langsomme, åbning af filer bliver langsom osv. osv.
- Mulige løsninger: Brug zip- eller rar-filer, hvor det er muligt, og opret undermapper med højst 500 til 1.000 filer pr. mappe. Men egentlig er det for et websted bedst at undgå ekstremt store filstrukturer.
- Det kan være, at bestemte tabeller i din database er vokset ubemærket. Det er en god idé engang imellem at se på din database via phpMyAdmin og tjekke, om antallet af records pr. tabel svarer til dine forventninger.
- Er der tabeller med mange records, så tjek, om det virkelig er nødvendigt, og ryd op i tabellerne, hvor det er muligt. Går det ikke, så se, om din database kan optimeres.
Processer
En webserver kan håndtere et bestemt antal processer ad gangen (antallet af processer har intet med antallet af besøgende at gøre). Det særlige ved en webserverproces er, at den altid kun er aktiv meget kort. Den leverer siden til brugeren og er så færdig. Det sker som regel på brøkdele af et sekund, nogle gange lidt længere, hvis det er store sider. På den måde kan én proces levere siderne til brugerne for rigtig mange websteder/besøgende. Når processer bliver ved med at være åbne, bliver de ikke længere genbrugt, og med tiden løber serverens hukommelse fuld, så den ikke kan nås, især hvis antallet af besøgende samtidig stiger. Altså en uønsket og usædvanlig situation. Inden da griber vi automatisk ind, og det pågældende websted bliver deaktiveret.
Mulige årsager til at bruge for mange processer
- Du har et script/program, der opretter forbindelse til en anden server via for eksempel curl. Forbindelsen mislykkes, og dit program bliver ved med at vente. Sker det for flere brugere, kan der hurtigt opstå et problem.
- Sørg for, at hvert kald altid har en timeout. Aldrig mere end 1 eller 2 sekunder, for hvis brugeren skal vente længere, klikker vedkommende alligevel væk.
- Dit websted bliver 'leechet'. Det betyder, at noget eller nogen automatisk forsøger at kopiere dit websted. Alle dele, billeder osv.
- Prøv at finde de mulige IP-adresser, der forårsager det, i Apache-logfilen, og prøv at blokere dem. Se vores FAQ for en artikel om blokering af IP-adresser.
- Du indlæser et RSS-feed fra et andet websted, hver gang en side opdateres. Det er ikke klogt. Det gør alt unødigt langsomt og kan også give disse problemer.
- Indlæs kun RSS-feeds hvert X. minut, og kun når der er besøgende. Sørg også for, at der gælder en timeout, når feedsene indlæses.