Kinerja MySQL:Mengidentifikasi Pertanyaan Panjang

Setiap aplikasi yang didukung MySQL dapat memperoleh manfaat dari server database yang disetel dengan baik. Tim Dukungan Heroik Web Cair telah menghadapi banyak situasi selama bertahun-tahun ketika beberapa penyesuaian kecil telah membuat perbedaan besar dalam kinerja situs web dan aplikasi. Dalam rangkaian artikel ini, kami telah menguraikan beberapa rekomendasi umum yang memiliki dampak terbesar pada performa.

Pemeriksaan Sebelum Penerbangan

Artikel ini berlaku untuk sebagian besar server VPS MySQL berbasis Linux. Ini termasuk, namun tidak terbatas pada, server Tradisional Dedicated dan Cloud VPS yang menjalankan berbagai distribusi Linux umum. Artikel dapat digunakan dengan jenis sistem Liquid Web berikut:

• CentOS 6x/7x yang dikelola inti
• Ubuntu 14.04/16.04 yang dikelola inti
• CPanel CentOS 6/7 yang dikelola sepenuhnya
• CentOS 7 Plesk Onyx 17 yang terkelola sepenuhnya
• Server Linux yang dikelola sendiri

Rangkaian artikel ini mengasumsikan keakraban dengan konsep dasar administrasi sistem berikut:

• Koneksi SSH dan navigasi dasar lingkungan shell baris perintah Linux standar.
• Membuka, Mengedit, dan Menyimpan file di Vim atau editor sistem yang dipilih.
• Mode interaktif MySQL dan sintaks kueri MySQL umum.

Apa itu Pengoptimalan MySQL?

Tidak ada definisi yang jelas untuk istilah Optimasi MySQL. Ini bisa berarti sesuatu yang berbeda bergantung pada orang,  administrator, grup, atau perusahaan. Untuk rangkaian artikel tentang Pengoptimalan MySQL ini, kami akan mendefinisikan Pengoptimalan MySQL sebagai: Konfigurasi server MySQL atau MariaDB yang telah dikonfigurasi untuk menghindari kemacetan yang biasa ditemui yang dibahas dalam rangkaian artikel ini.

Apa yang dimaksud dengan kemacetan?

Sangat mirip dengan leher pada botol soda, kemacetan sebagai istilah teknis adalah titik dalam konfigurasi aplikasi atau server di mana sejumlah kecil lalu lintas atau data dapat melewati tanpa masalah. Namun, volume yang lebih besar dari jenis lalu lintas atau data yang sama terhalang atau diblokir dan tidak dapat beroperasi dengan sukses apa adanya. Lihat contoh kemacetan konfigurasi berikut:

Dalam contoh ini, server mampu menangani 10 koneksi secara bersamaan. Namun, konfigurasi hanya menerima 5 koneksi. Masalah ini tidak akan muncul selama ada 5 atau lebih sedikit koneksi sekaligus. Namun, ketika lalu lintas meningkat hingga 10 koneksi, setengahnya mulai gagal karena sumber daya yang tidak digunakan dalam konfigurasi server. Contoh di atas mengilustrasikan bentuk bottleneck di mana ia mendapatkan namanya versus konfigurasi yang dioptimalkan yang mengoreksi bottleneck.

Kapan Saya Harus Mengoptimalkan database MySQL Saya?

Idealnya, penyetelan kinerja basis data harus dilakukan secara teratur dan sebelum produktivitas terpengaruh. Ini adalah perilaku praktik terbaik untuk melakukan audit kinerja database mingguan atau bulanan untuk mencegah masalah agar tidak berdampak buruk pada aplikasi. Gejala yang paling jelas dari masalah kinerja adalah:

• Kueri menumpuk dan tidak pernah selesai dalam tabel proses MySQL.
• Aplikasi atau situs web yang menggunakan database menjadi lamban.
• Kesalahan waktu koneksi habis, terutama selama jam sibuk.

Meskipun normal jika ada beberapa kueri serentak yang berjalan sekaligus pada sistem yang sibuk, ini menjadi masalah ketika kueri ini terlalu lama untuk diselesaikan secara teratur. Meskipun ambang batas spesifik bervariasi per sistem dan per aplikasi, waktu kueri rata-rata yang melebihi beberapa detik akan bermanifestasi sebagai pelambatan dalam situs web dan aplikasi yang dilampirkan. Perlambatan ini terkadang dapat dimulai dari yang kecil dan tidak diperhatikan hingga lonjakan lalu lintas yang besar mencapai hambatan tertentu.

Mengidentifikasi Masalah Kinerja

Mengetahui cara memeriksa tabel proses MySQL sangat penting untuk mendiagnosis hambatan spesifik yang dihadapi. Ada beberapa cara untuk melihat tabel proses tergantung pada server dan preferensi Anda. Untuk singkatnya, seri ini akan fokus pada metode paling umum yang digunakan melalui akses Secure Shell (SSH):

Metode 1. Menggunakan Tabel Proses MySQL

Gunakan 'mysqladmin ' alat baris perintah dengan tanda 'daftar proses ' atau 'proc ' Singkatnya. (Menambahkan tanda 'statistik ' atau 'stat ' singkatnya akan menampilkan statistik yang berjalan untuk kueri sejak MySQL terakhir kali dihidupkan ulang.)

Perintah:

mysqladmin proc stat

