[MYSQL] Replication

[Verwijderd]

Ik ben op dit moment bezig met een webshop van een klant, en de webserver werkt an sich snel. Het probleem zit hem in de mysql-database: Deze heeft het namelijk ontzettend zwaar. Nu werken we al met een simpel cache meganisme maar dit kan op lang niet alle pagina's, omdat dit actuele data moet zijn. Ook zijn alle query's bekeken en is er gechekt of er indexes staan, daar waar ze nodig zijn.

Nu zit ik te denken aan een master-slave configuratie om zo de load te kunnen verdelen.

Alleen vroeg ik mij af hoe jullie users een bepaalde server toewijzen. Doen jullie dit random, of vragen jullie de load op van de server?
En heeft replicatie altijd nut, of zijn er nog dingen waar je eerder naar moet kijken?

[Verwijderd]

Heb je de DB op een aparte machine staan ?

Specifieke webshop (systeem bedoel ik dan) ?

[ Voor 15% gewijzigd door Verwijderd op 17-08-2010 20:52 ]

[Verwijderd]

Nee de db staat op dezelfde server, en de webshop is erg uitgebreid en is idd een systeem op zichzelf

[Verwijderd]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 20:55:
Nee de db staat op dezelfde server, en de webshop is erg uitgebreid en is idd een systeem op zichzelf

Zelf gebouwd ?
dus geen magento, virtuemart ofzo ?

Maar heeft de DB het zwaar door de vele requests, of zorgen maar een paar requests voor de hoge belasting?
Of zijn er specifieke requests die voor te zware belasting zorgen (show all products oid) ?
Of is de machine misschien te zwak voor en de shop (de webpage zegmaar) en de db te hosten?s

[ Voor 36% gewijzigd door Verwijderd op 17-08-2010 20:59 ]

[Verwijderd]

Zelf gebouwd ja

Met een single request heeft hij het ook zwaar, en meerdere wordt het alleen maar erger. Idd zware querys zorgen voor enorm veel belasting. Simpele querys gaan nog best rap.

Het is een quad-core met 8gig ram, ik heb zelf niet heel veel verstand van servers maar het is volgens mij wel een rap bakje.

[burne]

Voor process-latency doen meer cores niet zoveel.


Maar begin bij het begin. Log in op het ding, wget mysqltuner.pl, draai het eens (mysql-root nodig, dat wel) en post de resultaten hier.

code:

wget mysqltuner.nl
perl -w mysqltuner.pl

(leuk toch, een poolse domeinnaam?)

[cariolive23]

Ga eerst eens uitzoeken wat nu precies het probleem is, voordat je nieuwe problemen gaat aanmaken met MySQL-replicatie.

1) Hoeveel concurrent database users zitten er op de database?
2) Zijn er andere processen die de database (gruwelijk) in de weg zitten?
3) Heb je de configuratie van de server en van de database al geoptimaliseerd?
4) Mocht hardware het probleem zijn, waarom schaf je dan geen betere hardware aan? Voor replicatie heb je ook al andere hardware nodig, één server is aanmerkelijk eenvoudiger in onderhoud dan twee servers. En dan heb ik het nog niet eens over MySQL-replicatie, wat geen feest is.
5) Over hardware gesproken, hoe ziet de configuratie eruit?
6) PostgreSQL loopt veel harder en schaalt veel beter dan MySQL wanneer het wat complexer en/of drukker wordt. Een migratie is een optie.

[Verwijderd]

burne schreef op dinsdag 17 augustus 2010 @ 21:10:
Voor process-latency doen meer cores niet zoveel.


Maar begin bij het begin. Log in op het ding, wget mysqltuner.pl, draai het eens (mysql-root nodig, dat wel) en post de resultaten hier.

code:

wget mysqltuner.nl
perl -w mysqltuner.pl

(leuk toch, een poolse domeinnaam?)

De server is niet in ons beheer, dus hier zou ik morgen even een ticket voor moeten aanmaken. Beide commando's uitvoeren of 1 van beide(ze zien er redelijk identiek uit )?

1) Hoeveel concurrent database users zitten er op de database?
2) Zijn er andere processen die de database (gruwelijk) in de weg zitten?
3) Heb je de configuratie van de server en van de database al geoptimaliseerd?
4) Mocht hardware het probleem zijn, waarom schaf je dan geen betere hardware aan? Voor replicatie heb je ook al andere hardware nodig, één server is aanmerkelijk eenvoudiger in onderhoud dan twee servers. En dan heb ik het nog niet eens over MySQL-replicatie, wat geen feest is.
5) Over hardware gesproken, hoe ziet de configuratie eruit?
6) PostgreSQL loopt veel harder en schaalt veel beter dan MySQL wanneer het wat complexer en/of drukker wordt. Een migratie is een optie.

1) Dit loggen wij niet, maar dit fluctueert nogal. Ik denk zo rond de 20 - 300
2) Bedoel je dit op cpu niveau, dat kan ik namelijk in directadmin wel bekijken.
3) We hebben de query's geoptimaliseerd, alleen is het voor mij lastig inschatten wat er nog meer kan. Hoe zou ik dit moeten vast stellen dan?
4) Ik dacht dat replicatie sneller is/was dan 1 bak met betere hardware, omdat het dan niet via 1 server loopt(maar dit zal wel te kort door de bocht zijn )
5)

