Pemantauan MySQL yang Efektif Dengan Dasbor SCUMM:Bagian 3

Kami membahas di blog kami sebelumnya tentang dasbor terkait MySQL. Kami menyoroti hal-hal yang dapat dimanfaatkan oleh DBA dengan mempelajari grafik, terutama saat melakukan rutinitas harian mereka dari diagnostik, pelaporan metrik, dan perencanaan kapasitas. Dalam blog ini, kita akan membahas Metrik InnoDB dan Skema Kinerja MySQL, yang sangat penting terutama dalam memantau transaksi InnoDB, I/O disk/cpu/memori, mengoptimalkan kueri Anda, atau menyetel kinerja server.

Blog ini menyentuh topik kinerja yang mendalam, mengingat InnoDB akan membutuhkan cakupan yang luas jika kita menangani internalnya. Skema Kinerja juga luas karena mencakup kernel dan bagian inti dari MySQL dan mesin penyimpanan.

Mari kita mulai menelusuri grafik.

Metrik InnoDB MySQL

Dasbor ini sangat bagus untuk semua orang MySQL DBA atau ops, karena menawarkan tampilan yang sangat bagus ke dalam mesin penyimpanan InnoDB. Ada grafik tertentu di sini yang harus dipertimbangkan pengguna untuk diaktifkan, karena tidak dalam semua situasi variabel disetel dengan benar dalam konfigurasi MySQL.

• Usia Pos Pemeriksaan Innodb

  Menurut manual, checkpointing didefinisikan sebagai berikut:“Saat perubahan dibuat pada halaman data yang di-cache di buffer pool , perubahan tersebut ditulis ke file data beberapa waktu kemudian, sebuah proses yang dikenal sebagai pembilasan . Pos pemeriksaan adalah catatan perubahan terbaru (diwakili oleh LSN value) yang telah berhasil ditulis ke file data ”. Grafik ini berguna ketika Anda ingin menentukan bagaimana server Anda melakukan checkpointing data ke disk Anda. Ini bisa menjadi referensi yang baik jika log transaksi Anda (redo log atau ib_logfile0) terlalu besar. Grafik ini juga merupakan indikator yang baik jika Anda perlu menyesuaikan variabel seperti innodb_log_file_size,, innodb_log_buffer_size, innodb_max_dirty_pages_pct, atau innodb_adaptive_flushing_method. Semakin dekat usia pos pemeriksaan ke usia pos pemeriksaan maksimal, semakin banyak log yang terisi dan InnoDB akan melakukan lebih banyak I/O untuk mempertahankan ruang kosong di log. Mekanisme checkpoint berbeda dalam detail halus antara rasa berbasis Percona XtraDB, versi MariaDB dan Oracle, Anda juga dapat menemukan perbedaan dalam implementasinya antara versi MySQL.

• Transaksi InnoDB

  Setiap kali ada transaksi besar yang sedang berlangsung di server MySQL Anda, grafik ini adalah referensi yang bagus. Ini akan menghitung transaksi yang dibuat pada waktu tertentu, dan panjang riwayat (atau sebenarnya panjang daftar riwayat yang ditemukan di SHOW ENGINE INNODB STATUS) adalah jumlah halaman di log undo. Tren yang akan Anda lihat di sini adalah sumber yang bagus untuk memeriksa apakah itu bisa berarti, misalnya, pembersihan itu tertunda karena tingkat penyisipan yang sangat tinggi saat memuat ulang data atau karena transaksi yang berjalan lama, atau jika pembersihan hanya bisa 't mengikuti karena I/O disk tinggi dalam volume tempat $DATADIR Anda berada.

• Operasi Baris Innodb

  Untuk tugas DBA tertentu, Anda mungkin ingin menentukan jumlah penghapusan, penyisipan, pembacaan, dan pembaruan baris. Maka grafik inilah yang dapat Anda gunakan untuk memeriksanya.

