KAL
Menu

Pemantauan

SHOW STATUS dan PROCESSLIST, serta pengenalan performance_schema.

Daftar isi

Pemantauan menjawab pertanyaan tentang keadaan server pada suatu saat: berapa banyak pekerjaan yang sedang berjalan, dari mana sumber beban, dan apakah ada koneksi yang tersangkut. MySQL menyediakan tiga lapis alat untuk itu, yaitu SHOW STATUS yang menampilkan penghitung kerja, PROCESSLIST yang menampilkan koneksi aktif, dan performance_schema yang merekam peristiwa secara terstruktur. Setelah membacanya, ketiga lapis alat tersebut dapat dibaca dengan memilih nilai yang benar-benar bermakna untuk diagnosa.

SHOW STATUS dan macam nilainya#

SHOW STATUS menampilkan penghitung dan indikator kerja server, dengan lingkup SESSION untuk koneksi saat ini dan GLOBAL untuk seluruh server sejak terakhir dihidupkan. Nilai yang tampil tidak semuanya sama sifatnya: sebagian tetap, seperti ukuran halaman InnoDB, sebagian berubah tiap saat, seperti jumlah byte yang diterima.

bash 
# membaca indikator yang nilainya tetap
mysql -u root -e "SHOW GLOBAL STATUS LIKE 'Innodb_page_size';"
mysql -u root -e "SHOW SESSION STATUS LIKE 'Compression';"
text Keluaran 
Variable_name	Value
Innodb_page_size	16384
Variable_name	Value
Compression	OFF

Kedua keluaran di atas aman dikutip karena nilainya tidak berubah antarwaktu, sehingga cocok untuk laporan dan untuk skrip pengujian. Pemantauan rutin justru menarik nilai yang berubah, seperti jumlah koneksi atau byte lalu lintas, dan contoh polanya tampak seperti berikut.

SHOW STATUS perlu dibedakan dari SHOW VARIABLES yang dibahas pada topik Dasar Konfigurasi. SHOW VARIABLES menampilkan pengaturan yang menentukan perilaku server dan nilainya tetap sampai diubah, sedangkan SHOW STATUS menampilkan hasil kerja server yang menumpuk seiring waktu. Kesalahan membaca keduanya membuat diagnosis menyesatkan, misalnya mengutip penghitung sebagai pengaturan atau sebaliknya.

sql Penghitung yang nilainya berubah tiap saat 
-- tidak-dijalankan
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Bytes_received';

Melihat koneksi yang sedang berjalan#

Perintah SHOW PROCESSLIST menampilkan satu baris untuk setiap koneksi yang hidup di server. Bentuk lengkapnya, SHOW FULL PROCESSLIST, menambahkan kolom Info yang memuat query yang sedang dieksekusi, dan bentuk inilah yang dipakai untuk mencari koneksi bermasalah.

sql Bentuk lengkap daftar proses 
-- tidak-dijalankan
SHOW FULL PROCESSLIST;

Keluarannya berupa tabel berkolom Id, User, Host, db, Command, Time, State, dan Info. Nilai Id dan Time berubah sepanjang waktu sehingga tidak pernah cocok untuk ditempel sebagai keluaran tetap. Kolom Command menunjukkan apa yang sedang dilakukan koneksi: Query berarti sedang menjalankan pernyataan, Sleep berarti terbuka tetapi menganggur menunggu perintah berikutnya, dan Binlog Dump menandakan koneksi replikasi dari sebuah replica. Untuk keperluan yang membutuhkan keluaran stabil, baris koneksi sendiri dapat dibaca melalui information_schema dengan filter pada id koneksi saat ini.

bash 
# membaca baris koneksi sendiri secara deterministik
mysql -t -u root -e "SELECT user, command FROM information_schema.processlist WHERE id = CONNECTION_ID();"
text Keluaran 
+------+---------+
| user | command |
+------+---------+
| root | Query   |
+------+---------+

Koneksi yang tersangkut pada pernyataan berat dapat dihentikan dari luar dengan KILL id_koneksi, yang menghentikan koneksi tersebut, atau KILL QUERY id_koneksi, yang hanya membatalkan pernyataan yang sedang berjalan dan membiarkan koneksi tetap terbuka. Keduanya memerlukan hak proses atas koneksi yang dituju, sehingga operasi ini biasanya menjadi ranah akun administratif.