Intel(R) Xeon(R) CPU E5504 @ 2.00GHz
Total Memory 16623852 kB
Free Memory 8196436 kB
MySQL 5.0.67
Php 5.2.12

6) Dit lijkt mij liever een stap die ik als laatste zou zetten. Ook omdat we een aantal webshops(vele malen kleiner) op shared hosting hebben draaien, en hier is postgre niet op mogelijk

[ Voor 7% gewijzigd door Verwijderd op 17-08-2010 21:24 ]

[Creepy]

Even een tikje door naar Serversoftware en Windows Servers

PRG -> SWS

[Verwijderd]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 21:21:
[...]

6) Dit lijkt mij liever een stap die ik als laatste zou zetten. Ook omdat we een aantal webshops(vele malen kleiner) op shared hosting hebben draaien, en hier is postgre niet op mogelijk

Denk er dan is overna om over te gaan op VirtuelServerHosting oid, heb je meer invloed op wat je draait en hoe.
SharedHosting is leuk maar op den duur houdt het op met de mogelijkheden en/of performance.

[cariolive23]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 21:21:
1) Dit loggen wij niet, maar dit fluctueert nogal. Ik denk zo rond de 20 - 300

Je hebt het hier over concurrent database users? Of het aantal bezoekers op jouw website? Dat zijn twee totáál verschillende dingen.

MySQL kan in elk geval niet uit de voeten met "veel" concurrent users, vanaf 10 users gaat het al hard bergafwaarts met de performance. Sinds 5.1.x gaat het beter, maar die gebruik je dus niet.

2) Bedoel je dit op cpu niveau, dat kan ik namelijk in directadmin wel bekijken.

Wanneer er behalve de database nog andere dingen draaien, dan kunnen deze zaken elkaar in de web zitten. Zo kan bv. een mailserver of webserver alle I/O opeisen en staat de database te wachten tot de schijven weer beschikbaar zijn. Jouw database op een eigen server zetten, zou dan al een oplossing kunnen zijn.

3) We hebben de query's geoptimaliseerd, alleen is het voor mij lastig inschatten wat er nog meer kan. Hoe zou ik dit moeten vast stellen dan?

Je hebt de queries geoptimaliseerd, maar de databaseserver zelf ook? Door het juiste filesystem te kiezen, gaat de database zich al anders (beter?) gedragen, door betere geheugenconfiguraties kan het ook al beter gaan, etc. etc. etc.

4) Ik dacht dat replicatie sneller is/was dan 1 bak met betere hardware, omdat het dan niet via 1 server loopt(maar dit zal wel te kort door de bocht zijn )

Wanneer jouw database langzaam is, zal de replica ook langzaam zijn. Die staat te wachten op data vanaf de master. Daarnaast wordt beheer een kostbare zaak, er kan nog veel meer fout gaan. En MySQL kent de nodige bugs en rottigheden met replicatie, dat is niet über betrouwbaar.

5)
Intel(R) Xeon(R) CPU E5504 @ 2.00GHz
Total Memory 16623852 kB
Free Memory 8196436 kB
MySQL 5.0.67
Php 5.2.12

Flink wat RAM, heb je jouw database daarop geconfigureerd? Zo niet, dan verklaart dat direct waarom je nog zoveel RAM vrij hebt: De database mag dit dan blijkbaar niet gebruiken.

Jouw MySQL-installatie loopt ernstig achter, deze wordt niet eens meer ondersteund. Ga upgraden naar de laatste 5.1-release, die wordt in elk geval nog tot eind dit jaar ondersteund. Daarna is het ook over en sluiten, maar dan ben je nu tenminste weer even up to date.

6) Dit lijkt mij liever een stap die ik als laatste zou zetten. Ook omdat we een aantal webshops(vele malen kleiner) op shared hosting hebben draaien, en hier is postgre niet op mogelijk

Snap ik, dit is wat ingrijpender. Maar het levert wel de grootste performance winst op. Wij draaien tot 500 concurrent users op soortgelijke hardware (met RAID 10, 4 schijven) en de database is vooral druk met niks doen. Ja, de DB verwerkt een 1500 queries per seconde, maar dat komt toch vrijwel allemaal uit RAM (de recente data is de data waarmee wordt gewerkt, dat past in RAM). Betreft OLTP, dus continue verwerking en geen website waar gebruikers tussendoor ook nog eens wat tekst moeten lezen.

1) Ga een betere versie van MySQL installeren
2) Ga een betere configuratie opzetten
3) Ga kijken wat nu het echte probleem is
4) Ga de database op zijn eigen server neerzetten
5) Hou in je achterhoofd dat MySQL niet goed schaalt en dat een migratie naar bv. PostgreSQL een optie is. MySQL heeft na 31-12-2010 geen active support meer, dat kan ook een probleem worden.

