[sql] Groot aantal queries op statuspagina mysql

[radem205]

Hey,

Wanneer ik in phpmyAdmin op de statuspagina het totaal aantal queries wil bekijken schrik ik elke keer weer .

Elke keer dat ik de pagina opnieuw inlaadt (elke seconden) komen er wel 100 queries bij op het totale aantal queries. Dit terwijl er geen bezoekers zijn op de website, dus de website is hier niet de schuldige van (lijkt mij).

Is het normaal dat sinds gisteravond al zo'n 160.000 queries zijn uitgevoerd, zonder dat er veel gebruikers online waren?

Ook maak ik goed gebruik van indexes (tevens gecontroleerd met EXPLAIN etc..), maar op de statuspagina staat de:

Handler_read_rnd_next momenteel op 108M.

Het lijkt er wel op dat er veel andere queries worden gedraaid om een duistere reden.

Weet iemand waar dit door zal kunnen komen?

Edit: Ik maak overigens gebruik van PDO

[Verwijderd]

Shared hosting?

[ Voor 96% gewijzigd door MueR op 06-10-2010 12:43 . Reden: Die hele quote is niet nodig ]

[MueR]

Heb je ook enig idee hoe die queries die draaien er ongeveer uit zien? Nu is het een beetje lastig om iets nuttigs te zeggen

[NMe]

Hoe zie je dat er geen bezoekers op je site waren? Hoe en waarmee meet je dat? Hoeveel bezoekers heb je precies gehad en hoeveel views hebben die gegenereerd in de tijd dat je die 160k query's hebt gehad? Hoeveel query's per pageview heb je gemiddeld? Heb je niet iets van een cronjob draaien die de oorzaak kan zijn? Kortom: vertel eens wat meer over je situatie, gokken heeft geen enkele zin.

[radem205]

Excuus voor de onduidelijkheid. Het gaat om een VDS, dus geen shared hosting. Zoals gezegd maak ik gebruik van PDO om de query's uit te voeren. Ik heb een functie gemaakt (extenden van PDO class) om het aantal uitgevoerde queries te berekenen op de verschillende pagina's.

Het aantal queries per pagina varieert van 5 tot 10 queries.

Alle bezoekers worden geregistreerd (middels ipadres), waarna ik op de online pagina het aantal bezoekers kan zien (ook kan ik de inactiviteit zien van de leden), dus wanneer leden geen pagina inladen dan worden er nog veel queries uitgevoerd in de database.

De views kan ik zo 1,2,3 niet achterhalen. Maar stel als er 5 bezoekers online zien die in een seconde 3 pagina's bekijken (wat al erg veel is), dan genereren deze dus 3 x 7 x 5 queries. 100 queries in een seconde.

Wat mij ook zorgen baart is de Handler_read_rnd_next die momenteel op 207 M staat. Terwijl ik zeer veel queries door de EXPLAIN heb gehaald en allen gebruiken ze een key of een table scan (in dit geval betreft alleen hele kleine tabellen).

Ook de slow queries staat momenteel op 736 (sinds gisteravond), terwijl er geen queries in de slow-query log komen te staan.

Edit: En hoe de query eruit ziet maakt niet zo veel uit toch? Want 1 query is 1 query toch? Of worden de joins apart mee gerekend?

[ Voor 10% gewijzigd door radem205 op 06-10-2010 13:46 ]

[MueR]

Als je weet hoe de queries er uit zien kan je ze gaan traceren in je systeem natuurlijk

Maar loop je niet tegen table locks aan oid?

[NMe]

Klinkt als een gevalletje Googlebot of andere spider. Die heeft geen account, dus je ziet hem ook niet op je "online bezoekers"-lijst. Registreer eens al je pageviews, dan kun je veel sneller zien of iets als dan niet terecht query's oplevert. Ik vermoed in elk geval dat er niks aan de hand is.

[radem205]

Het is al meerder dagen aan de gang he (dus het kan wel een spider zijn, maar het lijkt mij sterk). En ik heb ook nog geen instellingen aangebracht in my.cnf (aangezien deze gemanaged wordt door de hoster).