Mengenal performance_schema#

performance_schema adalah skema bawaan yang merekam peristiwa eksekusi secara terstruktur: pernyataan, tunggu sumber daya (wait), transaksi, dan tahap eksekusi, lengkap dengan waktu dan jumlah kejadiannya. Skema ini dikelola server secara internal, tidak menyimpan data pengguna, dan biaya rekamnya diatur supaya tetap ringan.

bash 
# memeriksa status performance_schema dan luas cakupannya
mysql -t -u root <<'SQL'
SHOW VARIABLES LIKE 'performance_schema';
SELECT COUNT(*) AS jumlah_tabel FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'performance_schema';
SELECT NAME FROM performance_schema.setup_consumers ORDER BY NAME;
SQL
text Keluaran 
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+
+--------------+
| jumlah_tabel |
+--------------+
|          111 |
+--------------+
+----------------------------------+
| NAME                             |
+----------------------------------+
| events_stages_current            |
| events_stages_history            |
| events_stages_history_long       |
| events_statements_cpu            |
| events_statements_current        |
| events_statements_history        |
| events_statements_history_long   |
| events_transactions_current      |
| events_transactions_history      |
| events_transactions_history_long |
| events_waits_current             |
| events_waits_history             |
| events_waits_history_long        |
| global_instrumentation           |
| statements_digest                |
| thread_instrumentation           |
+----------------------------------+

Jumlah tabel pada server latihan ini adalah 111 dan dapat berbeda antarversi, tetapi statis untuk satu versi tertentu. Daftar setup_consumers memperlihatkan sisi rekamnya: baris berawalan events_ adalah kumpulan peristiwa yang masing-masing dapat dinyalakan atau dimatikan lewat tabel setup_consumers, sedangkan statements_digest meringkas pernyataan berdasarkan bentuknya tanpa nilai literal. Perkakas yang terekam ditentukan oleh tabel setup_instruments yang berisi lebih dari seribu jenis peristiwa pada versi ini.

Pemakaian paling sehari-hari dimulai dari tabel events_statements_summary_by_digest, yang mengurutkan bentuk pernyataan berdasarkan total waktu eksekusi dan jumlah eksekusinya, sehingga query yang paling banyak membebani server dapat disebutkan dengan bukti angka. Skema bernama sys yang juga terpasang bawaan membangun view yang mudah dibaca di atas performance_schema untuk kebutuhan yang sama.

Kesalahan umum#

Kesalahan pertama adalah membaca Command = Sleep sebagai tanda masalah. Sleep berarti koneksi terbuka tanpa pekerjaan, dan sejumlah koneksi menganggur adalah wajar pada aplikasi yang memakai connection pool. Yang perlu diwaspadai adalah jumlahnya yang menumpuk tanpa batas karena koneksi tidak pernah ditutup oleh aplikasi.

Kesalahan kedua adalah membandingkan penghitung global antarwaktu tanpa mencatat intervalnya. Nilai seperti Bytes_received berlaku sejak server hidup, sehingga angka mentahnya tak bermakna tanpa selisih antardua pembacaan. Praktik yang benar adalah mencatat dua nilai dan membagi selisihnya dengan selang waktunya.

Kesalahan ketiga adalah menyalakan seluruh konsumen performance_schema karena menganggap lebih banyak rekam berarti lebih baik. Konsumen seperti events_waits_history_long menambah kerja pencatatan pada setiap peristiwa, dan untuk diagnosa sehari-hari konsumen pernyataan saja sudah menjawab sebagian besar pertanyaan beban kerja.

Ringkasan#

  • SHOW STATUS menampilkan indikator dengan lingkup SESSION dan GLOBAL, dan nilai yang dipilih perlu dibedakan antara yang tetap dan yang berubah tiap saat.
  • PROCESSLIST memperlihatkan koneksi aktif beserta Command-nya, sedangkan kolom Id dan Time selalu berubah sehingga tidak pernah cocok untuk ditempel sebagai keluaran tetap.
  • Koneksi bermasalah dihentikan dengan KILL untuk seluruh koneksi atau KILL QUERY untuk pernyataannya saja.
  • performance_schema merekam peristiwa eksekusi di bawah kendali tabel setup_consumers dan setup_instruments, dengan tabel ringkasan digest sebagai titik masuk diagnosa beban.

Referensi#