Overbelastet MySQL server

Det kan vi ikke sige noget om på det foreliggende grundlag.

Er det MySQL eller PHP der bruger kraften ?

Er det CPU memory eller disk IO der er flaskehalsen ?

Hvad er typiske queries ?

(flere spørgsmål når disse er besvaret)

>Er det MySQL eller PHP der bruger kraften ?

Der er kun db'en på den server, som er overbelastet.

>Er det CPU memory eller disk IO der er flaskehalsen ?

Der skulle efter sigende være næsten et konstant 100% CPU load.

>Hvad er typiske queries ?

Der er rigtig mange SELECT queries.

Komplekse joins mellem mange tabeller ?

Sortering (ORDER BY)) af mange records ?

Stor brug af MySQL funktioner (LOG POW og den slags) ?

Generelt set kunne man gøre noget i at optimere de forskellige queries og updates der er. Hvis der f.eks. er nogle hæftige joins, kunne man prøve at opdele dem i flere statements.

Dette er ikke en normal fremgangsmåde, men MySQL har tendens til at være rigtig hurtig til små ting, men modsat langsom til komplicerede ting. I så fald skal der overføres lidt arbejde til PHP'en. Om det i sidste ende kan betale sig, må man prøve sig frem til.

>Komplekse joins mellem mange tabeller ?

Det maksimale join er mellem 2 tabeller. I hver tabel er der en primary key bestående af en attribut.

>Sortering (ORDER BY)) af mange records ?

Det er der. Der laves en sortering, for at vise en række poster sorteret efter tid.

>Stor brug af MySQL funktioner (LOG POW og den slags) ?

Nej.

Til dsj:

>Generelt set kunne man gøre noget i at optimere de forskellige queries og updates der er. Hvis der f.eks. er nogle hæftige joins, kunne man prøve at opdele dem i flere statements.

Kan du give et eksempel?

Du kunne evt. prøve at undlade den ORDER BY og se om det hjælper
på CPU forbruget.

Ikke sandsyneligt, men det er måden. Man prøver forskellige ting
og ser om det hjælper.

Der bliver lavet en del søgningen og dermed anvendt en del queries med LIKE.

Man kunne også sætte caching op.

join_buffer_size
key_buffer_size
query_cache_size

disse parametre in din my.cnf eller my.ini vil gøre dig i stand til at speede din server meget op forudsat at den har memory nok.

>Du kunne evt. prøve at undlade den ORDER BY og se om det hjælper på CPU forbruget.

Jeg har desværre ikke adgang til serveren, men jeg vil prøve at få servermanden til at se, om der er en forskel.

uden den store viden om mysql vil jeg forslå du kigger på "Index"  men det er ikke altid en fordel .. se på det her
http://www.mysql.com/doc/en/MySQL_indexes.html

Caching kan give meget stor performance fremgang, især hvis det ofte er de samme index som er i brug.

Det er jo trods alt billigere at købe en ½ Gib ram og dedikere den til caching end at købe en ny server.

Nogen som har erfaring med OPTIMIZE TABLE i SQL ?

http://www.mysql.com/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#OPTIMIZE_TABLE

Optimize table er bare en restrukturering af data så index mv. bliver optimeret. Det er især godt at gøre hvis der er mange sletninger i tabellen, men hvis man kun tilføjer så er det lige gyldigt

mht caching så kig her på de forskellige godt parametre man kan stille på:

http://www.mysql.com/doc/en/Server_parameters.html

Fornuftig brug af index er kritisk for SQL performance. Men manglende
index vil normalt skabe en IO flaskehals ikke en CPU flaskehals.

Angående index er der så ikke automatisk et index på primary keys?

Cache er også en god ting. Men igen ville jeg forvente IO problemer
ikke CPU problemer ved manglende cache.

Der er automatisk index på primary keys.

Men måske der kunne mangle nogle index på andre relevante attributter.

renton>

Det bedste ville være hvis du kunne få en kopi af database og applikation
ned på en test maskine, hvor du kunne genskabe problemet og
eksperimentere frit.

Der bør altid være index på felter som man bruger til at joine på
og felter som man hyppigt bruger i normale where betingelser.

Den optimize table er en oprydnings/pakke funktion. Og altså nyttig
hvis der er opdateret og slettet heftigt i en tabel. Men ellers ikke.
Og igen er det IO ikke CPU.

arne_v>

Men hvordan skaber man den samme belastning på test maskinen?

Det virker bare mærkeligt at en database server skulle være så presset bare med simple select statements.

Jeg ville ihvertfald prøve at slå lidt caching til for i det mindste at se om det skulle give lidt.

Man laver en simulator.

Enten:

simulator-PHP-MySQL

eller mere direkte:

simulator-MySQL

Simulatoren skal naturligvis være multithreaded og lave requests svarende
til "høj belastning".

Der er værktøjer tilgængeligt på internettet til den slags.

Og et svar.

Generelt vil man forvente at en database er IO bound og ikke CPU bound.

websmith>

Nemlig ... der må gemme sig en mindre "fejl" et sted, som er skyld i det.

kører databasen på en linux-server eller en windows-maskine ? Kan du evt se om det faktisk er mysql som bruger al cpu-tiden eller det er en anden process ? Har du prøvet at vende database-serveren ?

du kan evt prøve at sætte lidt mere ram i maskinen; hvis hukommelsen er brugt op så kan det være at operativ systemet bruger kraft på at swappe ting ud på disken.

Og endeligt så kan det være en perfomance-forbedring at lægge database-pooling ind fra frontenden på maskinen.

http://sqlrelay.sourceforge.net/  er database-pooling for flere forskellige databaser (bla mysql) til forskellige programmeringssprog.

Tid at lukke spørgsmålet ?