Maar replicatie, daar zou ik voorlopig nog even niet aan beginnen. Wat je nu voorspiegelt, moet makkelijk op jouw huidige server kunnen performen.

[burne]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 21:21:
De server is niet in ons beheer, dus hier zou ik morgen even een ticket voor moeten aanmaken. Beide commando's uitvoeren of 1 van beide(ze zien er redelijk identiek uit )?

Beiden, na elkaar. De een download een perlscript, de ander voert het uit. Het script doet een aantal commando's (vooral show global variables) en parst de resultaten in een begrijpbare vorm.

Het laat je zien hoeveel geheugen je maximaal gebruikt, hoeveel daadwerkelijk, hoe efficient je caching is, en geeft wat algemene tips voor optimalisatie. De meest nauwkeurige resultaten krijg je op een database-server die al langere tijd draait, omdat je daarmee over een langere periode de efficiency van bijvoorbeeld table- en query-caches bekijkt.

[b][message=34537875,noline]cariolive23 schreef op dinsdag 17 augustus 2010 @ 5) Hou in je achterhoofd dat MySQL niet goed schaalt en dat een migratie naar bv. PostgreSQL een optie is.

Dat mantra hoort men vaker. Maar je geeft(impliceert?) zelf al aan dat je 1500 qps draait met MySQL. Ik daag je uit om dat na te doen op identieke hardware met pgsql en dezelfde workload. Want je doet natuurlijk niet zonder reden ook zelf MySQL voor die toepassing. Pgsql is nog altijd beter met veel complexe queries, pqsql zit wat dichter tegen formeel correct ANSI SQL aan, en heeft meer toeters en bellen. Maar replicatie ontbreekt nog altijd, clustering staat nog niet eens op de roadmap, en voor veel eenvoudige queries op eenvoudige datasets is het nog altijd een traag, log monster. Een webshop met 100.000 bezoekers per uur mag blij zijn met een bestelling per minuut, dus iets wat select als een gek ventje afragt heeft de voorkeur boven iets wat partial indexes of bitmap indexes correct implementeert.

Da's geen anti-pgsql rant, het is erkenning voor de verschillen tussen de twee. Beiden hebben hun eigen hoekje van de markt.

[GlowMouse]

cariolive23 schreef op dinsdag 17 augustus 2010 @ 21:51:
[...]

MySQL kan in elk geval niet uit de voeten met "veel" concurrent users, vanaf 10 users gaat het al hard bergafwaarts met de performance. Sinds 5.1.x gaat het beter, maar die gebruik je dus niet.

Jij telt waarschijnlijk anders dan TS.

Replicatie helpt wel bij reads, maar als writes het probleem zijn dan los je dat niet op. Bovendien zul je je code moeten aanpassen zodat reads verdeeld worden.

Zware queries kun je ongetwijfeld verbouwen of aanpassen. Heb je wat meer details?

Ik zou er anders iemand naar laten kijken die er wel verstand van heeft. Inventariseren wat er bij een db-server misgaat, kost op een forum erg veel vragen terwijl een getraind oog zo ziet wat er misgaat.

[ Voor 22% gewijzigd door GlowMouse op 18-08-2010 01:28 ]

[cariolive23]

burne schreef op woensdag 18 augustus 2010 @ 00:51:
Dat mantra hoort men vaker.

Zie deze tests van Tweakers op hun eigen database. Dit betreft een test met MySQL 5.0 (wat de TS gebruikt) en PostgreSQL 8.2.

En ik heb al gezegd dat MySQL 5.1 beter schaalt, maar of dat genoeg is? Dat zal de TS zelf moeten ontdekken wanneer hij migreert naar deze versie.

Maar je geeft(impliceert?) zelf al aan dat je 1500 qps draait met MySQL.

Lijkt me sterk dat ik 1500 qps draai op MySQL, ik gebruik geen MySQL. En dat is niet zonder reden, MySQL kan dit helemaal niet aan op de hardware die als minimale systeemeis bij onze klanten neerleggen.

Daarnaast verliezen we dan transactionsafe DDL, wat we toch bij iedere update van de systemen gebruiken. Dat is zo mogelijk nog belangrijker voor ons, maar dat terzijde.

Ik daag je uit om dat na te doen op identieke hardware met pgsql en dezelfde workload. Want je doet natuurlijk niet zonder reden ook zelf MySQL voor die toepassing.

Volgens mij heb je niet goed gelezen, wij gebruiken geen MySQL en dat is juist omdat MySQL de load niet aankan. Althans niet op de budgethardware die onze klanten willen gebruiken. Oorzaak: MySQL kan niet goed uit de voeten met veel concurrent users. En omdat wij heel veel queries binnen hun eigen transacties uitvoeren, moet ook de connectionpool nog een groot aantal concurrent connections opzetten (tot 500).

Maar goed, de TS heeft reeds een lijstje met ToDo's waarmee hij aan de slag kan gaan. Het is wel zaak om eerst eens duidelijk te krijgen hoeveel concurrent users er op de database zitten, dan wordt de omvang van het probleem direct een heel stuk duidelijker.