MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Seberapa Performa Node ProxySQL Anda?

ProxySQL telah mendapatkan banyak minat saat ini di dunia database MySQL dan MariaDB, belum lagi ClickHouse yang membantu mendukung ProxySQL.

Dapat dikatakan bahwa ProxySQL telah menjadi proxy database default untuk keluarga database MySQL (seperti Server Percona, Oracle MySQL, Galera Cluster atau bahkan dengan MariaDB).

ProxySQL, pada kenyataannya, adalah pemecah masalah yang efisien dengan fungsionalitas yang sangat kaya yang mengelola komunikasi database klien-server; bertindak sebagai middleware dalam pendekatan yang sangat maju dan berkinerja.

Ini memungkinkan kemampuan untuk membentuk lalu lintas basis data dengan menunda, menyimpan, atau menulis ulang kueri dengan cepat. Ini juga dapat digunakan untuk membuat lingkungan di mana failover tidak akan memengaruhi aplikasi dan akan transparan bagi mereka. Komunitas ProxySQL sangat responsif dan terus-menerus membuat perbaikan, patch, dan rilis versi secara tepat waktu.

Tetapi seberapa baik kinerja penyiapan ProxySQL Anda, dan bagaimana Anda dapat menentukan bahwa penyiapan Anda telah disetel dengan benar? Blog ini berfokus untuk menentukan performa node ProxySQL Anda dan cara memantaunya secara efisien.

Masalah Umum yang Dapat Anda Hadapi Dengan ProxySQL

Penginstalan default ProxySQL dilengkapi dengan alat penyetelan ringan dan sederhana yang mampu menangani beban rata-rata hingga berat. Meskipun hal ini dapat bergantung pada jenis kueri yang dikirim ke middleware, hal ini dapat berdampak dan mulai mengalami kemacetan dan latensi.

Masalah Latensi

Misalnya, apa yang dapat menyebabkan masalah latensi mungkin sulit ditentukan jika Anda tidak memiliki sistem pemantauan. Demikian juga, Anda dapat secara manual memantau atau memeriksa skema statistik seperti di bawah ini:

mysql> select * from stats_mysql_connection_pool\G

*************************** 1. row ***************************

        hostgroup: 20

         srv_host: 192.168.10.225

         srv_port: 3306

           status: ONLINE

         ConnUsed: 0

         ConnFree: 0

           ConnOK: 0

          ConnERR: 0

      MaxConnUsed: 0

          Queries: 0

Queries_GTID_sync: 0

  Bytes_data_sent: 0

  Bytes_data_recv: 0

       Latency_us: 1151

*************************** 2. row ***************************

        hostgroup: 20

         srv_host: 192.168.10.226

         srv_port: 3306

           status: ONLINE

         ConnUsed: 0

         ConnFree: 0

           ConnOK: 0

          ConnERR: 0

      MaxConnUsed: 0

          Queries: 0

Queries_GTID_sync: 0

  Bytes_data_sent: 0

  Bytes_data_recv: 0

       Latency_us: 470

*************************** 3. row ***************************

        hostgroup: 10

         srv_host: 192.168.10.227

         srv_port: 3306

           status: ONLINE

         ConnUsed: 0

         ConnFree: 0

           ConnOK: 0

          ConnERR: 0

      MaxConnUsed: 0

          Queries: 0

Queries_GTID_sync: 0

  Bytes_data_sent: 0

  Bytes_data_recv: 0

       Latency_us: 10855

*************************** 4. row ***************************

        hostgroup: 40

         srv_host: 192.168.10.225

         srv_port: 3306

           status: ONLINE

         ConnUsed: 0

         ConnFree: 0

           ConnOK: 0

          ConnERR: 0

      MaxConnUsed: 0

          Queries: 0

Queries_GTID_sync: 0

  Bytes_data_sent: 0

  Bytes_data_recv: 0

       Latency_us: 1151

*************************** 5. row ***************************

        hostgroup: 40

         srv_host: 192.168.10.226

         srv_port: 3306

           status: ONLINE

         ConnUsed: 0

         ConnFree: 0

           ConnOK: 0

          ConnERR: 0

      MaxConnUsed: 0

          Queries: 0

Queries_GTID_sync: 0

  Bytes_data_sent: 0

  Bytes_data_recv: 0

       Latency_us: 470

5 rows in set (0.01 sec)