Keluaran:

 +-------+------+-----------+-----------+---------+------+-------+
 | Id    | User | Host      | db        | Command | Time | State | Info               | Progress |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 | 77255 | root | localhost | employees | Query   | 150  |       | call While_Loop2() | 0.000    |
 | 77285 | root | localhost |           | Query   | 0    | init  | show processlist   | 0.000    |
 +-------+------+-----------+-----------+---------+------+-------+--------------------+----------+
 Uptime: 861755  Threads: 2  Questions: 20961045  Slow queries: 0  Opens: 2976  Flush tables: 1  Open tables: 1011  Queries per second avg: 24.323

Metode 2:Menggunakan Tabel Proses MySQL

Jalankan kueri 'tampilkan daftar proses;' dari dalam prompt mode interaktif MySQL. (Amenambahkan ' penuh ’  pengubah perintah menonaktifkan pemotongan Info kolom. Ini diperlukan saat melihat kueri yang panjang.)

Perintah:

show processlist;

Keluaran:

MariaDB [(none)]> show full processlist;
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | Id    | User | Host      | db        | Command | Time | State | Info                  | Progress |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+
 | 77006 | root | localhost | employees | Query   |  151 | NULL  | call While_Loop2()    |    0.000 |
 | 77021 | root | localhost | NULL      | Query   |    0 | init  | show full processlist |    0.000 |
 +-------+------+-----------+-----------+---------+------+-------+-----------------------+----------+

Menggunakan log kueri lambat

Alat berharga lainnya di  MySQL adalah fitur pencatatan kueri lambat yang disertakan. Fitur ini adalah metode yang disukai untuk menemukan kueri yang berjalan lama secara teratur. Ada beberapa arahan yang tersedia untuk menyesuaikan fitur ini. Namun, pengaturan yang paling umum dibutuhkan adalah:

Arahan ini diatur dalam bagian [mysqld] dari file konfigurasi MySQL yang terletak di /etc/my.cnf dan akan memerlukan restart layanan MySQL sebelum berlaku. Lihat contoh di bawah untuk memformat:

[mysqld]
 log-error=/var/lib/mysql/mysql.err
 innodb_file_per_table=1
 default-storage-engine=innodb
 innodb_buffer_pool_size=128M
 innodb_log_file_size=128M
 max_connections=300
 key_buffer_size = 8M
 slow_query_log=1
 slow_query_log_file=/var/lib/mysql/slowquery.log
 long_query_time=5

Setelah log kueri lambat diaktifkan, Anda perlu menindaklanjutinya secara berkala untuk meninjau kueri yang sulit diatur yang perlu disesuaikan untuk kinerja yang lebih baik. Untuk menganalisis file log kueri lambat, Anda dapat menguraikannya secara langsung untuk meninjau isinya. Contoh berikut menunjukkan statistik untuk kueri sampel yang berjalan lebih lama dari 5 detik yang dikonfigurasi:

# Time: 180717  0:23:28
 # User@Host: root[root] @ localhost []
 # Thread_id: 32  Schema: employees  QC_hit: No
 # Query_time: 627.163085  Lock_time: 0.000021  Rows_sent: 0  Rows_examined: 0
 # Rows_affected: 0
 use employees;
 SET timestamp=1531801408;
 call While_Loop2();

Secara opsional, Anda dapat menggunakan alat baris perintah mysqldumpslow, yang mem-parsing file log kueri lambat dan mengelompokkan kueri seperti bersama-sama kecuali nilai data angka dan string:

~ $ mysqldumpslow -a /var/lib/mysql/slowquery.log
 Reading mysql slow query log from /var/lib/mysql/slowquery.log
 Count: 2  Time=316.67s (633s)  Lock=0.00s (0s)  Rows_sent=0.5 (1), Rows_examined=0.0 (0), Rows_affected=0.0 (0), root[root]@localhost
 call While_Loop2()

(Untuk informasi penggunaan, kunjungi dokumentasi MySQL di sini - mysqldumpslow — Meringkas File Log Kueri Lambat)

Kesimpulan

Jadi menyimpulkan bagian pertama dari seri Pengoptimalan Basis Data kami dan memberi kami dasar yang kuat untuk dirujuk untuk tujuan benchmark. Meskipun masalah basis data dapat menjadi rumit, seri kami akan menguraikan konsep-konsep ini untuk menyediakan sarana untuk mengoptimalkan basis data Anda melalui konversi basis data, konversi tabel, dan pengindeksan.

Bagaimana Kami Dapat Membantu?

Kami bangga menjadi Manusia Paling Bermanfaat di Hosting™!

Tim Dukungan kami diisi dengan teknisi Linux berpengalaman dan administrator sistem berbakat yang memiliki pengetahuan mendalam tentang berbagai teknologi hosting web, terutama yang dibahas dalam artikel ini.

Jika Anda memiliki pertanyaan tentang informasi ini, kami selalu tersedia untuk menjawab pertanyaan apa pun dengan masalah yang terkait dengan artikel ini, 24 jam sehari, 7 hari seminggu, 365 hari setahun.

Jika Anda adalah server VPS yang Dikelola Sepenuhnya, Cloud Dedicated, VMWare Private Cloud, server Private Parent, Server Cloud Terkelola, atau pemilik server Dedicated dan Anda merasa tidak nyaman melakukan salah satu langkah yang diuraikan, kami dapat dihubungi melalui telepon di @800.580.4985, chat atau tiket dukungan untuk membantu Anda dalam proses ini.