Gå til innhold

Oppdatert: Det defekte minnet er nå byttet ut!


Anbefalte innlegg

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

 

Hadde postgresql vært støttet ville vi selvsagt testet det. Jeg er ikke overbevist om at det ville løst alle problemer, men det er mulighet for at det ville gått raskere.

 

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?

 

Databasen ligger på et SAN med SAS-disker. SSD-disker montert rett i serveren tror jeg ville gitt bedre ytelse, men til gjengjeld er det mer upraktisk å vedlikeholde enn et SAN.

 

Den viktigste ytelsesforbedringen tror jeg uansett vil være å bli kvitt fulltekstindeksen og MyISAM-tabelltype på posts-tabellen. Før vi får gjort dette må vi bytte ut søkemotoren, men dette er noe vi jobber med nå.

Lenke til kommentar
Videoannonse
Annonse

Lokal lagring i bladsenteret ville nok gitt dere bedre database ytelse for diskusjon.no enn via et SAN. Noen bladservere støtter vel også 2 drev i selve bladet. Vi har i mange år alltid oppnådd vesentlig bedre og godt merkbare resultater ved å flytte databaser ut fra SAN. Og det utallige typer SAN helt opp til de dyreste klassene uten veldig stor last i SANet.

 

Rene, tunge databaser er derfor noe vi, så langt som overhodet mulig, strever etter å ikke ha i SAN systemer. Vi kjører selv forskjellige typer SAN etc. Vi opplever faktisk bedre ytelse ved å la dedikerte databaseservere med lokal lagring håndtere flere databaser.

 

Driftmessig er det ikke store implikasjoner å skille ut rene, tunge databaser. Men før man begynner med dette så bør helt klart selve databasen optimaliseres og div. ledd rundt.

 

Nå har ikke jeg særlig kompetanse rundt forumdrift, men hvilke årsaker er det til at dere ikke velger databasesystemer som også kanskje skalerer bedre? Såvidt jeg kan se støtter Invision både Oracle og MSSQL. Og lisenspenger burde jo ikke være et problem i landets største forum? Er det fordi kompetanse på drift og utvikling begrenser seg til MySQL?

 

PS.

Jeg vet at MySQL ble kjøpt av Oracle men det er alikevel vidt forskjellige systemer. Men det er klart at overgang til InnoDB vil forbedre ytelse vesentlig, samt en oppgradering til 5.5 samtidig.

Compared to MyISAM, InnoDB delivered 35x higher throughput on the Read / Write test and 5x higher throughput on the Read-Only test, with 90% scalability across 36 CPU cores.
Endret av Theo343
Lenke til kommentar

Hadde postgresql vært støttet ville vi selvsagt testet det. Jeg er ikke overbevist om at det ville løst alle problemer, men det er mulighet for at det ville gått raskere.

 

 

Databasen ligger på et SAN med SAS-disker. SSD-disker montert rett i serveren tror jeg ville gitt bedre ytelse, men til gjengjeld er det mer upraktisk å vedlikeholde enn et SAN.

 

Den viktigste ytelsesforbedringen tror jeg uansett vil være å bli kvitt fulltekstindeksen og MyISAM-tabelltype på posts-tabellen. Før vi får gjort dette må vi bytte ut søkemotoren, men dette er noe vi jobber med nå.

Tror ikke Postgres hadde vært noen magisk løsning heller, jeg har bare veldig god erfaring med Postgres 8.3 og oppover*.

 

@Theo343 Oracle støtten ble borte i IPB 3.x

 

*Kjørte 7.x en stund også, bra med features, men ikke veldig bra ytelse. Byttet til 8.1 og fikk et stort hopp i ytelse, men slet etterhvert med skrive-ytelsen. Byttet til 8.3 som fikser problemer med skrive-ytelsen i visse tilfeller og har ikke hatt noen problemer siden. (Vi har kjørt 8.3 i omtrent 3 år nå, på samme hardware med en stadig voksende database uten problemer). Har tenkt å bytte til 9.x for hot-standby replikering og mulighet til å ta backup fra hot-standby maskinen. Det vil da også være mulig å kjøre tunge statistikk-spørringer fra denne.

Lenke til kommentar

Rene, tunge databaser er derfor noe vi, så langt som overhodet mulig, strever etter å ikke ha i SAN systemer. Vi kjører selv forskjellige typer SAN etc. Vi opplever faktisk bedre ytelse ved å la dedikerte databaseservere med lokal lagring håndtere flere databaser.

 

