Забелязах същото явление в моите системи. Заявките, които обикновено отнемат милисекунда, внезапно ще отнемат 1-2 секунди. Всички мои случаи са прости, една таблица INSERT/UPDATE/REPLACE изрази --- не на никакви SELECT. Не се забелязва натоварване, блокиране или натрупване на резба.
Подозирах, че това се дължи на изчистване на мръсни страници, изтриване на промени на диска или на някакъв скрит мютекс, но все още не съм го стеснил.
Също изключено
- Натоварване на сървъра – няма връзка с високо натоварване
- Engine – случва се с InnoDB/MyISAM/Memory
- MySQL Query Cache – случва се независимо дали е включен или изключен
- Завъртания на регистрационните файлове – няма корелация в събитията
Единственото друго наблюдение, което имам в този момент, е извлечено от факта, че изпълнявам един и същ db на множество машини. Имам силно приложение за четене, така че използвам среда с репликация - по-голямата част от натоварването е върху подчинените. Забелязах, че въпреки че има минимално натоварване на главната, явлението се появява повече там. Въпреки че не виждам проблеми със заключването, може би Innodb/Mysql има проблеми с едновременността на (нишка)? Припомнете си, че актуализациите на подчинения ще бъдат еднонишкови.
MySQL версия 5.1.48
Актуализиране
Мисля, че имам представа за проблема в моя случай. На някои от моите сървъри забелязах това явление на повече от другите. Виждайки какво е различното между различните сървъри и променяйки нещата наоколо, бях отведен до Системна променлива на MySQL innodb
innodb_flush_log_at_trx_commit .
Намерих документа за малко неудобен за четене, но innodb_flush_log_at_trx_commit може да приема стойностите на 1,2,0:
- За 1 буферът на регистрационния файл се изтрива в регистрационния файл за всяко записване и лог файлът се изтрива на диск за всяко записване.
- За 2 буферът на регистрационния файл се изтрива в регистрационния файл за всеки комит и лог файлът се изтрива на диск приблизително на всеки 1-2 секунди.
- При 0 буферът на регистрационния файл се изтрива в регистрационния файл всяка секунда, а лог файлът се изтрива на диск всяка секунда.
На практика в реда (1,2,0), както е отчетено и документирано, трябва да получите с увеличаване на производителността в търговията за повишен риск.
След като казах това, открих, че сървърите с innodb_flush_log_at_trx_commit=0 се представяха по-зле (т.е. имаха 10-100 пъти повече „дълги актуализации“) от сървърите с innodb_flush_log_at_trx_commit=2 . Освен това нещата веднага се подобриха в лошите случаи, когато го превключих на 2 (имайте предвид, че можете да го промените в движение).
И така, въпросът ми е към какво е настроен вашият? Имайте предвид, че не обвинявам този параметър, а по-скоро подчертавам, че контекстът му е свързан с този проблем.
