[MySQL] Performance analyseren en optimaliseren * - Softwareontwikkeling

dinsdag 6 januari 2004 08:21

Acties:

Verwijderd

Topicstarter

Is er een manier om MySQL te monitoren?

Ik heb meerdere databases en sommige heb ik een paar jaar geleden gemaakt. Nu wil ik graag in de gaten houden of sommige van die db's niet teveel cpu kracht gebruiken waardoor de boel een beetje traag wordt.

Nu ben ik (na wat ondrzoek) ADOdb tegen gekomen en die heeft ook de The ADOdb Performance Monitoring Library.
De mogelijkheden die dit pakket aanbied is precies wat ik zoek, alleen moet ik dan alle scripts om gaan bouwen om te kunnen meten. En daar heb ik geen zin in (kost me een paar dagen).

Dit is voornamelijk belangrijk:
ADOdb also has the ability to log all SQL executed, using LogSQL. All SQL logged can be analyzed through the performance monitor UI. In the View SQL mode, we categorize the SQL into 3 types:

Suspicious SQL: queries with high average execution times, and are potential candidates for rewriting
Expensive SQL: queries with high total execution times (#executions * avg execution time). Optimizing these queries will reduce your database server load.
Invalid SQL: queries that generate errors.

Ik had gehoopt dat phpMyAdmin zoiets kan doen, maar dat kon ik niet vinden.

(Op moment van plaatsen vraag ik me af of die hier wel goed staat

)

[ Voor 5% gewijzigd door Verwijderd op 06-01-2004 08:23 ]

dinsdag 6 januari 2004 08:28

Acties:

whoami

Ik weet niet of er een pakket bestaat voor MySQL zoals SQL Server's Profiler en Query Analyzer.
Echter, een DB gebruikt geen CPU tijd, maar diskspace. Ik denk ook dat je bedoeld dat je wilt nagaan welke queries er traag werken en hoe je ze kan versnellen?
Je hebt een SQL statement waarmee je het execution plan van een query kunt bekijken. Adhv dat execution plan, kan je nagaan waar de bottleneck zit in een trage query, en op die manier kan je ook een beslissing nemen hoe je die query kunt versnellen (dmv een index op een bepaald veld te leggen, een bestaande index aan te passen, .....)

https://fgheysels.github.io/

dinsdag 6 januari 2004 08:36

Acties:

Verwijderd

Topicstarter

whoami schreef op 06 januari 2004 @ 08:28:
Ik denk ook dat je bedoeld dat je wilt nagaan welke queries er traag werken en hoe je ze kan versnellen?

idd

Je hebt een SQL statement waarmee je het execution plan van een query kunt bekijken.

Dan moet ik nog alle query's ombouwen en dat is me net iets teveel werk...

dinsdag 6 januari 2004 08:40

Acties:

whoami

Verwijderd schreef op 06 januari 2004 @ 08:36:
[...]

Dan moet ik nog alle query's ombouwen en dat is me net iets teveel werk...

Waarom moet je je queries ombouwen om een EXPLAIN PLAN te doen?
Trouwens, als je je queries wilt versnellen, zal je ze zowiezo moeten ombouwen.

https://fgheysels.github.io/

dinsdag 6 januari 2004 08:45

Acties:

Verwijderd

Topicstarter

whoami schreef op 06 januari 2004 @ 08:40:
Waarom moet je je queries ombouwen om een EXPLAIN PLAN te doen?

hmmzz... die staat niet in mijn boek

bedankt!
[qoute]
Trouwens, als je je queries wilt versnellen, zal je ze zowiezo moeten ombouwen.[/quote]
Ja, maar het is wel fijn als je weet welke er omgebouwd moet worden.

dinsdag 6 januari 2004 09:16

Acties:

Verwijderd

Topicstarter

EXPLAIN PLAN is toch niet wat ik zoek.

Ik zoek iets wat bijhoud welke query's er uitgevoerd zijn (door PHP scripts) en hoe belastend ze zijn.
En het liefst moet het werken met meerdere databases.

dinsdag 6 januari 2004 09:25

Acties:

curry684

left part of the evil twins

whoami schreef op 06 januari 2004 @ 08:28:
Ik weet niet of er een pakket bestaat voor MySQL zoals SQL Server's Profiler en Query Analyzer.

Dat zijn juist de tools die van SQL Server een enterprise DBMS maken van meerdere duizenden euro's per serverlicense, dus ik denk niet dat het voor een (nofi) hobbydatabase echt te vinden is

Echter, een DB gebruikt geen CPU tijd, maar diskspace. Ik denk ook dat je bedoeld dat je wilt nagaan welke queries er traag werken en hoe je ze kan versnellen?

Een DB gebruikt wel degelijk ook CPU tijd hoor

Erger nog, als je op een flinke RAID-array met diverse gigabytes aan geheugen zit kan CPU-power zelfs nog wel eens de bottleneck gaan vormen. Admittedly zit de bottleneck over het algemeen op andere plekken, maar grappen als 'order by' of 'group by' op tables van 1 miljoen elementen doen gewoon CPU-wise enorm pijn.

Zie ook [rml]curry684 in "[ postcount] techposts"[/rml], chem heeft me naderhand op IRC nog even toegelicht dat dat dus puur een kwestie is van het feit dat ie op de topictable van GoT (850000 entries) een group by moet doen richting het subforum, en dat is wat de query dus 30-60 seconden laat duren bij oude/hyperactieve users.

Je hebt een SQL statement waarmee je het execution plan van een query kunt bekijken. Adhv dat execution plan, kan je nagaan waar de bottleneck zit in een trage query, en op die manier kan je ook een beslissing nemen hoe je die query kunt versnellen (dmv een index op een bepaald veld te leggen, een bestaande index aan te passen, .....)

Je kunt ook individuele queries enorm optimizen. Sommige join-constructies worden tot dubbel zo snel met een slimme subselect in SQL Server, om maar een zwaar voorbeeld te noemen. Helaas kent MySQL geen correlated subqueries (of uberhaupt subqueries afaik) dus dat schiet niet echt op

Professionele website nodig?

dinsdag 6 januari 2004 09:28

Acties:

whoami

curry684 schreef op 06 januari 2004 @ 09:25:
[...]

Dat zijn juist de tools die van SQL Server een enterprise DBMS maken van meerdere duizenden euro's per serverlicense, dus ik denk niet dat het voor een (nofi) hobbydatabase echt te vinden is

Alleszins niet gratis nee, dat denk ik ook.

Een DB gebruikt wel degelijk ook CPU tijd hoor Erger nog, als je op een flinke RAID-array met diverse gigabytes aan geheugen zit kan CPU-power zelfs nog wel eens de bottleneck gaan vormen. Admittedly zit de bottleneck over het algemeen op andere plekken, maar grappen als 'order by' of 'group by' op tables van 1 miljoen elementen doen gewoon CPU-wise enorm pijn.

Ja, idd, je hebt wel gelijk. My bad, ik had idd moeten zeggen dat de bottleneck meestal bij disk IO ligt.

https://fgheysels.github.io/

dinsdag 6 januari 2004 09:28

Acties:

ripexx

bibs

Waarom schrjf je niet een eigen functie, die de resultaten logt naar een db of text file. Ipv mysql_query(); gebruik je je eigen functie die uit eindelijk ook de query tijd berekend.

Zodra je weet welke queries langzaam zijn kan je voor je query EXPLAIN zetten en dan gaan kjken hoe de verschillende indexen worden gebruikt.

Pas daarnaast op dat mysql voor bijvoorbeedl ORDER BY .. DESC al gebruik maakt van een file sort. Verder staan er in het manual ook meerdere optimalistaie tuckjes.

buit is binnen sukkel

dinsdag 6 januari 2004 09:58

Acties:

Verwijderd

Topicstarter

Het punt is, wij hebben een dedicated server en deze draait op zich goed alleen wordt die af en toe supertraag.
Nou was eerst onze verbinding traag (ISDN) en was dit niet echt een probleem, maar nu we een 2Mbit verbinding hebben beginnen die terugvallen vervelend te worden.

Op de server staan meerdere websites en meerdere MySQL db's.
Het niet is best een oude server, maar zou nog goed moeten draaien.
Het is een LINUX 400mhz CPU, 512MB geheugen met Apache, PHP 4.1 en MySQL 3.23.

Degene die de server beheert zegt dat alles goed gaat en kan de pieken zien. De CPU is dan wel zwaar belast, maar nog niet zo erg dat alles vertraagd. Ook is de bandbreedte geen probleem. Dus denken wij dat het probleem veroorzaakt wordt door scripts en vooral door script die verbinding maken met mysql.

Daarom wil ik graag weten welk script (of iig welke query) bezig is met MySQL en hoeveel MySQL er door belast wordt.
Lijkt me sowieso wel handig en leuk om te kunnen meten

dinsdag 6 januari 2004 10:00

Acties:

Verwijderd

Topicstarter

ripexx schreef op 06 januari 2004 @ 09:28:
Waarom schrjf je niet een eigen functie, die de resultaten logt naar een db of text file. Ipv mysql_query(); gebruik je je eigen functie die uit eindelijk ook de query tijd berekend.

Dan moet ik nog alle scripts aanpassen en dat zijn er veel

dinsdag 6 januari 2004 10:04

Acties:

curry684

left part of the evil twins

Verwijderd schreef op 06 januari 2004 @ 10:00:
[...]

Dan moet ik nog alle scripts aanpassen en dat zijn er veel

Jammer maar helaas, maar het is toch om meerdere redenen de aanpak die ik zou adviseren. Niet alleen heb je er plots de vrijheid mee om alles om de query uit te voeren wat je wilt, maar je genereert er ook database-independence mee omdat je dan ineens redelijk simpel kunt switchen naar bijv. Oracle of MSSQL.

Kijk eens voor de lol naar de sources van phpBB, die hebben dat best netjes geimplementeerd.

Professionele website nodig?

dinsdag 6 januari 2004 10:20

Acties:

ripexx

bibs

Heel kort is dit mijn mysql functie

PHP:

function do_query($sql)
{
    $startTime = microtime();
    $result = mysql_query($sql)or die ("<b>MySQL Error</b>
<br> MySQL error: ".Mysql_error()."<br>SQL Query: ".$sql);
    $endTime = microtime(); 
    $tijd = microtime_diff($startTime, $endTime); 
    query_count($tijd); // Tel aantal queries enz.
    return $result;
};

Je kan dan zelf nog een functie maken die iets je logging doet. Je krijgt dan iets in de vorm van log_query($sql, $tijd);

Waarin je het opslaat is niet zo zeer van belang, maar dat je iig kan achter halen welke queries de zaak lopen te verstieren. Verder kan je waarschijnlijk aan je stats ook zie welke pagina's veel vuldig worden bekeken. Bijkijk die queries als eerste, daarna pas de rest. Verder lees het manual van mysql er op na, de stukken over optimalisatie geven je een behoorlijkbeeld van wat je kan verbeteren en wat je maar beter weg kan laten.

buit is binnen sukkel

dinsdag 6 januari 2004 10:21

Acties:

Verwijderd

okay... zelfde idee als vorige post...

Kan je niet een funktie schrijven die qua parameters en return values precies hetzelfde doet als 'mysql_query'... en dat gewoon een search&replace doen binnen je pagina's...

bv (in pseudo code):

code:

my_mysql_query(param) 
{
starttimer
mysql_query(param)
stoptimer
dump query naar log
dump elapsed time naar log
}

[ Voor 10% gewijzigd door Verwijderd op 06-01-2004 10:22 ]

dinsdag 6 januari 2004 10:24

Acties:

chem

Reist de wereld rond

Waarom gebruik je niet gewoon het slowquery log met bv een slow-query-treshhold van een 2-3 seconden?

Klaar voor een nieuwe uitdaging.

dinsdag 6 januari 2004 10:29

Acties:

ripexx

bibs

chem schreef op 06 januari 2004 @ 10:24:
Waarom gebruik je niet gewoon het slowquery log met bv een slow-query-treshhold van een 2-3 seconden?

Nadeel is dat je dan wel DBA moet zijn, en niet elke hoster wil hieraan beginnen. Het is wel een optie die verreweg het meeste makkelijk is en voor weinig problemen zorgt.

@Chem, ik neem toch aan dat jij voor react toch ook gewoon een eigen sql/query handler hebt geschreven die dit soort info kan loggen etc?

buit is binnen sukkel

dinsdag 6 januari 2004 10:50

Acties:

chem

Reist de wereld rond

Jah, kijk maar onderaan elke pagina; "DB: 0.04/26" bijvoorbeeld; 0.04 seconde voor 26 queries.

Klaar voor een nieuwe uitdaging.

dinsdag 6 januari 2004 11:02

Acties:

Verwijderd

Topicstarter

Als ik alle scripts ga aanpassen dan kan ik net zo goed ADOdb gebruiken.
Is alles al netjes in verwerkt

Maar dat slowquery log verhaal ga ik wel ff vragen. Dat moet niet zo'n probleem zijn.

Bedankt!!!

Pagina: 1

Reageer