• Waktu Penguncian Baris Innodb

  Grafik ini adalah sumber yang bagus untuk dilihat ketika Anda memperhatikan bahwa aplikasi Anda mengalami banyak kejadian untuk “Waktu tunggu kunci terlampaui; coba mulai ulang transaksi ”. Ini juga dapat membantu Anda menentukan apakah Anda mungkin memiliki indikasi untuk menggunakan kueri buruk dalam menangani kunci. Ini juga merupakan referensi yang baik untuk dilihat saat mengoptimalkan kueri Anda yang melibatkan penguncian baris. Jika waktu untuk menunggu terlalu tinggi, Anda perlu memeriksa log kueri yang lambat atau menjalankan pt-query-digest dan melihat kueri apa yang dicurigai menyebabkan pembengkakan tersebut pada grafik.

  

• I/O InnoDB

  Kapan pun Anda ingin menentukan jumlah pembacaan data InnoDB, penghapusan disk, penulisan, dan penulisan log, grafik ini memiliki apa yang perlu Anda lihat. Anda dapat menggunakan grafik ini untuk menentukan apakah variabel InnoDB Anda disetel dengan baik untuk menangani kebutuhan spesifik Anda. Misalnya, jika Anda memiliki cache Modul Cadangan Baterai tetapi Anda tidak mendapatkan banyak kinerja optimalnya, Anda dapat mengandalkan grafik ini untuk menentukan apakah fsyncs() Anda lebih tinggi dari yang diharapkan. Kemudian mengubah variabel innodb_flush_method dan menggunakan O_DSYNC dapat menyelesaikan masalah.

• Penggunaan File Log InnoDB Setiap Jam

  Grafik ini hanya menunjukkan jumlah byte yang ditulis ke file log redo InnoDB dan pertumbuhan file log InnoDB Anda berdasarkan rentang waktu 24 jam dari tanggal saat ini.

• Kinerja Pencatatan InnoDB

  Grafik ini terkait erat dengan grafik Penggunaan File Log InnoDB Per Jam. Anda harus menggunakan grafik ini kapan pun Anda perlu menentukan seberapa besar ukuran innodb_log_file_size Anda. Anda dapat menentukan jumlah byte yang ditulis ke file log redo InnoDB dan seberapa efisien MySQL Anda mem-flush data dari memori ke disk. Setiap kali Anda mengalami waktu rendah untuk menggunakan ruang redo log Anda, maka itu akan menunjukkan bahwa Anda harus meningkatkan ukuran file innodb_log_file Anda. Dalam hal ini, grafik ini akan memberi tahu Anda bahwa Anda perlu melakukannya. Namun, untuk menggali lebih dalam berapa banyak yang Anda butuhkan untuk innodb_log_file Anda, mungkin lebih masuk akal untuk memeriksa LSN (Log Sequence Number) di SHOW ENGINE INNODB STATUS. Percona memiliki blog bagus yang terkait dengan ini yang merupakan sumber yang bagus untuk dilihat.

• Deadlock InnoDB

  Dalam situasi tertentu di mana klien aplikasi Anda sering mengalami kebuntuan atau Anda harus melihat seberapa banyak MySQL Anda mengalami kebuntuan, grafik ini dapat digunakan. Deadlock menunjukkan bahwa Anda memiliki desain SQL yang buruk yang menyebabkan transaksi Anda menciptakan kondisi balapan yang menyebabkan deadlock.

