Oppdatert: Det defekte minnet er nå byttet ut!

[Pseudopod]

Eller for tidlig!

[After Dark]

Da hadde jeg det første problemet med at forumet falt ut siden dette ble fikset.

[Kimm0n0]

Da tas det kopi av databasen, derfor er forumet tregt og uresponsivt rundt klokken 4 hver natt. Backup-en starter 4 og det tar 10-30 minutter.

 

Er det load som går opp da eller er IO problemet da? Hvilken lagring bruker dere?

[rvenes]

De har blitt for store ja, klarer ikkje å følge med på hardware sida.

[amund]

Er det load som går opp da eller er IO problemet da? Hvilken lagring bruker dere?

 

IO går betydelig opp når det tas backup. Databasen er på 22 GB, og det tar naturlig nok litt IO å kopiere alt dette. Det største problemet er likevel at den største tabellen (den med forumpostene) er MyISAM. MyISAM fungerer slik at den låser hele tabellen for skriving når det tas backup av denne tabellen. Dermed må alle som prøver poster et innlegg i de minuttene posts-tabellen kopieres vente til kopieringen av denne tabellen er ferdig. Ved å bytte til tabelltype InnoDB vil vi bli kvitt denne begrensningen, men det krever samtidig at vi først må bytte ut forumsøket.

 

Backup-rutinen starter kl. 0400. Mads skal få lagt inn en melding i forumet som dukker opp automatisk hver natt mellom 0400 og 0430 som varsler at vi tar backup og at forumet derfor vil være litt ustabilt i denne peridoen.

 

Mvh,

Amund

[G]

Ja, det er en server som kjører webserver (Apache) og en server som kjører databasen (Mysql).

Det koster jo litt å sikre seg mot nedetid.

 

Men det er jo fullt mulig å virtualisere en server som kjører spredd over flere fysiske servere. De fysiske serverene i ett slikt oppsett kan tas ut av det kjørende systemet, uten å påvirke driften annet enn litt svakere ytelse. Om en f.eks. plutselig får en defekt server i systemet, kan en så plugge inn en ny reserve-server.

Endret 8. april 2011 av G

[kyrsjo]

Er det load som går opp da eller er IO problemet da? Hvilken lagring bruker dere?

 

IO går betydelig opp når det tas backup. Databasen er på 22 GB, og det tar naturlig nok litt IO å kopiere alt dette. Det største problemet er likevel at den største tabellen (den med forumpostene) er MyISAM. MyISAM fungerer slik at den låser hele tabellen for skriving når det tas backup av denne tabellen. Dermed må alle som prøver poster et innlegg i de minuttene posts-tabellen kopieres vente til kopieringen av denne tabellen er ferdig. Ved å bytte til tabelltype InnoDB vil vi bli kvitt denne begrensningen, men det krever samtidig at vi først må bytte ut forumsøket.

 

Backup-rutinen starter kl. 0400. Mads skal få lagt inn en melding i forumet som dukker opp automatisk hver natt mellom 0400 og 0430 som varsler at vi tar backup og at forumet derfor vil være litt ustabilt i denne peridoen.

 

Mvh,

Amund

 

Jøss, er ikke databasen til diskusjon.no større enn 22 GB? Regner med at dette stort sett kun er teksten i forumpostene, og at vedlegg etc. lagres et annet sted? Hvaslags storage bruker dere?

[blackbrrd]

Ja, det er en server som kjører webserver (Apache) og en server som kjører databasen (Mysql).

Det koster jo litt å sikre seg mot nedetid.

 

Men det er jo fullt mulig å virtualisere en server som kjører spredd over flere fysiske servere. De fysiske serverene i ett slikt oppsett kan tas ut av det kjørende systemet, uten å påvirke driften annet enn litt svakere ytelse. Om en f.eks. plutselig får en defekt server i systemet, kan en så plugge inn en ny reserve-server.

