Jag har märkt samma fenomen på mina system. Frågor som normalt tar en millisekund tar plötsligt 1-2 sekunder. Alla mina fall är enkla, enkeltabell INSERT/UPDATE/REPLACE-satser --- inte på några SELECT. Ingen belastning, låsning eller gänguppbyggnad är uppenbar.
Jag hade misstänkt att det berodde på att rensa bort smutsiga sidor, tömning av ändringar på disken eller något dold mutex, men jag har ännu inte begränsat det.
Också utesluten
- Serverbelastning -- ingen korrelation med hög belastning
- Motor -- händer med InnoDB/MyISAM/Memory
- MySQL Query Cache – händer oavsett om den är på eller av
- Loggrotationer -- ingen korrelation i händelser
Den enda andra observationen jag har vid det här laget är härledd från det faktum att jag kör samma db på flera maskiner. Jag har en tung läsapplikation så jag använder en miljö med replikering -- det mesta av belastningen är på slavarna. Jag har märkt att även om det är minimal belastning på mastern så uppstår fenomenet mer där. Även om jag inte ser några låsningsproblem, kanske det är Innodb/Mysql som har problem med (tråd) samtidighet? Kom ihåg att uppdateringarna på slaven kommer att vara entrådiga.
MySQL Verion 5.1.48
Uppdatera
Jag tror att jag har en ledtråd för problemet i mitt fall. På några av mina servrar märkte jag detta fenomen på fler än de andra. När jag såg vad som var olika mellan de olika servrarna och justerade saker, leddes jag till MySQL innodb systemvariabel
innodb_flush_log_at_trx_commit .
Jag tyckte att dokumentet var lite besvärligt att läsa, men innodb_flush_log_at_trx_commit kan ta värdena 1,2,0:
- För 1 töms loggbufferten till loggfilen för varje commit, och loggfilen töms till disken för varje commit.
- För 2 töms loggbufferten till loggfilen för varje commit, och loggfilen töms till disken ungefär var 1-2:e sekund.
- För 0 töms loggbufferten till loggfilen varje sekund, och loggfilen töms till disken varje sekund.
Effektivt, i den ordning (1,2,0), som rapporterats och dokumenterats, är det meningen att du ska få med ökande prestanda i handeln för ökad risk.
Med det sagt upptäckte jag att servrarna med innodb_flush_log_at_trx_commit=0 presterade sämre (dvs. hade 10-100 gånger fler "långa uppdateringar") än servrarna med innodb_flush_log_at_trx_commit=2 . Dessutom förbättrades saker omedelbart i de dåliga fallen när jag bytte den till 2 (observera att du kan ändra det direkt).
Så min fråga är, vad är din inställd på? Observera att jag inte skyller på den här parametern, utan snarare framhåller att dess sammanhang är relaterat till det här problemet.