it-swarm.asia

Mengapa utas MySQL sering menunjukkan status "membebaskan item" ketika cache kueri dinonaktifkan?

Ketika saya menjalankan SHOW PROCESSLIST, Sering ada sejumlah besar utas INSERT/PEMBARUAN dalam keadaan "membebaskan item".

Manual MySQL menunjukkan bahwa setidaknya sebagian alasan utas berada dalam status ini melibatkan cache kueri - mungkin ini akan membatalkan permintaan cache yang di-cache karena data yang diubah.

Namun, query_cache_size Saya disetel ke 0 yang seharusnya menonaktifkan cache permintaan sama sekali.

Apa alasan lain mengapa ada begitu banyak utas di negara ini?

Tabel yang relevan menggunakan mesin penyimpanan InnoDB.

16
Dan Grossman

Periksa nilai innodb_thread_concurrency.

Untuk sistem saya meningkatkan nilai dari 8 menjadi 32, per pedoman dalam dokumentasi MySql , menyebabkan penurunan yang terlihat dalam jumlah utas yang secara bersamaan melaporkan keadaan "membebaskan item". Juga, waktu permintaan rata-rata yang dihabiskan turun oleh urutan besarnya.

Meskipun ini membuat perbedaan besar dalam kinerja server secara keseluruhan, itu bukan peluru perak "item membebaskan". Ekosistem perangkat keras saya membuat saya berhipotesis bahwa keadaan ini sebagian besar terlihat pada sistem dengan disk "lambat" (serangan disk 2x10k 1), dan kurang lazim pada sistem dengan penyimpanan yang lebih cepat (disk drive 12x15k disk serangan 10). Jadi, pemeriksaan kinerja disk juga dapat dilakukan.

Semoga berhasil!

Juga:

Perlu dicatat bahwa nilai default dari innodb_thread_concurrency sangat berbeda tergantung pada rilis 5.0 poin apa yang sedang digunakan.

Nilai default telah berubah beberapa kali: 8 sebelum MySQL 5.0.8, 20 (tak terbatas) dari 5.0.8 hingga 5.0.18, 0 (tak terbatas) dari 5.0.19 hingga 5.0.20, dan 8 (terbatas) dari 5.0.21 di. - sumber

Ini berarti bahwa peningkatan yang tampaknya tidak berbahaya dari 5.0.20 ke 5.0.21 mengubah standar dari tak terbatas ke 8, dan membawa serta konsekuensi kinerja.

7
jphofmann

Membebaskan item adalah tahap pelaksanaan kueri di mana struktur sementara, buffer, dll dideallocated. Beberapa pekerjaan cache query dilakukan pada tahap ini, tetapi itu bukan satu-satunya hal yang terjadi di sana. Saya akan menyarankan menggunakan PROFIL TAMPILKAN untuk melihat berapa lama tahap ini relatif dibandingkan dengan tahap lainnya, dan jika waktu yang dihabiskan berakhir menjadi perhatian, pemecahan masalah dengan alat seperti profiler dan oprofile orang miskin.

5
Baron Schwartz

Ada laporan bug tentang masalah ini tentang "membebaskan item" dan cache kueri . Meskipun bug sudah ditutup, tidak disebutkan innodb_thread_concurrency .

Secara kebetulan, saya berbicara dengan Ronald Bradford di Percona Live NYC pada bulan Mei. Saya mengatakan kepadanya tentang situasi di mana saya tweeked innodb_thread_concurrency karena beberapa InnoDB Buffer Pool MySQL 5.5 menghasilkan banyak penguncian utas dan saya curiga bahwa data cache yang saya butuhkan kemungkinan besar telah menyebar di antara beberapa buffer pool.

Dia dengan jelas mengatakan kepada saya bahwa saya seharusnya tidak pernah menetapkan nilai terhadap innodb_thread_concurrency. Biarkan selalu menjadi nilai default, yang sekarang nol (0). Dengan melakukannya, Anda membiarkan penyimpanan InnoDB memutuskan berapa banyak innodb_concurrency_tickets untuk menghasilkan sendiri. Inilah yang dilakukan konkurensi tak terbatas.

'Membebaskan item' kemungkinan besar terjadi lebih sering ketika kita memberlakukan batasan pada innodb_thread_concurrency. Itu harus selalu nol (0). Saya akan mengambil risiko dan meningkatkan innodb_concurrency_tickets dan melihat apakah itu membantu atau tidak.

3
RolandoMySQLDBA

Kami memiliki masalah dengan gejala yang persis sama. Ternyata disk dengan file log InnoDB telah terisi. Layak diperiksa.

2
RedBlueThing

Petunjuk lain: Mungkin innodb fsync (). Coba pengaturan

innodb_flush_log_at_trx_commit = 2

Di my.cnf

Logfile innodb kemudian dibilas ke disk setiap 1-2 detik, bukannya ob pada setiap commit. Hukuman yang sedikit terhadap integritas data, keuntungan besar dalam kecepatan.

1
sto