De Created_tmp_disk_tables wordt ook vrij hoog, dus dat is een teken dat ik de table_cache moet veranderen.

Edit: En ik gebruik myISAM, waardoor het wel kan zijn dat ik tegen table_locks aanloop.

Edit 2: Table_locks_waited staat op 0 dus dat lijkt mij niet het geval

[ Voor 24% gewijzigd door radem205 op 06-10-2010 14:10 ]

[NMe]

radem205 schreef op woensdag 06 oktober 2010 @ 14:04:
Het is al meerder dagen aan de gang he (dus het kan wel een spider zijn, maar het lijkt mij sterk).

Meten is weten. Zeggen dat het je sterk lijkt helpt je niet. Meet het en sluit het uit of bevestig het. Sowieso hoeft het niet één spider te zijn, Google is niet de enige speler. En niet elke spider is zo netjes om tijd tussen de requests te laten zitten.

radem205 schreef op woensdag 06 oktober 2010 @ 14:04:
De Created_tmp_disk_tables wordt ook vrij hoog, dus dat is een teken dat ik de table_cache moet veranderen.

...of je moet je query's verbeteren danwel je indexen beter leggen zodat de temp tables in het geheugen kunnen draaien in plaats van op het filesystem of zodat temp tables zelfs helemaal niet meer nodig zijn.

[ Voor 31% gewijzigd door NMe op 06-10-2010 14:16 ]

[radem205]

Een spider geeft toch wel een ipadres door tijdens het bezoek? Want deze worden dan wel geregistreerd en komen ook in de lijst met bezoekers (waarvan het aantal dus niet hoog is).

En zoals eerder gezegd wordt er goed gebruik gemaakt van indexes, ik kan daar niet al te veel meer aan verbeteren.

[NMe]

radem205 schreef op woensdag 06 oktober 2010 @ 14:26:
Een spider geeft toch wel een ipadres door tijdens het bezoek? Want deze worden dan wel geregistreerd en komen ook in de lijst met bezoekers (waarvan het aantal dus niet hoog is).

En zoals eerder gezegd wordt er goed gebruik gemaakt van indexes, ik kan daar niet al te veel meer aan verbeteren.

Een spider met één IP-adres dat 10.000 keer je site opvraagt staat één keer als bezoeker in je lijst...

[RobIII]

radem205 schreef op woensdag 06 oktober 2010 @ 14:26:
Een spider geeft toch wel een ipadres door tijdens het bezoek?

offtopic:
Spiders, noch browsers noch andere clients, "geven het ip adres door". Het IP adres wordt gewoon uit de IP stack meegenomen naar de webserver. Al zou je het dus willen, je kunt niet "IP loos" gelogged worden. _{Je kunt 't spoofen maar da's een ander verhaal....}

NMe schreef op woensdag 06 oktober 2010 @ 14:45:
[...]

Een spider met één IP-adres dat 10.000 keer je site opvraagt staat één keer als bezoeker in je lijst...

Een spider die een indexactie aan 't doen is kan echter wél van een shitload aan IP's vandaan komen en dus als 'losse bezoekers' verschijnen als je je data enkel op IP beschouwt. Google doet dat, AFAIK, niet in een enkele 'ronde' over je site, maar het is wél mogelijk dat dit gebeurt.

[ Voor 34% gewijzigd door RobIII op 06-10-2010 15:02 ]

[kluyze]

Heb je al eens met "show processlist" bekeken welke queries er dan ook uitgevoerd worden?

Ik draai niets op mijn server en alle keren dat ik de pagina op phpmyadmin met statistieken herlaad komen er ~19 queries bij. Denk er dus ook aan dat phpMyAdmin een hoop queries stuurt. Ik heb ook ooit eens handmatig statistieken bij gehouden en daarin kwam naar boven dat elke connect een 3-4tal queries was volgens de MySQL statistieken. En dat was een connect via de commandline wie weet hoeveel pdo nodig heeft.

[GlowMouse]

Je kunt MySQL alle queries laten loggen, dan weet je het gelijk

