Onderwerp: 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)

Oorspronkelijk geplaatst door QBell

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.

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.

Oorspronkelijk geplaatst door QBell

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).

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.

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.