24. maj 2003 - 18:09
Der er
3 kommentarer og
1 løsning
Optimering af mysql database
Jeg har ansvaret for en mysql-databasen, som er back-end for 2 websider, der er godt besøgt.
Nu er siderne begyndt at blive periodisk langsomme. Der er selvfølgelig når den er mest besøgt. Det der sker er at, men må vente op imod 1min på en side, hvorefter siden kører fint i nogle minutter (nogen gange mindre),
hvorefter man oplever vente tid igen.
Jeg tror det skyldes at vi har mange (understreges) update og insert kald til tabeller som også er velbesøgt af select kald. Dvs. at meget af tiden er tabellerne låst, og man kan ikke læse fra dem, pga. update'sne og insert'
sne. Når så tabellen har været låst i et stykke tid, faldet antallet af updates og inserts, fordi de besøgene ikke kan komme ind på siden, og databasen kører igen fint.
Spørgsmål:
-Jeg er ikke sikker på at dette er årsagen, er der nogen der har ideer til hvordan jeg tjekker det?
-Er der nogen der ved hvordan jeg optimere databasen til at håndtere dette bedre?
-Ville det evt. hjælpe at skifte tabel-type fra myISAM til innodb (herunder en opdatering til mysql version 4), som skulle være bedre til at håndtere updates og inserts samtidig med selects?
--
Mvh
Anders Lund
Det kunne være interessant at lave en:
SHOW STATUS
og se de to variable:
Table_locks_immediate
Table_locks_waited
når det virker OK og lige efter et hik.
Standard råd: sørg for at der er index på alle felter der bruges
i WHERE og til at joine tabeller på.
Generelt kan man også formindske problemerne med samtidige SELECT
of INSERT/UPDATE ved at sænke transaction isolation level, hvis
end applikation vel at mærke kan leve med det. Men om det har nogen effekt
i MySQL med MyISAM som ikke understøtter transactions tvivler jeg måske lidt
på.
Hvis jeg har forstået MySQL dokumentationen korrekt, så laver MySQL noget
smart for INSERT som ikke skulle generer så meget men UPDATE skulle
bruge lock af hele tabellen for MyISAM. Det betyder at INSERT ikke burde
betyde så meget for SELECT men at UPDATE kan være dræbende.
Det problem vil kunne forbedres meget ved at skifte til InnsoDB, da
den understøtter row locking.
Hvis du har et test-system som du kan teste på uden at berøre
produktions systemet, så synes jeg at du skulle lave en
multi-threaded database client application som kan simulere
et typisk load og måle svar-tider.
Så vil du kunne verificere præcis hvad der trigger problemerne.
Er der UPDATE der er skurken ?
Og du vil kunne prøve at konvertere fra MyISAM til InnoDB og
prøve at teste igen og se om det hjælper på problemet.
