Jag har märkt några gånger att Fotosidan "går trögt" vid 24-tiden på dan, förlåt dygnet. Varför, kör ni backup eller något annat? Har ni andra märkt samma sak?

11:59 och 23:59 roteras Apache loggarna, eftersom dom blir större en 2GB annars.

När dom är roterade så gzip:as dom, hela operationen brukar ta 2-4 minuter.

Backuperna på databaserna och filsystem går senare på natten ( runt 02:30 om jag minns rätt), men dom märks inte.


-Thomas

Är du säkert på det Thomas, någonstans där mitt i natten eller morgon kvisten, har för mig att det är runt 4a snåret, men det kan har varit 2:30 också så stannar allting upp. Jag brukar öppna ett gäng trådar åt gången, typ 10, men just någongång där så stannar allt upp, och väntar, i kanske 2 minuter, laddar inte, skickar inte upp svar, osv, sen laddar den vidare som om inget hade hänt.

Nja, visst har du rätt att "märks inte" är felaktigt ordval ...

Dataserna exporteras 03:30 och 04:30 tar 5-10 minuter per databas (Fotosidan består av 3 databaser). Exporten sker görs på tabellnivå, under den process så skapas det rad/tabelllås för att inga transaktioner skall exporteras "halv genomförda". Så då märks det ju ...

Sen vet jag inte om det skall betraktas som ett "problem" att sajten låses under 1-2 minuter några gånger per dygn. Dygnet innehåller trots allt 1440 minuter, min gissning är att under 99% av dessa minuter är allt normalt ...

Man bör ha i bakuvet att trafikmängden på Fotosidan är hög, i sommras gjorde jag en uträkning att FS i snitt skickar ut 10 jpeg bilder i sekunder året runt (~30 miljoner på en månad). Vi toppar på uppåt 1000 sql anrop i sekunden.

Storleksmässigt kan kanske inte jämföra med MSN, Lunarstorm eller Aftonbladet. Men dom sajterna har ju en teknikplattform som kostar minst ett 8 siffrigt belopp, troligen 9 siffror. Faktum kvarstår dock att även dom går på knäna ibland ..

EDIT: Anledningen till att databaserna exportas två gånger är för att vi vill ha dom på disk på två olika maskiner.

-Thomas

Vilken databas använder ni på Fotosidan?

Microsoft Access

FS kör Apache 1.3x, PHP 4.3.x samt MySQL 4.x på Linux burkar.


-Thomas

OK, då är hotbackups ingen option (såvida ni inte sätter upp en kopia och sen tar backuper på denna).

Vad skönt det är att jobba med dyra databaser i vardagslag;-)

mvh Christian

Så du menar att bara för att man ta hotbackups så märks inget på sajten ...det tror inte jag på.
Om backup tas på databasnivå så måste låsen uppstå, det tar tid att skriva på disken under "tillbaka" synkningen av loggen som uppstod under tiden backup:n gick,

Om man har ett SAN och gör backup på disknivå, gärna genom att leka med att slå isär speglingar då kan man backup:a enorma mängder data på kort tid utan att det märks.

Jag hoppas på att replikeringen i MySQL 4.1 är "osynlig" då kan vi göra som du föreslår. Dvs. replikera till en kopia som sen backup:as frekvent samt finns redo får tyngre bakgrunds operationer (såsom bevakningarna som diskuterats förrut).



-Thomas

I tex Oracle kan man ta backup på en fil i taget och Oracle fortsätter att hantera den filen som om inget hade hänt. Vad som händer är att den skriver förändringar i minnet, och loggfiler, och då en läsning skall göras så görs den i minnet, och i loggfilerna, under tiden som filen är låst.

Dvs man märker en prestandasänkning, men ingen totallåsning.

Så om man betalar big bucks så får man mer funktionalitet. Men mig gör det inget att databasen låses några minuter varje natt. Allt handlar om hur mycket man kan investera.

mvh Christian

FS databaserna låses inte, det är en skilda tabeller/rader som låses under backup ögonblicket. Backupen är en sqldump, dvs varje enskild rad skrivs ut till fil. Den största databasen i

Under den tiden som Oracle behöver på sig för att skriva ner backuploggen kommer rad/tabelllås behöva upprättas för att säkerställa intergriteten i databasen, dvs. samma effekt som vi ser här på FS uppstår. Hur lång den tiden sen är beror på ju på massa parametrar.

Grejen med en sajt såsom FS är ju att massa saker loggas, så även "titt" besök förändrar ju databasen. (Ex. skall antalet gånger en bild visas förändras, bannerannonserna skall man ju inte glömma) Jag har inte mätt hur många databasanrop som utförs av en besökare när man ex. laddar förstasidan eller "visa nästa tråd" i forumet. Jag vet bara att databaserna (dvs. flera) är av olika skäl är frekvent besökta i stora delar av databasen. Det är inte på designen som är problemet. Det är mängden information som båda skall hämtas och sen skrivas/uppdateras för varje besök/sidvisning som gör problemet lite komplexera. Vart jag vill komma är att "prestandasäkningen" blir upplevd som ett totallås istället. Så den enda lösningen på att "inget märks" är att göra backuperna på en nivå där databashanteraren inte är inblandad samt skriv/läsprestanden är så "rå" som möjligt, ex.så som jag skrev förrut i ett SAN på "disk till disk" nivå.


