Bekijk Volledige Versie : MySQL max queries per second
Om een beetje inzichtelijk te krijgen wat resulier is aan queries er second in MySQL wil ik graag vragen wat jullie doen. Uiteraard is het een beetje appels met peren vergelijken aangezien het aantal queries dat er doorheen kunnen sterk afhankelijk is van de hardware, Mysql cache en hoe de queries opgebouwd zijn.
Dit vraag ik omdat ik momenteel een klant heb die er 7500 queries per seconden doorheen drukt (in piektijd). Dit is echt enorm en kon ook alleen behaald worden na veel tweaken. Ik heb het idee dat dit echt het maximum is van MySQL zelf. Aangezien de hardware nog wel meer aankan maar MySQL het verdomt om er meer queries doorheen te douwen (connection timeouts, stroperig).
Ik denk dat marktplaats, wat wel wat meer doet dan 7500 queries per seconde, toch echt op mysql draait.
Je moet horizontaal en verticaal gaan schalen :)
7500 queries per seconden per server.
Klant doet er in totaal een kleine 20.000 (2 slaves 7.500, 1 master 5.000)
7500 queries per seconden per server.
Klant doet er in totaal een kleine 20.000 (2 slaves 7.500, 1 master 5.000)
Jij weet dat marktplaats met ruim 1500 servers draait en minimaal 50 MySQL servers ?
Ik snap je punt niet helemaal.
Kan namelijk prima wat je wil.
Het gaat om queries per seconden per server waarvan ik de max wil weten.
Dat je domweg meer slaves erbij kan prakken en daardoor ook meer queries kan verstouwen snap ik wel. Hyves doet er nog veel meer per seconden maar hebben wel een max van 1000 queries per seconden per server, als de stats hier overheen gaan lijken ze nieuwe servers erbij te gaan kopen.
BDigitinternetdiensten
03/12/09, 14:00
Nee indd, Ligt simpelweg aan hoe sterk je servers zijn en wat ze aankunnen. Je kan het dmv bepaalde instellingen en programma verdelen over een x aanttal servers.
Het gaat om queries per seconden per server waarvan ik de max wil weten.
Dat je domweg meer slaves erbij kan prakken en daardoor ook meer queries kan verstouwen snap ik wel. Hyves doet er nog veel meer per seconden maar hebben wel een max van 1000 queries per seconden per server, als de stats hier overheen gaan lijken ze nieuwe servers erbij te gaan kopen.
Hyves is er niet op gecode om minder queries te kunnen draaien.
Voorbeeld is dat marktplaats vanaf den beginne al is geschreven om over meerdere DC's te draaien en dus data in SQL te verdelen... hier kwamen ze bij hyves wat laat achter dus was dat niet meer helemaal recht te trekken.
Dus de HW zegt niet direct alles... tuurlijk is dat belangrijk maar in dergelijke gevallen ga je altijd meteen kijken of je risico kan scheiden aan de hand van verdeling van tabellen over meerdere servers.
De wil dus eigenlijk schalen maar weet niet direct hoe wie wat en waar maak ik uit je verhaal op ?
volgens mij zoekt hij gewoon een tool om het max aantal queries wat hij aankan te testen
hiervoor is er gewoon de MySQl benchmark Suite van mysql zelf
Nee, ik wil er achter komen wat gebruikelijk is bij grote partijen als marktplaats, hyves en facebook. Klant waarover ik praat zit namelijk in dezelfde category (> 100 alexa ranking wereldwijd).
Ramon Fincken
03/12/09, 20:56
En op wat voor een hardware ( denk aan schijven, RAM ) draait dit geheel? Dedi mysql cluster? of op de zelfde webserver (fysiek) ?
is NU.nl groot genoeg? [alexa: 656 <- hoger dan marktplaats zie ik net]
FE#1
MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 3
Historic max_used_connections = 38
FE#2
MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 4
Historic max_used_connections = 32
BACKEND#1
MAX CONNECTIONS
Current max_connections = 250
Current threads_connected = 13
Historic max_used_connections = 166
FE#3
MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 3
Historic max_used_connections = 46
FE#4
MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 5
Historic max_used_connections = 40
BACKEND#2
MAX CONNECTIONS
Current max_connections = 1000
Current threads_connected = 3
Historic max_used_connections = 12
Dit trek ik net van de servers af.
Zo zie je maar door het goed in te richten van een [web]applicatie dat het helemaal niet zwaar hoeft te zijn. Backend servers zijn waar de redactie hun artikelen in opslaan wat weer naar de mysql slaves word gepushed.
Uiteraard is dit niet het enige wat voor NU.nl draait er draait nog veel meer.
Ik moet echt meer info hebben om iets nuttigs tegen te te zeggen:
wat voor applicatie gaat het? En wat Ramon net zei.
Dag Allemaal,
... en als je echt groot wilt gaan, lees dan maar eens wat over de z.g. "nosql" en "bigdata" hypes. Ik heb wat dingen gezien op Devoxx 2009 over die onderwerpen. Erg interessant.
Erg kort door de bocht gezegd: ACID is niet altijd nodig, soms kun je met redelijk inconsistente data goed wegkomen. Let maar eens op de buddylist van Skype o.i.d. Die klopt op zijn best redelijk, maar vaak merk je toevallig dat iemand net weg gaat als je met 'm wilt chatten. Jaja. :-)
Iets anders om goed over na te denken is je caching strategie. Lees wat over memcached, bijvoorbeeld.
Maar goed, dat helpt je niet met je vraag. :)
Ik mis nog iets in de discussie: wat voor soort queries zijn het? Lezen? Schrijven? Allebei? Is de bottleneck van je machines? I/O? CPU? Ik kan queries bedenken waar je er echt gaan 7500 per seconde per machine van weg kunt zetten. :)
Kees Jan
Dit zijn allemaal selects (zoals ik eerder al aangaf, het gaat hier om de slaves).
Dat er minder queries doorheen kunnen snap ik wel als ik morgen memcache uitzet en haal de query en key cache overal af dan stort het boeltje als een plum pudding in elkaar.
@bhai:
Hoeveel queries doen jullie per seconden? (login in mysql en type "\s<enter>")
Het aantal queries zegt nix zolang je niet weet wat de queries doen. Ik kan met 1 query de beste server op zijn knieen krijgen en op een simpele pentium 10000 queries per seconden doen. Het hangt allemaal af van de database, de data en de queries, dus vooral van de kwaliteiten van de programmeur.
systemdeveloper
04/12/09, 02:58
Is idd niet veel over te zeggen. Als ik 'stiekum' een slave van een webtellertje kick, krijg ik op 4 minuten zoiets:
Uptime: 4 min 0 sec
Threads: 14 Questions: 2745748 Slow queries: 0 Opens: 30 Flush tables: 1 Open tables: 24 Queries per second avg: 11440.617
Maar het zou me niet verbazen als de helft simpele select count(*) from blabla is, maar als je een paar queries hebt die goed cacheble zijn, ram genoeg hebt en een proc op steroids kun je er nog wel meer uit slepen. (Als je de resultsets snel genoeg over de lijn gepompt krijgt tenminste). Met een paar ssd's in raid 0 (het is toch maar een slave) kun je ook nog wel wat leuks bereiken.
Ramon Fincken
04/12/09, 09:05
Precies, nu.nl zal ongetwijfeld caching van queries EN paginas gebruiken.
Wat ik wel zeker weet is dat ze een paar jaar geleden een reverse proxy hadden lopen.
Dat er minder queries doorheen kunnen snap ik wel als ik morgen memcache uitzet en haal de query en key cache overal af dan stort het boeltje als een plum pudding in elkaar.
Ja, dat heb ik me altijd af zitten vragen bij memcached: als ik om wat voor reden dan ook alle memcached instanties moet herstarten, krijg je het systeem dan wel weer gestart, of stort het bij elke herstart in? Stel je voor: power strip defect, alle memcached's uit. Na de herstarts zijn alle instanties leeg en moet alle data even uit de database komen.
Is het niet handiger om een cache te gebruiken die eventueel van disk gestart kan worden?
Kees Jan
@bhai:
Hoeveel queries doen jullie per seconden? (login in mysql en type "\s<enter>")
Sorry voor de iets te laten reactie:
FE#1: Queries per second avg: 159.177
FE#2: Queries per second avg: 159.216
FE#3: Queries per second avg: 177.483
FE#4: Queries per second avg: 177.385
Backend: Queries per second avg: 51.888
@Ramon, de reverse proxy [wodan] is vervangen door Varnish.
Tweakers.net draait anders ook op een major database server. Geen idee hoeveel queries per sec, maar dat zullen er heel wat zijn.
Tweakers.net draait anders ook op een major database server. Geen idee hoeveel queries per sec, maar dat zullen er heel wat zijn.
Er is ook heel veel gecached hoor =)
Zie hier hun stats: http://tweakers.net/stats/
serverstats: http://tweakers.net/stats/?Action=Serverstats
Ja, dat heb ik me altijd af zitten vragen bij memcached: als ik om wat voor reden dan ook alle memcached instanties moet herstarten, krijg je het systeem dan wel weer gestart, of stort het bij elke herstart in? Stel je voor: power strip defect, alle memcached's uit. Na de herstarts zijn alle instanties leeg en moet alle data even uit de database komen.
Is het niet handiger om een cache te gebruiken die eventueel van disk gestart kan worden?
Kees Jan
Goed gebruik maken van memcache forests ;)
Daardoor kan je memcache servers plat gooien zonder dat de boel in stort.
Als de gehele feed plat gaat, gaat de rest ook uit, dus dan kan het ook niet meer instorten :p
Sorry voor de iets te laten reactie:
FE#1: Queries per second avg: 159.177
FE#2: Queries per second avg: 159.216
FE#3: Queries per second avg: 177.483
FE#4: Queries per second avg: 177.385
Backend: Queries per second avg: 51.888
@Ramon, de reverse proxy [wodan] is vervangen door Varnish.
Jullie ook varnish :):)
Top pakket hé?
Wij hebben nu een clustertje draaien van 8 servers X 48GB geheugen die uit malloc serveren. Ik heb ook redelijk contact met Paul ;). Misschien kunnen we een beetje kennis uitwisselen hierover. Ik heb er namelijk redelijk wat tijd in varnish verdiept en neem aan jullie ook. Mogelijk levert het iets op. Neem hiervoor maar contact met mij op via pb, dan kunnen we mail adressen uitwisselen.
Dag QBell,
Memcache forests? Heb je meer info?
Kees Jan
Wij hebben een daemon geschreven die een tcp poortje open houd en requests ontvangt van mysql en php. Deze chunkt vervolgens de data (bij meer als 1MB) en schrijft dit redundant weg over verschillende memcache servers.
Hierdoor hebben we altijd 2 chunks staan ergens en mag er willekeurig 1 uitvallen zonder problemen.
De uiteindelijke latency is een paar ms hoger geworden door deze C applicatie die er tussen staat, maar het overall plaatje is er wel vele malen beter door geworden.
Hmmm. Interessant, want je lost twee problemen tegelijk op. Is de source code daarvan beschikbaar?
Kees Jan
Ik zal hier intern is overleggen of we de source code beschikbaar gaan stellen.
Ligt er een beetje aan hoeveel support tijd de programmeur hierin wil steken.
Support is niet nodig. We hebben hier genoeg C devs lopen. :)
Doorgeven aan jou alleen is nog geen open source ;)
Er is ook heel veel gecached hoor =)
Zie hier hun stats: http://tweakers.net/stats/
serverstats: http://tweakers.net/stats/?Action=Serverstats
Tweakers ligt er nu toevallig uit wegens een database storing.
Error
Wegens een databasestoring is de site momenteel niet beschikbaar.
Apache/2.2.12 (Debian) mod_ssl/2.2.12 OpenSSL/0.9.8k at tweakers.net (Astraeus)
Ik ken iemand die hardnekkig probeert meer dan 17000 qps te doen op een mysql-slave die enkel dat inserts/updates doet. Hij geraakt niet echt veel verder dan 17000 momenteel.
@frankske
het is wel mogelijk om meer te doen, maar niet met een simpele raid5 diskset.
Je kan kijken naar tablespace in mysql [5.1] met tablespace kun je tabellen op eigen disksets krijgen en hoe sneller je deze schijven krijgt [bijv met raid10 met 20 schijven of meer <- per tabel of index :)] des te meer queries per seconde je krijgt
Er is wel een groot probleem met deze setup, het gaat je belachelijk veel geld kosten.
Er zijn wedstrijden, combinatie van hardware/software, welke opzet de meeste transacties per minuut kan verwerken. Vorige maand kwam er een nieuwe nummer 1 met 7,646,486 transacties per seconde.
Helaas heb ik dit nog niet gezien voor MySQL [best jammer].
http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=109110401
Onderaan vind je 2 PDF's , de eerste is de factuur :) de 2e complete stappen plan van de setup en hoe en wat, maar er staat niet in waarom de developers gekozen hebben voor bepaalde indexes etc en waarom ze bepaalde queries zo hebben geschreven.
FransVanNispen
21/12/09, 01:20
Ik ken iemand die hardnekkig probeert meer dan 17000 qps te doen op een mysql-slave die enkel dat inserts/updates doet. Hij geraakt niet echt veel verder dan 17000 momenteel.
Is het niet zo dat een slave alleen read-only is?
Ik ben toevallig wat zaken aan het uitzoeken voor een klant die een MMORPG ontwikkelt. Er zijn hier een paar problemen die we bekijken om problemen met schaalbaarheid in de toekomst te voorkomen.
De spelers moeten kunnen inloggen en naar de juiste zone worden gestuurd. Vanwege IM moet er gecheckt kunnen worden of een speler online is en met regelmatige tussenposen moet de actuele speler positie en wat andere zaken in de speler database worden geplaatst.
De speler database moet ook nog eens de webservers voorzien van login data. Daarbij wil de klant een backup kunnen maken terwijl het systeem live blijft.
Dit gaan we uiteindelijk niet redden met een enkele database server :( Hoewel, met 17k queries per seconde en een interval van 10s kom je een eind :)
Misschien iemand ervaring met een dergelijke setup?
Dag Frank,
Ik denk dat je je moet afvragen of sessie informatie (login status, welke zone, etc) in de database moet staan. Dat is misschien handiger om in een vette memcached te zetten, ergens.
Ik denk ook dat je verschillende soorten data (spel data, IM data) kunt scheiden in verschillende systemen. Zo ben je uiteindelijk schaalbaarder, ten koste van meer te onderhouden systemen.
Live backup is simpel: mysql slave eraan en die dan periodiek backuppen.
Kees Jan
FransVanNispen
21/12/09, 16:14
Er komen meerdere database servers. Elke zone is als het ware self maintained. Alleen is er ltijd 1 punt waar alles samen komt.
In dit geval is dat de login server waar de gebruikers gegevens zijn opgeslagen. Waarschijnlijk is de vraag, hoe vaak moet de user status worden gupdate in de database om een goede indicatie te houden van waar een speler zich bevindt en of hij online is of niet.
Maar blijft natuurlijk mijn vraag staan: Is het bij master-slave niet zo, dat de slaves alleen lezen zijn en er alleen geschreven kan worden naar de master?
Maar blijft natuurlijk mijn vraag staan: Is het bij master-slave niet zo, dat de slaves alleen lezen zijn en er alleen geschreven kan worden naar de master?
Dat is juist, situatie waarin je op beide zou kunnen schrijven is master <-> master.
Dat is juist, situatie waarin je op beide zou kunnen schrijven is master <-> master.
Je bent er in ieder geval op tijd bij. Nu kun je makkelijk de read en write query's nog uit elkaar halen. Ik heb ooit een hele webshop verbouwd en hier ging achteraf nog eens 200 uur extra inzitten, tezamen met enkele optimalisaties en het implementeren van caching. Wanneer de groei vooraf berekend zou zijn, zou je aan 1/5 van die tijd voldoende hebben gehad.