Ini memungkinkan Anda memantau latensi berdasarkan grup host. Tapi itu menambah kerumitan kecuali Anda harus berinovasi dan mengembangkan skrip yang akan berhasil memberi tahu Anda.

Kesalahan Koneksi Klien

Waktu habis koneksi maksimum karena koneksi maksimum di backend (node ​​basis data itu sendiri) dapat membuat Anda bingung jika Anda tidak dapat menentukan apa sumber utama masalahnya. Anda dapat memeriksa basis data statistik untuk memeriksa koneksi yang dibatalkan seperti itu di klien atau bahkan server dan koneksi ditolak sebagai berikut,

mysql> select * from stats.stats_mysql_global where variable_name like '%connect%';

+-------------------------------------+----------------+

| Variable_Name                       | Variable_Value |

+-------------------------------------+----------------+

| Client_Connections_aborted          | 0 |

| Client_Connections_connected        | 205 |

| Client_Connections_created          | 10067 |

| Server_Connections_aborted          | 44 |

| Server_Connections_connected        | 30 |

| Server_Connections_created          | 14892 |

| Server_Connections_delayed          | 0 |

| Client_Connections_non_idle         | 205 |

| Access_Denied_Max_Connections       | 0 |

| Access_Denied_Max_User_Connections  | 0 |

| MySQL_Monitor_connect_check_OK      | 41350 |

| MySQL_Monitor_connect_check_ERR     | 92 |

| max_connect_timeouts                | 0 |

| Client_Connections_hostgroup_locked | 0              |

| mysql_killed_backend_connections    | 0 |

+-------------------------------------+----------------+

15 rows in set (0.01 sec)

Ini juga ideal jika Anda dapat memverifikasi dan memeriksa jumlah maksimum koneksi pengguna backend untuk melihat berapa jumlah batas koneksi yang dapat dibuka atau digunakan. Misalnya, saya memiliki yang berikut ini dalam pengujian saya,

mysql> select username, active, transaction_persistent, max_connections from mysql_users;

+---------------+--------+------------------------+-----------------+

| username      | active | transaction_persistent | max_connections |

+---------------+--------+------------------------+-----------------+

| proxydemo     | 1 | 1                   | 10000 |

| proxysql-paul | 1      | 1 | 10000           |

+---------------+--------+------------------------+-----------------+

2 rows in set (0.00 sec)

Permintaan Lambat

Mengidentifikasi kueri yang lambat tidak terlalu sulit di ProxySQL, tetapi dapat menjadi tidak efisien jika dilakukan secara manual. Anda dapat memeriksa ini jika melakukan manual dengan variabel,

mysql> select * from stats_mysql_global where  variable_name like '%slow%';

+---------------+----------------+

| Variable_Name | Variable_Value |

+---------------+----------------+

| Slow_queries  | 2 |

+---------------+----------------+

1 row in set (0.00 sec)

Meskipun itu dapat memberi Anda beberapa angka, Anda dapat memeriksa tabel stats_mysql_query_digest di bawah skema statistik jika Anda ingin menggali lebih dalam. Misalnya di bawah ini,

mysql> select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text

    -> from stats_mysql_query_digest

    -> where count_star > 100 order by average_time_ms desc limit 10;

+------------+----------+-----------------+--------------------------------------+

| count_star | sum_time | average_time_ms | digest_text                          |

+------------+----------+-----------------+--------------------------------------+

| 884        | 15083961 | 17              | UPDATE sbtest1 SET k=k+? WHERE id=?  |

| 930        | 16000111 | 17              | UPDATE sbtest9 SET k=k+? WHERE id=?  |

| 914        | 15695810 | 17              | UPDATE sbtest4 SET k=k+? WHERE id=?  |

| 874        | 14467420 | 16              | UPDATE sbtest8 SET k=k+? WHERE id=?  |

| 904        | 15294520 | 16              | UPDATE sbtest3 SET k=k+? WHERE id=?  |

| 917        | 15228077 | 16              | UPDATE sbtest6 SET k=k+? WHERE id=?  |

| 907        | 14613238 | 16              | UPDATE sbtest2 SET k=k+? WHERE id=?  |

| 900        | 15113004 | 16              | UPDATE sbtest5 SET k=k+? WHERE id=?  |

| 917        | 15299381 | 16              | UPDATE sbtest7 SET k=k+? WHERE id=?  |

| 883        | 15010119 | 16              | UPDATE sbtest10 SET k=k+? WHERE id=? |