• Penurunan Kondisi Indeks

  Sedikit peringatan ketika melihat grafik ini. Pertama, Anda harus menentukan bahwa variabel global MySQL Anda innodb_monitor_enable disetel ke nilai yang benar yaitu module_icp. Jika tidak, Anda akan mengalami “Tidak Ada Poin Data” seperti yang ditunjukkan di bawah ini:

  

  Tujuan grafik, jika memiliki titik data yang ditentukan seperti yang saya miliki dalam output sampel, akan memberikan DBA pandangan tentang seberapa baik kueri Anda diuntungkan dengan Index Condition Pushdown atau singkatnya ICP. ICP adalah fitur hebat di MySQL yang menawarkan pengoptimalan untuk kueri Anda. Alih-alih MySQL membaca baris penuh yang difilter dalam kueri WHERE Anda setelah pengambilan, itu akan menambahkan lebih banyak pemeriksaan setelah indeks sekunder Anda. Ini menambah lebih banyak perincian dan menghemat waktu, jika tidak, mesin harus membaca baris tabel penuh sebagai gantinya ketika hanya didasarkan pada indeks yang difilter dan tidak ada ICP yang digunakan. Ini menghindari membaca baris penuh yang sesuai dengan tupel indeks Anda yang cocok dengan indeks sekunder Anda.

  Biarkan saya menguraikan sedikit tentang grafik ini, katakanlah saya memiliki tabel bernama:

  mysql> show create table a\G
  *************************** 1. row ***************************
         Table: a
  Create Table: CREATE TABLE `a` (
    `id` int(11) NOT NULL,
    `age` int(11) NOT NULL,
    KEY `id` (`id`)
  ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  1 row in set (0.00 sec)

  Dan memiliki beberapa data kecil:

  mysql> select * from a;
  +----+-----+
  | id | age |
  +----+-----+
  |  1 |   1 |
  |  2 |   1 |
  |  3 |   1 |
  |  3 |  41 |
  |  4 |  41 |
  |  5 |   4 |
  |  4 |   4 |
  |  4 |   4 |
  +----+-----+
  8 rows in set (0.00 sec)

  Saat ICP diaktifkan, hasilnya lebih efisien dan layak:

  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
  1 row in set, 2 warnings (0.00 sec)

  Daripada tanpa ICP,

  mysql> set optimizer_switch='index_condition_pushdown=off';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> explain extended select * from a where id>2 and id<4 and age=41;
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  | id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  |  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
  +----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
  1 row in set, 2 warnings (0.00 sec)

  Ini adalah contoh sederhana ICP, dan bagaimana grafik ini dapat bermanfaat bagi DBA.

  

• Konten Kumpulan Buffer InnoDB

  Saat bekerja dengan MySQL dan menggunakan mesin InnoDB, grafik ini adalah salah satu nilai paling umum (innodb_buffer_pool*) yang harus Anda sesuaikan untuk mengoptimalkan kinerja MySQL. Secara khusus berbicara tentang konten buffer pool, ini menampilkan tren halaman kotor terhadap total konten buffer pool. Konten kumpulan buffer total mencakup halaman bersih selain halaman kotor. Menentukan seberapa efisien MySQL Anda menangani kumpulan buffer, grafik ini sesuai dengan tujuannya.

• Halaman Pool Buffer InnoDB

  Grafik ini berguna ketika Anda ingin memeriksa seberapa efisien MySQL menggunakan kumpulan buffer InnoDB Anda. Anda dapat menggunakan grafik ini, misalnya, jika lalu lintas harian Anda tidak memenuhi innodb_buffer_pool_size yang ditetapkan, maka ini dapat menunjukkan bahwa bagian tertentu dari aplikasi tidak berguna atau tidak memiliki tujuan apa pun atau jika Anda menyetel innodb_buffer_pool_size sangat tinggi yang mungkin baik untuk menurunkan nilainya dan mendapatkan kembali ruang memori Anda.

• I/O Kumpulan Penyangga InnoDB

  Ketika Anda harus memeriksa jumlah halaman yang dibuat dan ditulis pada tabel InnoDB atau halaman yang dibaca ke kumpulan buffer InnoDB dengan operasi pada tabel InnoDB.

• Permintaan Kumpulan Buffer InnoDB

  Saat Anda ingin menentukan seberapa efisien kueri Anda mengakses kumpulan buffer InnoDB, grafik ini berfungsi. Grafik ini akan menunjukkan tren berdasarkan titik data tentang bagaimana kinerja server MySQL Anda ketika mesin InnoDB harus sering mengakses disk (indikasi kumpulan buffer belum memanas), seberapa sering permintaan kumpulan buffer menangani permintaan baca dan tulis permintaan.

• InnoDB Read-Ahead

  Ketika variabel innodb_random_read_ahead disetel ke AKTIF, tambahkan grafik ini sebagai tren yang berharga untuk dilihat sebagai bagian dari rutinitas DBA Anda. Ini menunjukkan tren tentang bagaimana mesin penyimpanan MySQL InnoDB Anda mengelola kumpulan buffer dengan utas latar belakang baca-depan, bagaimana ia mengelola yang kemudian digusur tanpa diakses oleh kueri, dan bagaimana InnoDB memulai pembacaan maju acak saat kueri memindai sebagian besar tabel tetapi dalam urutan acak.

  

• Buffer Perubahan InnoDB

  Saat Anda menjalankan Percona Server 5.7, grafik ini berguna saat memantau seberapa baik InnoDB telah mengalokasikan buffering perubahan. Perubahan ini mencakup penyisipan, pembaruan, dan penghapusan yang ditentukan oleh variabel innodb_change_buffering. Perubahan buffering membantu mempercepat kueri, menghindari I/O akses acak substansial yang akan diperlukan untuk membaca halaman indeks sekunder dari disk.

• Aktivitas Perubahan Buffer InnoDB

  Ini terkait dengan grafik InnoDB Change Buffer, tetapi membedah informasi menjadi titik data yang lebih layak. Ini memberikan lebih banyak informasi untuk memantau bagaimana InnoDB menangani buffering perubahan. Ini berguna dalam tugas DBA tertentu untuk menentukan apakah innodb_change_buffer_max_size Anda disetel ke nilai yang terlalu tinggi, karena buffering perubahan berbagi memori yang sama dari kumpulan buffer InnoDB yang mengurangi memori yang tersedia untuk cache halaman data. Anda mungkin harus mempertimbangkan untuk menonaktifkan buffering perubahan jika set kerja hampir sesuai dengan kumpulan buffer, atau jika tabel Anda memiliki indeks sekunder yang relatif sedikit. Ingat bahwa buffering perubahan tidak memaksakan overhead tambahan, karena hanya berlaku untuk halaman yang tidak ada di buffer pool. Grafik ini juga berguna jika Anda harus menentukan bagaimana penggabungan berguna jika Anda harus membandingkan aplikasi Anda berdasarkan permintaan tertentu untuk skenario tertentu. Katakanlah Anda memiliki sisipan massal, Anda harus mengatur innodb_change_buffering=insert dan menentukan apakah memiliki nilai yang ditetapkan di kumpulan buffer Anda dan innodb_change_buffer_max_size tidak memengaruhi I/O disk, khususnya selama pemulihan atau shutdown lambat (diperlukan jika Anda ingin melakukan failover dengan persyaratan downtime rendah). Selain itu, grafik ini dapat membantu tujuan Anda untuk mengevaluasi skenario tertentu, karena penggabungan buffer perubahan dapat memakan waktu beberapa jam ketika ada banyak indeks sekunder untuk diperbarui dan banyak baris yang terpengaruh. Selama waktu ini, I/O disk meningkat, yang dapat menyebabkan perlambatan signifikan untuk kueri yang terikat disk.

Skema Kinerja MySQL

Skema Kinerja MySQL adalah topik yang rumit. Ini panjang dan sulit, tetapi saya hanya akan membahas informasi yang khusus untuk grafik yang kita miliki di SCUMM. Ada juga variabel tertentu yang harus Anda pertimbangkan, dan pastikan variabel tersebut disetel dengan benar. Pastikan Anda memiliki variabel innodb_monitor_enable =all dan userstat=1 untuk melihat titik data dalam grafik Anda. Sebagai catatan, ketika saya menggunakan kata “event” di sini, bukan berarti ini terkait dengan MySQL Event Scheduler. Saya berbicara tentang peristiwa tertentu seperti MySQL mem-parsing kueri, MySQL membaca atau menulis ke relai/file log biner, dll.

Mari kita lanjutkan dengan grafiknya.

• File Skema Kinerja IO (Peristiwa)

  Grafik ini mengambil titik data yang terkait dengan peristiwa apa pun yang terjadi di MySQL yang mungkin telah diinstrumentasi untuk membuat beberapa instance objek yang diinstrumentasi (misalnya pembacaan log biner atau pembacaan file data InnoDB). Setiap baris merangkum acara untuk nama acara tertentu. Misalnya, jika ada instrumen untuk mutex yang dibuat untuk setiap koneksi, maka mungkin ada banyak contoh kejadian berinstrumen ini karena ada banyak koneksi. Baris ringkasan untuk instrumen merangkum semua contoh ini. Anda dapat memeriksa kejadian ini di manual MySQL untuk Tabel Ringkasan Skema Kinerja untuk info lebih lanjut.

• Kinerja Skema File IO (Muat)

  Grafik ini sama dengan grafik “Performance Schema File IO (Events)” kecuali grafik ini diinstrumentasikan berdasarkan beban.

• File Skema Kinerja IO (Bytes)

  Grafik ini sama dengan grafik “Performance Schema File IO (Events)” kecuali grafiknya diinstrumentasikan berdasarkan ukuran dalam byte. Misalnya, berapa lama waktu yang diperlukan peristiwa tertentu saat MySQL memicu peristiwa wait/io/file/innodb/innodb_data_file.

• Skema Kinerja Menunggu (Peristiwa)

  Grafik ini memiliki grafik data untuk semua waktu tunggu yang dihabiskan pada peristiwa tertentu. Anda dapat memeriksa Tabel Ringkasan Acara Tunggu di manual untuk info lebih lanjut.

  

• Skema Kinerja Menunggu (Memuat)

  Sama seperti grafik “Skema Kinerja Menunggu (Peristiwa)” tetapi kali ini menunjukkan tren pemuatan.

• Operasi Akses Indeks (Pemuatan)

  Grafik ini adalah agregasi dari semua peristiwa wait I/O indeks tabel yang dikelompokkan berdasarkan indeks tabel, seperti yang dihasilkan oleh instrumen wait/io/table/sql/handler. Anda dapat memeriksa manual MySQL tentang tabel Skema Kinerja table_io_waits_summary_by_index_usage untuk info lebih lanjut.

• Operasi Akses Tabel (Pemuatan)

  Grafik “Sama seperti Index Access Operations (Load)”, ini adalah agregasi dari semua tabel I/O wait event group by table, seperti yang dihasilkan oleh instrumen wait/io/table/sql/handler. Ini sangat berguna untuk DBA. Misalnya, Anda ingin melacak seberapa cepat yang diperlukan untuk mengakses (mengambil) atau memperbarui (menyisipkan, menghapus, memperbarui) tabel tertentu. Anda dapat memeriksa manual MySQL tentang tabel Skema Kinerja table_io_waits_summary_by_table untuk info lebih lanjut.

  

• Skema Kinerja SQL &Kunci Eksternal (Acara)

  Grafik ini merupakan agregasi (menghitung berapa kali hal itu terjadi) dari semua peristiwa menunggu kunci tabel, seperti yang dihasilkan oleh instrumen wait/lock/table/sql/handler yang dikelompokkan berdasarkan tabel. Kunci SQL di sini dalam grafik berarti kunci internal. Kunci internal ini dibaca normal, membaca dengan kunci bersama, membaca prioritas tinggi, tidak membaca penyisipan, menulis izinkan menulis, menulis penyisipan bersamaan, menulis tertunda, menulis prioritas rendah, menulis normal. Sedangkan kunci eksternal membaca eksternal dan menulis eksternal. Dalam tugas DBA apa pun, ini sangat berguna jika Anda harus melacak dan menyelidiki kunci pada tabel tertentu terlepas dari jenisnya. Anda dapat memeriksa tabel table_lock_waits_summary_by_table untuk info lebih lanjut.

• Skema Kinerja SQL dan Kunci Eksternal (Detik)

  Sama seperti grafik “Performance Schema SQL &External Locks (Events)”, tetapi ditentukan dalam detik. Jika Anda ingin mencari kunci meja Anda berdasarkan detik ia menahan kunci, maka grafik ini adalah sumber yang bagus untuk Anda.

Kesimpulan

Metrik InnoDB dan Skema Kinerja MySQL adalah beberapa bagian yang paling mendalam dan rumit dalam domain MySQL, terutama ketika tidak ada visualisasi untuk membantu interpretasi. Jadi, pergi ke penelusuran manual dan investigasi mungkin membutuhkan waktu dan kerja keras Anda. Dasbor SCUMM menawarkan cara yang sangat efisien dan layak untuk menangani ini dan menurunkan beban ekstra pada tugas rutin DBA.

Di blog ini, Anda mempelajari cara menggunakan dasbor untuk InnoDB dan Skema Kinerja untuk meningkatkan kinerja basis data. Dasbor ini dapat membuat Anda lebih efisien dalam menganalisis kinerja.