Tror ikke du har lyst å virtualisere en databaseserver som praktisk talt ikke virker når den har 16gb istedetfor 32gb minne.

[G]

Hva? Er det en minnebegrensning en snakker om her blackbrrd?

 

Er det noe problem å virtualisere høyere enn 32 Gigabyte med virtuell RAM?

[Theo343]

Ja, det er en server som kjører webserver (Apache) og en server som kjører databasen (Mysql).

Det koster jo litt å sikre seg mot nedetid.

 

Men det er jo fullt mulig å virtualisere en server som kjører spredd over flere fysiske servere. De fysiske serverene i ett slikt oppsett kan tas ut av det kjørende systemet, uten å påvirke driften annet enn litt svakere ytelse. Om en f.eks. plutselig får en defekt server i systemet, kan en så plugge inn en ny reserve-server.

Dette innlegget var omtrent like matnyttig som "det er fult mulig å sikre seg mot alt".

Endret 8. april 2011 av Theo343

[Gjest Slettet+9871234]

Samtidig er vi til min kjennskap den dag i dag verdens største IPB 3.X-forum, så det er ikke lett verken for dem eller oss å forutse ytelsesproblemer og skaleringsproblemer i forkant av oppgraderinger.

Inntekter skal vel helst dekke kostnadene, så jeg vet ikke om forumdriften er direkte og indirekte lønnsom.

 

Se på denne

 

http://www.phpbb.com/community/viewtopic.php?t=135383

 

monstertråden og se om der er interessante løsninger for dere.

 

Last balansering, rack eller clustering hvor man kan ta ut en server uten at det merkes hadde nok vært det beste.

 

Hva med den nyeste innen cloud hosting hvor man automatisk oppskalerer ved at en kapasitetsgrense overskrides?

[blackbrrd]

Hva? Er det en minnebegrensning en snakker om her blackbrrd?

 

Er det noe problem å virtualisere høyere enn 32 Gigabyte med virtuell RAM?

Nei, jeg tenkte på at du må ha tilgang til den 22gb store databasen...

[Lindsay]

Det er uansett ikke verdens undergang ting tar bare litt lenger tid

[Jotun]

Så bra dette var en såpass enkel sak å løse.

 

Hva sier du "hr representant for teknisk", hva med å løse de andre "ytelsesproblemene" mens du er igang?

 

Det har jo tatt litt tid?

[amund]

Hadde det vært en veldig enkel løsning på ytelsesutfordringene (f.eks. ved å bytte til cloud computing) hadde vi selvsagt gjort det :-)

[Jotun]

Vel, i mitt hode er en oppgradering noe som gjør noe bedre.

 

Her har det jo bare vært surr siden oppdateringen.

[Kimm0n0]

Hadde det vært en veldig enkel løsning på ytelsesutfordringene (f.eks. ved å bytte til cloud computing) hadde vi selvsagt gjort det :-)

 

Fortsett å tweake MySQL og en dag finner du gull og så går alt easy peasy etter det

[blackbrrd]

Synd det ikke er støtte for Postgresql i IPB.

 

Btw, hva slags disksystem kjører dere på databaseserveren? Med bare 22gb database burde det jo gå veldig bra å kjøre det på SSD-er. På den andre siden så er kanskje ikke skrive-ytelsen det største problemet?

[TSP]

Strengt tatt bedret ytelsen seg etter forrige oppdatering. I alle fall merket jeg en merkbar bedring i forhold til 3.0, dette var blant annet grunnet tilbakemeldinger/feilrapporter sendt til IPS fra oss, men det er fremdeles langt fra optimalt.

 

3.0-oppdateringen derimot, den var ikke spesielt hyggelig..

[blackbrrd]

Har vel strengt tatt ikke noe å klage over når det kommer til ytelse nå.

 

Forresten helt enig i at se-nyeste-foruminnlegg featuren var viktig å beholde. Det gjør det så utrolig mye lettere å følge med i tråder og er en feature jeg bruker HELE tida. (Sammen med mine innlegg)