+------------+----------+-----------------+--------------------------------------+

10 rows in set (0.01 sec)

yang menangkap 10 kueri lambat teratas berdasarkan pengambilan sampel sebanyak 100. 

Utilisasi Memori

Item perangkat keras seperti CPU, Disk, dan Memori harus dipantau untuk memastikan kinerja ProxySQL Anda. Namun, hal yang paling penting adalah memori, karena ProxySQL akan banyak menggunakan memori karena mekanisme cache kueri. Secara default, cache kueri, yang bergantung pada variabel mysql-query_cache_size_MB default ke 256 Mib. Sehubungan dengan itu, ia dapat sampai pada situasi di mana ia menggunakan memori dan Anda perlu menentukan dan mendiagnosis jika Anda menemukan masalah dalam node ProxySQL Anda atau bahkan diketahui di dalam lapisan aplikasi.

Saat mengidentifikasi ini, Anda mungkin akan memeriksa tabel di stats_history dan skema stats. Anda dapat melihat daftar tabel yang dapat membantu Anda selama diagnosis,

mysql> show tables from stats;

| stats_memory_metrics                 |

19 rows in set (0.00 sec)

or,

mysql> show tables from stats_history;

+------------------------+

| tables                 |

+------------------------+

| mysql_connections      |

| mysql_connections_day  |

| mysql_connections_hour |

| mysql_query_cache      |

| mysql_query_cache_day  |

| mysql_query_cache_hour |

| system_cpu             |

| system_cpu_day         |

| system_cpu_hour        |

| system_memory          |

| system_memory_day      |

| system_memory_hour     |

+------------------------+

15 rows in set (0.00 sec)

Efisien Menentukan Kinerja ProxySQL Anda

Ada beberapa cara untuk menentukan kinerja node ProxySQL Anda. Menggunakan ClusterControl menawarkan Anda kemampuan untuk menentukan ini dengan grafik sederhana namun lugas. Misalnya, ketika ProxySQL terintegrasi ke dalam cluster Anda, Anda akan dapat menetapkan aturan kueri Anda, mengubah max_connections pengguna, menentukan kueri teratas, mengubah grup host pengguna, dan memberi Anda kinerja node ProxySQL Anda. Lihat tangkapan layar di bawah ini...

Yang Anda lihat hanyalah bukti betapa mahirnya ClusterControl dapat memberi Anda wawasan tentang kinerja node ProxySQL Anda. Tapi ini tidak membatasi Anda untuk itu. ClusterControl juga memiliki dasbor yang kaya dan kuat yang kami sebut SCUMM, yang mencakup dasbor Ikhtisar ProxySQL.

Jika Anda ingin menentukan kueri lambat, Anda cukup melihat ke dasbor. Memeriksa distribusi latensi Anda pada grup host yang berbeda tempat node backend Anda ditetapkan membantu Anda memiliki wawasan cepat tentang kinerja berdasarkan distribusi. Anda dapat memantau koneksi klien dan server, memberi Anda wawasan cache kueri. Yang terpenting dan tidak kalah pentingnya, ini memberi Anda pemanfaatan memori yang digunakan node ProxySQL. Lihat grafik di bawah ini...

Grafik ini adalah bagian dari dasbor yang membantu Anda menentukan dengan mudah kinerja node ProxySQL Anda.

ClusterControl tidak membatasi Anda saat berurusan dengan ProxySQL. Juga, ada fitur yang kaya di sini di mana Anda juga dapat mengambil cadangan atau mengimpor konfigurasi yang sangat penting ketika Anda berurusan dengan ketersediaan tinggi untuk node ProxySQL Anda.

Kesimpulan

Tidak pernah semudah ini untuk memantau dan menentukan apakah Anda memiliki masalah dengan ProxySQL Anda. Seperti dalam contoh blog ini, kami menampilkan ClusterControl sebagai alat yang dapat memberikan Anda efisiensi dan memberi Anda wawasan untuk menentukan masalah luar biasa yang Anda hadapi terkait masalah kinerja Anda.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Bagian 1:Klasifikasi Gambar dengan Server MariaDB dan TensorFlow – Gambaran Umum

  2. Bagaimana LOAD_FILE() Bekerja di MariaDB

  3. MariaDB RTRIM() vs RTRIM_ORACLE():Apa Bedanya?

  4. Dasar-dasar Enkripsi Database Server MariaDB

  5. Cara Memecahkan Masalah Basis Data MySQL