Ho notato lo stesso fenomeno sui miei sistemi. Le query che normalmente richiedono un millisecondo impiegheranno improvvisamente 1-2 secondi. Tutti i miei casi sono semplici istruzioni INSERT/UPDATE/REPLACE a tabella singola --- non su nessun SELECT. Non è evidente alcun carico, bloccaggio o accumulo di filo.
Sospettavo che fosse dovuto alla rimozione di pagine sporche, allo svuotamento delle modifiche sul disco o a qualche mutex nascosto, ma devo ancora restringere il campo.
Anche escluso
- Carico del server:nessuna correlazione con un carico elevato
- Motore -- succede con InnoDB/MyISAM/Memory
- MySQL Query Cache:si verifica indipendentemente dal fatto che sia attivata o disattivata
- Rotazioni del registro:nessuna correlazione negli eventi
L'unica altra osservazione che ho a questo punto deriva dal fatto che sto eseguendo lo stesso db su più macchine. Ho un'applicazione di lettura pesante, quindi sto usando un ambiente con replica:la maggior parte del carico è sugli slave. Ho notato che anche se c'è un carico minimo sul master, il fenomeno si verifica di più lì. Anche se non vedo problemi di blocco, forse Innodb/Mysql ha problemi con la concorrenza (thread)? Ricordiamo che gli aggiornamenti sullo slave saranno a thread singolo.
MySQL versione 5.1.48
Aggiorna
Penso di avere una pista per il problema sul mio caso. Su alcuni dei miei server ho notato questo fenomeno più degli altri. Vedendo cosa c'era di diverso tra i diversi server e modificando le cose, sono stato portato a Variabile di sistema MySQL innodb
innodb_flush_log_at_trx_commit .
Ho trovato il documento un po' scomodo da leggere, ma innodb_flush_log_at_trx_commit può assumere i valori di 1,2,0:
- Per 1, il buffer di registro viene scaricato nel file di registro per ogni commit e il file di registro viene scaricato su disco per ogni commit.
- Per 2, il buffer di registro viene scaricato nel file di registro per ogni commit e il file di registro viene scaricato su disco approssimativamente ogni 1-2 secondi.
- Per 0, il buffer di registro viene scaricato nel file di registro ogni secondo e il file di registro viene scaricato sul disco ogni secondo.
In effetti, nell'ordine (1,2,0), come riportato e documentato, dovresti ottenere con l'aumento delle prestazioni nel commercio per un aumento del rischio.
Detto questo, ho scoperto che i server con innodb_flush_log_at_trx_commit=0 avevano prestazioni peggiori (ovvero avendo 10-100 volte più "aggiornamenti lunghi") rispetto ai server con innodb_flush_log_at_trx_commit=2 . Inoltre, le cose sono immediatamente migliorate nelle istanze negative quando l'ho passato a 2 (nota che puoi cambiarlo al volo).
Quindi, la mia domanda è:su cosa è impostato il tuo? Nota che non sto incolpando questo parametro, ma piuttosto evidenziando che il suo contesto è correlato a questo problema.
