[olsserik]

En av mina VPS:er krånglar till det ett par ggr per vecka nuförtiden. Det är webservern som går ner och trots autostart vill den ej starta förrän jag själv startar den. Hittar inget i de loggar jag kan se, men det kanske finns andra att kolla.

Inget fel annars vad jag kan se, normal belastning, nedgången kan till och med ske på tidig morgon med mycket lite trafik.

Är det någon som har några tips ang detta?

Tack.

[najk]

Kika på programmet monit för övervakning, larm och åtgärd. Skulle kunna vara minnet som tar slut på burken. Finns det inga httpd processer igång?

[abergman]

Tycker det låter ganska rimligt med att minnet i maskinen dör, prova att kompilera Apache2 själv och kör det genom gdb annars, så får du backtracen på när den dör.

[olsserik]

Hej,
Ok, ska kolla på detta. Kan kanske vara minnet. När jag kollat så har det inte varit några problem ens vid hög belastning. Det enda anmärkningsvärda verkar vara att CPU förbrukas en hel del under kortare stunder, men ändå inte så det bottnar liksom.

skulle minnesbrist kunna orsaka att den inte autostartar alltså?

[Magnus_A]

Se till så att vps:en inte har burst, det vill säga extra minne som tilldelas lite då och då. När det dras tillbaka krashar appliaktionerna som då helt saknar minne.
Antar att du kör php och det är inte alltid så lätt. Rekommenderar fastcgi, då kan man styra minnesanvändningen bättre.
monit är bra för att ha koll, och även munin, så får du fina grafer.

[emilv]

Detta liknar minnesfel men det är svårt att säga exakt utan mer data. Därför är övervakning bra (det är bra av andra anledningar också, som att man får varningar och ibland även kan förebygga problem). Om du kör till exempel GD så kan du plötsligt börja använda mycket minne (för att någon postar en stor bild eller liknande), och ibland slår man i taket. Även andra sorters skript kan trigga hög minnesanvändning men GD är något jag sett flera gånger på olika sajter.

Får du slut på minne kommer Linux som standard att börja döda processer mer eller mindre slumpmässigt, vilket kan ge obehagliga konsekvenser; du vet inte längre vilka program som är igång och vilka som inte är det. Kanske finns det beroenden mellan programmen som inte längre kan uppfyllas.

Om du kör Apache med mod_php kan det även vara bra att veta att Apache som standard aldrig lämnar tillbaka det minne som PHP använder. Om du använder mycket minne i ett skript kommer detta minne därför bara kunna användas av Apache i fortsättningen - och kör du preforkad Apache (vilket många gör med PHP) blir problemet ännu värre eftersom minnet bara kan användas av just den Apache-processen! Ett inte helt ovanligt problem är därför att du kanske har ett skript som slukar mycket minne ibland, men varje gång skriptet körs hanteras det av olika Apache-processer. Varje process behåller minnet och till slut är det slut.

Den bästa lösningen är att köra PHP som FastCGI, men har du inte möjlighet till det kan en nödlösning vara att konfigurera Apache till att då och då döda sina processer och forka om dem. Kolla då på inställningen maxrequestsperchild som du kan behöva sätta till ett lägre värde.

Allt detta förutsatt att det faktiskt är minnet som är problemet. Börja med att hitta felet innan du börjar fundera på lösning.

[Magnus_A]

Det låter som om man inte ska använda Apache och php?

[emilv]

Ursprungligen postat av Magnus_A

Det låter som om man inte ska använda Apache och php?

Apache med mod_php bör man undvika. Apache med PHP via FastCGI går alldeles utmärkt. Då kan man även använda mpm_worker istället för mpm_prefork vilket ökar prestandan hos Apache även för statiska filer.

Personligen föredrar jag Nginx som webbserver, ett byte som är rätt lätt när man väl kör FastCGI-PHP, men förstår att många vill ha styrkan i Apaches konfigurationsmöjligheter. Fördelen med Nginx är att prestandan är så fantastiskt bra. Nginx är riktigt bra på att hantera uppkopplingar; en passiv uppkoppling kostar i stort sett ingenting så man kan sätta Keepalive hur stor man vill. Den nyttan kan man få även om man behåller Apache genom att låta Nginx agera reverse-proxy framför Apache men då börjar vi komma från ämnet :-)