-Thomas

talthoff skrev:
11:59 och 23:59 roteras Apache loggarna, eftersom dom blir större en 2GB annars.

När dom är roterade så gzip:as dom, hela operationen brukar ta 2-4 minuter.

Klicka för att se resterande...

Tips: Stoppa Apache, döp om loggarna till ngt annat, starta Apache och gzip:a gamla loggen i efterhand. Kunderna (vi) kommer inte märka ett skit

/Johan, fd webgubbe vid ett av landets större internetleverantörer

Öhhh ....hur tror du vi gör idag ?

Gzippandet av filen kommer alltid ta tid, och kommer alltid att orsaka att disk i/o blir en trång sektor på maskinen. Eller har du en lösning på det oxå ?



-Thomas

talthoff skrev:
Öhhh ....hur tror du vi gör idag ?

Gzippandet av filen kommer alltid ta tid, och kommer alltid att orsaka att disk i/o blir en trång sektor på maskinen. Eller har du en lösning på det oxå ?

Klicka för att se resterande...

Ajaj, inte låta förnärmad nu

Om maskinprestanda eller annat sätter käppar i hjulen kan du ju vänta med packandet till senare under natten.

/Johan

talthoff skrev:
Öhhh ....hur tror du vi gör idag ?

Gzippandet av filen kommer alltid ta tid, och kommer alltid att orsaka att disk i/o blir en trång sektor på maskinen. Eller har du en lösning på det oxå ?

Klicka för att se resterande...

På inlägget tidigare lät det som att ni väntade på gzipandet innan ni startade upp igen )

/Johan

Det hade ju inte varit så smart, men så gör vi som sagt inte.

Vi gör

1) mv på g:a filen
2) apachectl restart
3) gzip av den g:a filen

Under 3 så blir disk i/o en flaskhals, som vissa tydligen har "märkt".

Även apachectl restart "märks" eftersom det under en kort tid skall forka:s ett gäng nya apache barn...

Hela diskussionen i den här tråden är ett lyx lite av ett "lyxproblem". Det är inte gzippande, filsystemsbackup eller databasbackupen som är dom stora "bovarna" mätt över dygnet. Det är "trafik stormar" och komplexa sökmöjligheter som trycker till maskinerna med ojämna/jämna mellanrum.

Jag har inga problem med att diskutera vidare, kom med flera förslag ....

-Thomas

talthoff skrev:
Det hade ju inte varit så smart, men så gör vi som sagt inte.

Vi gör

1) mv på g:a filen
2) apachectl restart
3) gzip av den g:a filen

Under 3 så blir disk i/o en flaskhals, som vissa tydligen har "märkt".

Även apachectl restart "märks" eftersom det under en kort tid skall forka:s ett gäng nya apache barn...

Hela diskussionen i den här tråden är ett lyx lite av ett "lyxproblem". Det är inte gzippande, filsystemsbackup eller databasbackupen som är dom stora "bovarna" mätt över dygnet. Det är "trafik stormar" och komplexa sökmöjligheter som trycker till maskinerna med ojämna/jämna mellanrum.

Jag har inga problem med att diskutera vidare, kom med flera förslag ....

-Thomas

Klicka för att se resterande...

Kan inte minnas att vi hade några kunder som klagade under vårt logroterande. Men jag hade kanske lite mer prestanda till mitt förfogande.

Mailade dig ett förslag av annan art.

/Johan

Anledningen till att jag märkte att det gick segt är att jag har semester.
På måndag börjar jag jobba igen, klock-f-n ringer 05.30 och då kan jag inte sitta och surfa mitt i nätterna, tyvärr.
Vad är Apache?

Jorek skrev:

Vad är Apache?

Klicka för att se resterande...

Det är en webservermjukvara - Läs mer här

/Johan

hansen2 skrev:
Kan inte minnas att vi hade några kunder som klagade under vårt logroterande. Men jag hade kanske lite mer prestanda till mitt förfogande.

Klicka för att se resterande...

Tror inte det handlar om "brist" prestanda, i detta fall.

Snarare om att mer normala/enklare sajter och kunder som kör på den typen av delade webbhotellsmaskiner där du jobbade.

Lösningen som är jag kan fixa nu på 4 sekunder är ju att rotera oftare, då kommer ni inte märka något av just den biten. Men att sajten "hickar" kommer kvarstå av dom olika skälen som jag skrev 2-3 inlägg upp.

-Thomas

Ja, jag hade nog last och trafik uppdelat på betydligt fler maskiner och inga flyttade logg samtidigt.

Hur mycket data och accesser per dygn handlar det om för FS ?

/Johan