Jeg har bemærket det samme fænomen på mine systemer. Forespørgsler, der normalt tager et millisekund, vil pludselig tage 1-2 sekunder. Alle mine cases er simple INSERT/UPDATE/REPLACE-sætninger med en enkelt tabel --- ikke på nogen SELECT'er. Ingen belastning, låsning eller gevindopbygning er tydelig.
Jeg havde mistanke om, at det skyldtes at rydde snavsede sider ud, skylle ændringer til disken eller en eller anden skjult mutex, men jeg har endnu ikke indskrænket det.
Også udelukket
- Serverbelastning -- ingen korrelation med høj belastning
- Engine -- sker med InnoDB/MyISAM/Memory
- MySQL Query Cache -- sker uanset om den er slået til eller fra
- Log rotationer – ingen sammenhæng i hændelser
Den eneste anden observation, jeg har på dette tidspunkt, er afledt af det faktum, at jeg kører den samme db på flere maskiner. Jeg har et tungt læseprogram, så jeg bruger et miljø med replikering -- det meste af belastningen er på slaverne. Jeg har bemærket, at selvom der er minimal belastning på masteren, så opstår fænomenet mere der. Selvom jeg ikke ser nogen låseproblemer, er det måske Innodb/Mysql, der har problemer med (tråd) samtidighed? Husk, at opdateringerne på slaven vil være enkelttrådede.
MySQL Verion 5.1.48
Opdater
Jeg tror, jeg har en ledetråd til problemet i min sag. På nogle af mine servere bemærkede jeg dette fænomen på flere end de andre. Da jeg så, hvad der var forskelligt mellem de forskellige servere, og tilpassede tingene, blev jeg ledt til MySQL innodb systemvariabel
innodb_flush_log_at_trx_commit .
Jeg fandt dokumentet lidt akavet at læse, men innodb_flush_log_at_trx_commit kan tage værdierne 1,2,0:
- For 1 tømmes logbufferen til logfilen for hver commit, og logfilen tømmes til disken for hver commit.
- For 2 tømmes logbufferen til logfilen for hver commit, og logfilen tømmes til disk ca. hvert 1.-2. sekund.
- For 0 tømmes logbufferen til logfilen hvert sekund, og logfilen tømmes til disk hvert sekund.
Effektivt, i den rækkefølge (1,2,0), som rapporteret og dokumenteret, formodes du at få med stigende præstation i handelen for øget risiko.
Når det er sagt, fandt jeg ud af, at serverne med innodb_flush_log_at_trx_commit=0 præsterede dårligere (dvs. havde 10-100 gange flere "lange opdateringer") end serverne med innodb_flush_log_at_trx_commit=2 . Desuden blev tingene straks forbedret i de dårlige tilfælde, da jeg skiftede til 2 (bemærk, at du kan ændre det med det samme).
Så mit spørgsmål er, hvad er din indstillet til? Bemærk, at jeg ikke bebrejder denne parameter, men snarere fremhæver, at dens kontekst er relateret til dette problem.