Saya telah memperhatikan fenomena yang sama pada sistem saya. Pertanyaan yang biasanya memakan waktu satu milidetik tiba-tiba akan memakan waktu 1-2 detik. Semua kasus saya sederhana, satu tabel INSERT/UPDATE/REPLACE pernyataan --- tidak pada SELECT apa pun. Tidak ada beban, penguncian, atau penumpukan benang yang terlihat.
Saya telah menduga bahwa itu karena membersihkan halaman kotor, menghapus perubahan ke disk, atau mutex tersembunyi, tetapi saya belum mempersempitnya.
Juga Disingkirkan
- Pemuatan server -- tidak ada korelasi dengan beban tinggi
- Mesin -- terjadi dengan InnoDB/MyISAM/Memory
- Tembolok Kueri MySQL -- terjadi baik aktif maupun nonaktif
- Rotasi log -- tidak ada korelasi dalam peristiwa
Satu-satunya pengamatan lain yang saya miliki saat ini berasal dari fakta bahwa saya menjalankan db yang sama pada banyak mesin. Saya memiliki aplikasi baca yang berat jadi saya menggunakan lingkungan dengan replikasi -- sebagian besar beban ada di budak. Saya perhatikan bahwa meskipun ada beban minimal pada master, fenomena tersebut lebih banyak terjadi di sana. Meskipun saya tidak melihat masalah penguncian, mungkin Innodb/Mysql mengalami masalah dengan konkurensi (utas)? Ingatlah bahwa pembaruan pada budak akan menjadi satu utas.
MySQL Versi 5.1.48
Perbarui
Saya pikir saya memiliki petunjuk untuk masalah pada kasus saya. Di beberapa server saya, saya melihat fenomena ini lebih dari yang lain. Melihat apa yang berbeda antara server yang berbeda, dan mengutak-atik hal-hal di sekitar, saya diarahkan ke Variabel sistem innodb MySQL
innodb_flush_log_at_trx_commit .
Saya menemukan dokumen ini agak canggung untuk dibaca, tetapi innodb_flush_log_at_trx_commit dapat mengambil nilai 1,2,0:
- Untuk 1, buffer log di-flush ke file log untuk setiap komit, dan file log di-flush ke disk untuk setiap komit.
- Untuk 2, buffer log di-flush ke file log untuk setiap komit, dan file log di-flush ke disk kira-kira setiap 1-2 detik.
- Untuk 0, buffer log di-flush ke file log setiap detik, dan file log di-flush ke disk setiap detik.
Secara efektif, dalam urutan (1,2,0), seperti yang dilaporkan dan didokumentasikan, Anda seharusnya mendapatkan peningkatan kinerja dalam perdagangan untuk peningkatan risiko.
Karena itu, saya menemukan bahwa server dengan innodb_flush_log_at_trx_commit=0 berkinerja lebih buruk (yaitu memiliki 10-100 kali lebih banyak "pembaruan panjang") daripada server dengan innodb_flush_log_at_trx_commit=2 . Selain itu, hal-hal segera membaik pada contoh buruk ketika saya beralih ke 2 (perhatikan Anda dapat mengubahnya dengan cepat).
Jadi, pertanyaan saya adalah, apa yang Anda setel? Perhatikan bahwa saya tidak menyalahkan parameter ini, melainkan menyoroti bahwa konteksnya terkait dengan masalah ini.