Interessant (og egentlig ikke så overraskende). For databaser er det jo én ting som teller og det er hastighet. SSD-disker lokalt i serveren ville nok derfor vært en suveren vinner om vi kunne velge løsning på nytt. Inntil vi har testet mulige software-oppgraderinger vil vi vente med å oppgradere maskinvaren.

 

Nå har ikke jeg særlig kompetanse rundt forumdrift, men hvilke årsaker er det til at dere ikke velger databasesystemer som også kanskje skalerer bedre?

 

Det er svært tidkrevende og kostbart å teste ut hvor mye bedre Oracle eller andre databaseløsninger skalerer enn den vi har i dag, særlig når det er MySQL vi har erfaring og kompetanse på. Dessuten vet vi at det vil hjelpe å bytte fra MyISAM til InnoDB, men det tar tid å skrive en ny søkemotor som fungerer raskt nok.

 

EDIT: Ser at blackbrrd skriver at Oracle-støtten forsvant i IPB3.x, og da er jo ikke det noe option heller..

Lenke til kommentar

amund IPB3.x har fortsatt støtte for MSSQL

 

Recommended Requirements

MySQL 5+, or

MSSQL 2005+ (see note in sidebar)

MSSQL Support

We support MSSQL with a separate database driver, available for $75. To purchase our suite with MSSQL support, please contact us

 

Jeg har erfaring fra Postgres og fra og med 8.3 skalerer den svært bra, tipper det blir på samme nivå som MSSQL og Oracle. Fra og med versjon 9.0 så støtter den hot standby i tillegg.

 

Angående MySQL, så ser det ihvertfall ut som 5.5 er en god ide hvis du skal bruke InnoDB:

http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-performance-improvements-on-windows/

Endret av blackbrrd
Lenke til kommentar

Angående MySQL, så ser det ihvertfall ut som 5.5 er en god ide hvis du skal bruke InnoDB:

http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-performance-improvements-on-windows/

 

Vi kjører SUSE Linux. Vet du om de samme forbedringene gjelder Linux?

Forbedringene ser ganske store ut på linux også, men det ser ut til at det er på høyt antall connections det spiller størst rolle. Vet ikke hvor mange dere har kjørende samtidig...

 

Regarding the second point, or type of scale, we've really improved the scalability on multi-core machines. If you look specifically at the 16-core machine, we're about three times faster on a 16-core machine than we were with 5.1.

 

Q: Tomas, you referred to performance benchmarks over 5.1 earlier, can you come back on those results and provide some more details?

A: Sure. We've run benchmarks at scale with about 1,000 database connections, both Read Only and Read/Write. Previously with MySQL 5.1 you would see performance drop as you added connections, but that's no longer the case with MySQL 5.5. We've managed to sustain the performance when scaling. On Linux you see, at scale with over 1000 connections, 200% performance improvement over 5.1 for Read Only operations, and about 370 % performance for Read/Write ones. On Windows, the performance improvements are even more impressive as I mentioned earlier due to the specific optimization we've performed. We're seeing at scale over 500% improvement over 5.1 for Read Only operations. So overall, both peak performance and scalability have gone up significantly with MySQL 5.5.

 

http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html

Lenke til kommentar

Rene, tunge databaser er derfor noe vi, så langt som overhodet mulig, strever etter å ikke ha i SAN systemer. Vi kjører selv forskjellige typer SAN etc. Vi opplever faktisk bedre ytelse ved å la dedikerte databaseservere med lokal lagring håndtere flere databaser.

 

Interessant (og egentlig ikke så overraskende). For databaser er det jo én ting som teller og det er hastighet. SSD-disker lokalt i serveren ville nok derfor vært en suveren vinner om vi kunne velge løsning på nytt. Inntil vi har testet mulige software-oppgraderinger vil vi vente med å oppgradere maskinvaren.

 

Nå har ikke jeg særlig kompetanse rundt forumdrift, men hvilke årsaker er det til at dere ikke velger databasesystemer som også kanskje skalerer bedre?

 

Det er svært tidkrevende og kostbart å teste ut hvor mye bedre Oracle eller andre databaseløsninger skalerer enn den vi har i dag, særlig når det er MySQL vi har erfaring og kompetanse på. Dessuten vet vi at det vil hjelpe å bytte fra MyISAM til InnoDB, men det tar tid å skrive en ny søkemotor som fungerer raskt nok.

 

EDIT: Ser at blackbrrd skriver at Oracle-støtten forsvant i IPB3.x, og da er jo ikke det noe option heller..

Helt på linje med det du svarer :).

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...