Všiml jsem si stejného jevu na svých systémech. Dotazy, které normálně trvají milisekundu, budou najednou trvat 1-2 sekundy. Všechny mé případy jsou jednoduché, příkazy INSERT/UPDATE/REPLACE s jednou tabulkou --- ne na žádných SELECTech. Není evidentní žádné zatížení, zamykání nebo vytváření vláken.
Měl jsem podezření, že je to kvůli vymazání špinavých stránek, vyprázdnění změn na disku nebo nějakého skrytého mutexu, ale ještě to musím zúžit.
Také vyloučeno
- Zatížení serveru – žádná korelace s vysokým zatížením
- Engine – děje se s InnoDB/MyISAM/Memory
- Mezipaměť dotazů MySQL – děje se bez ohledu na to, zda je zapnutá nebo vypnutá
- Otočení protokolu – žádná korelace v událostech
Jediné další pozorování, které mám v tomto bodě, je odvozeno ze skutečnosti, že provozuji stejnou databázi na více počítačích. Mám náročnou aplikaci pro čtení, takže používám prostředí s replikací - většina zátěže je na podřízených zařízeních. Všiml jsem si, že i když je na masteru minimální zátěž, tam se ten jev vyskytuje více. I když nevidím žádné problémy se zamykáním, možná má Innodb/Mysql potíže se souběžností (vlákna)? Připomeňme, že aktualizace na podřízeném zařízení budou jednovláknové.
MySQL verze 5.1.48
Aktualizovat
Myslím, že mám vodítko k problému v mém případě. Na některých mých serverech jsem tento fenomén zaznamenal na více než na ostatních. Když jsem viděl, co se mezi různými servery liší, a vyladil věci kolem, byl jsem přiveden k systémová proměnná MySQL innodb
innodb_flush_log_at_trx_commit .
Dokument se mi četl trochu nepohodlně, ale innodb_flush_log_at_trx_commit může nabývat hodnot 1,2,0:
- V případě 1 se vyrovnávací paměť protokolu vyprázdní do souboru protokolu při každém potvrzení a soubor protokolu se vyprázdní na disk při každém potvrzení.
- V případě 2 je vyrovnávací paměť protokolu vyprázdněna do souboru protokolu pro každé potvrzení a soubor protokolu je vyprázdněn na disk přibližně každé 1-2 sekundy.
- Pro hodnotu 0 se vyrovnávací paměť protokolu vyprázdní do souboru protokolu každou sekundu a soubor protokolu se každou sekundu vyprázdní na disk.
Efektivně, v objednávce (1,2,0), jak je hlášeno a zdokumentováno, byste měli získat se zvyšujícím se výkonem v obchodu se zvýšeným rizikem.
Když jsem to řekl, zjistil jsem, že servery s innodb_flush_log_at_trx_commit=0 měly horší výkon (tj. měly 10–100krát více „dlouhých aktualizací“) než servery s innodb_flush_log_at_trx_commit=2 . Navíc se věci okamžitě zlepšily ve špatných případech, když jsem to přepnul na 2 (všimněte si, že to můžete změnit za běhu).
Moje otázka tedy zní, jak je nastaveno to vaše? Všimněte si, že tento parametr neobviňuji, ale spíše zdůrazňuji, že jeho kontext souvisí s tímto problémem.