[radem205]

GlowMouse schreef op dinsdag 12 oktober 2010 @ 12:46:
Je kunt MySQL alle queries laten loggen, dan weet je het gelijk

Ok, thanks!

Nog even een vraag:

Hoe kan het dat onderstaande query geen indexes gebruikt (index op vriend_in, vriend_uit en actief)? (ik weet dat het komt door de OR condition)

EXPLAIN SELECT id FROM vrienden WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1

Op http://dev.mysql.com/doc/...x-merge-optimization.html zag ik dat dit wel eens het probleem kan zijn, echter beschik ik over mySQL 5.1 maar nog werkt het niet.

[GlowMouse]

Doe eens

SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief

en kijk dan of je snel alle rijen kunt vinden die voldoen aan WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1. Dat zal niet lukken. Dat lukt wel bij het resultaat uit deze twee queries:

SELECT actief,vriend_in FROM vrienden ORDER BY actief,vriend_in
SELECT actief,vriend_uit FROM vrienden ORDER BY actief,vriend_uit

Het filteren van dubbelen is dan wel weer even werk. Je hebt dus minimaal twee indexen nodig wil je deze query volledig met indices uitvoeren.

[Creepy]

EN uiteraard is het ook nog afhankelijk van de inhoud van de tabellen. Als er maar 10 records in staan kan MySQL prima vinden dat een table scan sneller is.

[radem205]

GlowMouse schreef op dinsdag 12 oktober 2010 @ 15:53:
Doe eens

SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief

en kijk dan of je snel alle rijen kunt vinden die voldoen aan WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1. Dat zal niet lukken. Dat lukt wel bij het resultaat uit deze twee queries:

SELECT actief,vriend_in FROM vrienden ORDER BY actief,vriend_in
SELECT actief,vriend_uit FROM vrienden ORDER BY actief,vriend_uit

Het filteren van dubbelen is dan wel weer even werk. Je hebt dus minimaal twee indexen nodig wil je deze query volledig met indices uitvoeren.

Ik heb nu even wat geexperimenteerd met indexes, wanneer ik onderstaande indexes plaats dan gebruik hij de "actief,afgekeurd" index wat in mijn ogen inefficiënt is, want dan worden nog steeds 2800 rijen doorlopen:

index 1: vriend_in
index 2: vriend_uit
index 3: actief,afgekeurd

Nu doe ik het waarschijnlijk nog steeds fout, want ik weet niet precies hoe mysql met OR conditions te werk gaat (schijnbaar anders dan verwacht).

Of doe ik het zo wel correct en kan hij alleen de "actief, afgekeurd" index gebruiken?

Creepy schreef op dinsdag 12 oktober 2010 @ 15:58:
EN uiteraard is het ook nog afhankelijk van de inhoud van de tabellen. Als er maar 10 records in staan kan MySQL prima vinden dat een table scan sneller is.

Ja inderdaad, maar het zijn nu (binnen een week) al 2800 records, dus de kans dat dit heel erg gaat oplopen is erg groot.

[ Voor 14% gewijzigd door radem205 op 12-10-2010 16:04 ]

[GlowMouse]

radem205 schreef op dinsdag 12 oktober 2010 @ 16:00:
[...]


Ik heb nu even wat geexperimenteerd met indexes, wanneer ik onderstaande indexes plaats dan gebruik hij de "actief,afgekeurd" index wat in mijn ogen inefficiënt is, want dan worden nog steeds 2800 rijen doorlopen:

Je moet niet experimenteren, je moet logisch nadenken. Indexen werken als gesorteerde lijsten. Kun jij uit een lijst gesorteerd op vriend_in snel de rijen halen die voldoen aan (vriend_in = 6 OR vriend_uit = 6) AND actief = 1? Zonee, dan helpt een index op vriend_in niet.
Uit een lijst gesorteerd op actief kun je snel de rijen halen met actief=1, maar als dat bijna alle rijen zijn dan heeft dat niet zoveel zin.

[radem205]

GlowMouse schreef op woensdag 13 oktober 2010 @ 11:03:
[...]

