Likes: 0
06/01/05 12:23
Correct me if i'm wrong, maar MySQL maakt toch voornamelijk gebruik van RAM en niet van de CPU?
ik heb namelijk een vrij hoge load voor de CPU door mysqld-nt.exe
Gisteren geheugen erbij geplaatst, maar nog steeds een beetje traag tijdens de drukkere uren...
Ik dacht dat mysql vooral geheugen gebruikte...
06/01/05 12:44
Licht eraan hoie je programmeerd.Heb je nette SQL syntax en Query's is je load laag. Ben je wat slechter in programeren en doe je graag veel ingewikkelde SQL Query's dan stijgt de load aanzienlijk.Origineel geplaatst door Nitroserve
Correct me if i'm wrong, maar MySQL maakt toch voornamelijk gebruik van RAM en niet van de CPU?
ik heb namelijk een vrij hoge load voor de CPU door mysqld-nt.exe
Gisteren geheugen erbij geplaatst, maar nog steeds een beetje traag tijdens de drukkere uren...
Ik dacht dat mysql vooral geheugen gebruikte...
Maar waarom heb je niet alvorens je Geheugen erbij prikte bekeken wat het geheugengebruik van SQL was? Je kunt dan ook tevens bekijken hoe het met de load is gesteld en welke Query's eventueel veel tijd nodig hebben om te processen.
06/01/05 13:25
Staat je query cache aan? Als je net meer ram hebt bijgestoken kan je het query cache verhogen/aanzetten, waardoor er msischien minder CPU gebruik is.Origineel geplaatst door Nitroserve
Correct me if i'm wrong, maar MySQL maakt toch voornamelijk gebruik van RAM en niet van de CPU?
ik heb namelijk een vrij hoge load voor de CPU door mysqld-nt.exe
Gisteren geheugen erbij geplaatst, maar nog steeds een beetje traag tijdens de drukkere uren...
Ik dacht dat mysql vooral geheugen gebruikte...
06/01/05 13:30
het gaat om een druik bezochte site van een klant, heb hier dus geen invloed op....Origineel geplaatst door Deimos
Licht eraan hoie je programmeerd.Heb je nette SQL syntax en Query's is je load laag. Ben je wat slechter in programeren en doe je graag veel ingewikkelde SQL Query's dan stijgt de load aanzienlijk.
Maar waarom heb je niet alvorens je Geheugen erbij prikte bekeken wat het geheugengebruik van SQL was? Je kunt dan ook tevens bekijken hoe het met de load is gesteld en welke Query's eventueel veel tijd nodig hebben om te processen.
wat doet dit precies???
Staat je query cache aan? Als je net meer ram hebt bijgestoken kan je het query cache verhogen/aanzetten, waardoor er msischien minder CPU gebruik is.
en waar kan ik deze optie vinden? (win2k3)
06/01/05 13:33
Database optimalisatie kan ook helpen (kun je ook gewoon via phpMyAdmin doen).
06/01/05 13:34
In de configuratie file. Gebruik de search eens op het forum of zie in de documentatie op http://dev.mysql.comOrigineel geplaatst door Nitroserve
het gaat om een druik bezochte site van een klant, heb hier dus geen invloed op....
wat doet dit precies???
en waar kan ik deze optie vinden? (win2k3)
06/01/05 13:53
OK, bedankt voor de info, ik ga even kijken of het me kan helpen...
06/01/05 15:01
Beetje negatieve reactie zonder goede beredenering. Als het om een productieserver gaat met daarop veel verschillende klanten dan heb je ten eerste weinig invloed op de opbouw van de querys, maar ook nog eens op de aantallen querys en dus zal je load dan zoiezo stijgen.Origineel geplaatst door Deimos
Licht eraan hoie je programmeerd.Heb je nette SQL syntax en Query's is je load laag. Ben je wat slechter in programeren en doe je graag veel ingewikkelde SQL Query's dan stijgt de load aanzienlijk.
Maar waarom heb je niet alvorens je Geheugen erbij prikte bekeken wat het geheugengebruik van SQL was? Je kunt dan ook tevens bekijken hoe het met de load is gesteld en welke Query's eventueel veel tijd nodig hebben om te processen.
Daarnaast zijn moeilijke query's soms onontkoombaar en dat heeft dan helemaal NIKS met slecht programmeren te maken
06/01/05 15:12
Was wellicht een beetje met een rot ondertoon. Maar wat er staat is wel waar. Zelf heb ik al menig klant moeten helpen met PHPén en SQL omdat de klant anders de hele server in een sleur trok en dat kan ik natuurlijk niet verantwoorden tegenover andere klanten.Origineel geplaatst door WE-Create!
Beetje negatieve reactie zonder goede beredenering. Als het om een productieserver gaat met daarop veel verschillende klanten dan heb je ten eerste weinig invloed op de opbouw van de querys, maar ook nog eens op de aantallen querys en dus zal je load dan zoiezo stijgen.
Daarnaast zijn moeilijke query's soms onontkoombaar en dat heeft dan helemaal NIKS met slecht programmeren te maken
Maargoed, mijn punt is denk ik redelijk duidelijk.
06/01/05 16:24
OK, ik ga eens kijken of dit hier ook een probleem is, ik heb bijgaand even een screenshotje van de load gezet.
Dit is niet echt normaal lijkt mij...
06/01/05 16:54
Start anders eens met loggen van je trage SQL processen. Dan zie je zo welke query's enorm veel tijd kosten. En dan kan je de eigenaar van die DB erop aanspreken.
06/01/05 21:42
CPU percentage zegt weinig.
Die hoort 100% te zijn op het moment dat hij bezig met een query is, en niks van schijf nodig heeft.
Kijk eens hoeveel CPU time ("view" "select columns") hij over langere tijd gebruikt.
06/01/05 21:49
Kijk eens naar het volgende plaatje....
Ik denk trouwens dat ik weet waar de lange wachttijden vandaan komen.
Dit is voornamelijk uit het "gastenboek"
Deze tabel kent 252711 rijen en is 31MB groot!!!
Hier een stukje uit mijn slow_query_log:
-----------------------------
# Query_time: 6 Lock_time: 0 Rows_sent: 8 Rows_examined: 238142
SELECT * FROM gastenboek WHERE eigenaar='591' ORDER BY id DESC LIMIT 0,8;
-----------------------------
hij zoekt vreslijk lang naar (in dit geval) eigenaar 591 denk ik...
Is dit te optimaliseren?
06/01/05 21:56
Start eens met een indice op de kolom "eigenaar" en als dat niet helpt kan je ook nog op "id" doen (in de tabel "gastenboek"). Alleen zal die 2e veel minder effect hebben.Origineel geplaatst door Nitroserve
Kijk eens naar het volgende plaatje....
Ik denk trouwens dat ik weet waar de lange wachttijden vandaan komen.
Dit is voornamelijk uit het "gastenboek"
Deze tabel kent 252711 rijen en is 31MB groot!!!
Hier een stukje uit mijn slow_query_log:
-----------------------------
# Query_time: 6 Lock_time: 0 Rows_sent: 8 Rows_examined: 238142
SELECT * FROM gastenboek WHERE eigenaar='591' ORDER BY id DESC LIMIT 0,8;
-----------------------------
hij zoekt vreslijk lang naar (in dit geval) eigenaar 591 denk ik...
Is dit te optimaliseren?
06/01/05 21:56
SELECT * FROM gastenboek WHERE eigenaar='591' ORDER BY id DESC LIMIT 0,8;
Alle kolommen echt nodig? Anders alleen de kolommen die nodig zijn in je query opnemen.
Index op eigenaar?
Is de kolom eigenaar wel van INT en niet bijvoorbeeld VARCHAR?
Die id hoort niet tussen quotes.
