Di hampir semua server produksi, sebaiknya matikan cache Query. Setiap modifikasi pada tabel menyebabkan pembersihan semua entri QC untuk tabel itu. Semakin besar meja, semakin banyak waktu yang dibutuhkan. 128M sangat tinggi.
Biasanya, adalah bijaksana untuk mengatur innodb_buffer_pool_size hingga sekitar 70% dari tersedia RAM. Anda telah menyetelnya ke nilai yang jauh lebih rendah, bahkan lebih kecil dari ukuran set data. 3G mungkin akan membantu. 20G tidak akan membantu lagi (sampai dataset Anda tumbuh secara signifikan).
Pastikan OS dan MySQL adalah versi 64-bit.
Untuk analisis yang lebih menyeluruh, berikan
- Ukuran RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(setelah berjalan setidaknya 24 jam)
Analisis VARIABEL dan STATUS:
Masalah Yang Lebih Penting
Karena Anda hanya (?) Menggunakan InnoDB dan hanya 2GB data, tidak penting untuk menanggapi komentar-komentar tentang innodb_buffer_pool_size dan key_buffer_size
Berikan beberapa detail lebih lanjut tentang penggunaan berat DELETE .
Manfaatkan slowlog untuk menemukan kueri 'terburuk'. Lebih detail di sini . Itu akan mengidentifikasi masalah pemindaian tmp_table dan tabel yang disebutkan di bawah.
Jangan repot-repot menggunakan OPTIMIZE TABLE .
Bagaimana Anda melakukan "transaksi"? Terkadang dengan komit otomatis, terkadang dengan COMMIT ?
Detail dan pengamatan lainnya
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Persentase key_buffer yang digunakan. High-water-mark.-- Turunkan key_buffer_size untuk menghindari penggunaan memori yang tidak perlu.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % RAM yang digunakan untuk buffer_pool InnoDB
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- Sebagian besar ram yang tersedia harus tersedia untuk cache.-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffer pool free -- buffer_pool_size lebih besar dari working set; bisa menguranginya
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Tulis permintaan yang harus mencapai disk-- Periksa innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Persentase kumpulan buffer yang diambil oleh data-- Sebagian kecil mungkin menunjukkan bahwa buffer_pool terlalu besar.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Menit antara rotasi log InnoDB Dimulai dengan 5.6.8, ini dapat diubah secara dinamis; pastikan juga untuk mengubah my.cnf.-- (Rekomendasi 60 menit antara rotasi agak sewenang-wenang.) Sesuaikan innodb_log_file_size. (Tidak dapat diubah di AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Jangan antri, lakukan saja." (Jika MySQL sedang digunakan sebagai antrian.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Persentase tabel temp yang tumpah ke disk -- mungkin meningkatkan tmp_table_size dan max_heap_table_size; menghindari gumpalan, dll.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- pemindaian tabel lengkap-- Tambahkan indeks / optimalkan kueri (kecuali tabel kecil)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % pilihan melakukan pemindaian tabel penuh. (Mungkin tertipu oleh Rutinitas Tersimpan.)-- Tambahkan indeks / optimalkan kueri
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Seberapa sering OPTIMIZE TABLE dilakukan.-- OPTIMIZE TABLE jarang berguna, tentu saja tidak pada frekuensi tinggi.
( long_query_time ) = 10.000000 = 10 -- Cutoff (Detik) untuk mendefinisikan kueri "lambat".-- Sarankan 2
Ekstrem (tanpa komentar):
Sangat kecil:
Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360
Luar biasa besar:
Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8 (This may be unused? It was removed in 5.6.3, but possibly left in MariaDB 10.1?)
String tidak normal:
Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off
Tembolok kueri
Karena dimatikan, tidak ada nilai status Qcache yang disetel. Jadi saya tidak bisa menjawab pertanyaan awal. Jika Anda ingin mengaktifkan QC dan memulai ulang server dan menunggu beberapa hari, saya dapat menganalisis ulang dengan mengaktifkannya. Berbagai metrik tentang hit, prune, dll mungkin menjawab pertanyaan awal.