Je moet niet experimenteren, je moet logisch nadenken. Indexen werken als gesorteerde lijsten. Kun jij uit een lijst gesorteerd op vriend_in snel de rijen halen die voldoen aan (vriend_in = 6 OR vriend_uit = 6) AND actief = 1? Zonee, dan helpt een index op vriend_in niet.
Uit een lijst gesorteerd op actief kun je snel de rijen halen met actief=1, maar als dat bijna alle rijen zijn dan heeft dat niet zoveel zin.

Ik snap dat je beter logisch kan nadenken, maar in het leven is logisch nadenken soms erg moeilijk. En wat jij zegt had ik ook al wel bedacht, maar als ik logisch nadenk dan moet een index op "vriend_in, vriend_uit en actief" wel kunnen (want dan kan hij sorteren op vriend_in of vriend_uit en actief). Maar dit werkt dus niet (dit heb ik aanvankelijk al ingesteld).

Dus ik hoop dat je begrijpt dat ik nu niet helemaal weet welke indexen het beste zijn voor mijn query. Kan je mij een eindje op weg helpen?

[GlowMouse]

radem205 schreef op woensdag 13 oktober 2010 @ 16:45:
[...]


Ik snap dat je beter logisch kan nadenken, maar in het leven is logisch nadenken soms erg moeilijk. En wat jij zegt had ik ook al wel bedacht, maar als ik logisch nadenk dan moet een index op "vriend_in, vriend_uit en actief" wel kunnen (want dan kan hij sorteren op vriend_in of vriend_uit en actief). Maar dit werkt dus niet (dit heb ik aanvankelijk al ingesteld).

Dus ik hoop dat je begrijpt dat ik nu niet helemaal weet welke indexen het beste zijn voor mijn query. Kan je mij een eindje op weg helpen?

Met die index kan hij helemaal niet sorteren op vriend_uit of actief. Stel je de index voor als het resultaat van
SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief


Puur deze query:
SELECT id FROM vrienden WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1
kun je volledig met indexen uitvoeren. Over je tabellay-out zullen we het niet hebben, en komt er een ORDER BY bij, dan kun je het vergeten. Index op (actief,vriend_in) en op (actief,vriend_uit) en dan deze query:
SELECT id FROM vrienden WHERE vriend_in = 6 AND actief = 1
UNION
SELECT id FROM vrienden WHERE vriend_uit = 6 AND actief = 1

[radem205]

GlowMouse schreef op woensdag 13 oktober 2010 @ 17:16:
[...]

Met die index kan hij helemaal niet sorteren op vriend_uit of actief. Stel je de index voor als het resultaat van
SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief


Puur deze query:
SELECT id FROM vrienden WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1
kun je volledig met indexen uitvoeren. Over je tabellay-out zullen we het niet hebben, en komt er een ORDER BY bij, dan kun je het vergeten. Index op (actief,vriend_in) en op (actief,vriend_uit) en dan deze query:
SELECT id FROM vrienden WHERE vriend_in = 6 AND actief = 1
UNION
SELECT id FROM vrienden WHERE vriend_uit = 6 AND actief = 1

Bedankt, dat werkt top! En de tabellay kan beter inderdaad (wellicht per vriendschap 2 rijen), maar met een groot aantal vriendschappen wordt het aantal rijen hiermee verdubbeld (misschien bij nader inzien was dit niet zo'n probleem geweest).

[GlowMouse]

radem205 schreef op woensdag 13 oktober 2010 @ 17:25:
[...]


Bedankt, dat werkt top! En de tabellay kan beter inderdaad (wellicht per vriendschap 2 rijen), maar met een groot aantal vriendschappen wordt het aantal rijen hiermee verdubbeld (misschien bij nader inzien was dit niet zo'n probleem geweest).

Als het om vriendschappen gaat, zou ik het aantal rijen zeker verdubbelen. Hoewel je een index minder hebt zal het toch meer ruimte kosten en updates zijn iets trager, je krijgt er flexibiliteit voor terug (de mogelijkheid tot sorteren via een index bijvoorbeeld).