Hologres：FAQ Metrik Pemantauan

Koneksi mencakup jumlah total koneksi SQL dalam suatu instans, termasuk koneksi aktif dan idle dari Java Database Connectivity (JDBC) atau PSQL. Jumlah koneksi maksimum suatu instans biasanya bergantung pada spesifikasi instans tersebut. Jika jumlah koneksi melebihi batas maksimum atau Anda mengalami error berikut:

• Error FATAL: sorry, too many clients already connection limit exceeded for superusers.

• Error FATAL: remaining connection slots are reserved for non-replication superuser connections.

hal ini menunjukkan bahwa instans telah mencapai batas koneksi. Anda dapat melihat koneksi saat ini melalui HoloWeb atau menggunakan SQL. Untuk informasi selengkapnya, lihat Connection management. Gunakan akun superuser untuk Kill koneksi yang tidak diharapkan atau idle.

Latensi kueri tinggi umumnya disebabkan oleh beberapa faktor. Pertama, identifikasi pernyataan SQL lambat melalui log kueri lambat, lalu atasi masalah berdasarkan skenario berikut. Untuk informasi selengkapnya, lihat View and analyze slow query logs.

• Latensi kueri tinggi karena queries per second (QPS) rendah tetapi pernyataan SQL kompleks.

  Solusi: Optimalkan pernyataan SQL dan buat indeks yang sesuai untuk meningkatkan performa kueri. Untuk informasi selengkapnya, lihat Optimize query performance dan Optimize the query performance of MaxCompute foreign tables.

• Latensi kueri tinggi karena QPS kueri tinggi.

  Solusi: Jika pernyataan SQL sudah dioptimalkan tetapi Anda memerlukan QPS lebih tinggi dan latensi lebih rendah, lakukan scale out instans. Sumber daya tambahan akan meningkatkan performa. Untuk informasi selengkapnya, lihat Upgrade an instance.

• Latensi kueri tinggi karena banyak operasi write terjadi selama kueri, yang memengaruhi performa kueri.

  Solusi: Jika operasi write memengaruhi performa kueri, lakukan langkah-langkah berikut.

  • Lakukan operasi write selama jam non-puncak kueri untuk mengurangi dampak terhadap kueri.

  • Kurangi konkurensi write untuk meningkatkan efisiensi kueri. Jika Anda menulis ke tabel eksternal, gunakan parameter berikut untuk mengurangi konkurensi.

    -- Setel konkurensi maksimum untuk eksekusi MaxCompute. Nilai default adalah 128. Atur ke nilai yang lebih kecil untuk mencegah satu kueri memengaruhi kueri lain dan menyebabkan error sistem.
    set hg_experimental_foreign_table_executor_max_dop = 32; -- Pengaturan yang direkomendasikan
    
    -- Sesuaikan ukuran batch untuk setiap pembacaan dari tabel MaxCompute. Nilai default adalah 8192.
    set hg_experimental_query_batch_size = 1024;
    
    -- Baca langsung file ORC.
    set hg_experimental_enable_access_odps_orc_via_holo = on;
    
    -- Atur ukuran split untuk mengakses tabel MaxCompute. Ini menyesuaikan jumlah task konkuren. Nilai default adalah 64 MB. Tingkatkan nilai ini untuk tabel besar agar mencegah terlalu banyak split yang memengaruhi performa.
    set hg_experimental_foreign_table_split_size = 512MB;

Namun, dalam beberapa kasus, penggunaan memori dapat terus meningkat hingga mendekati 80%. Penyebab utamanya sebagai berikut:

• Jumlah tabel dan volume data total meningkat, sehingga skala data jauh melebihi spesifikasi komputasi saat ini. Penggunaan memori berkorelasi positif dengan jumlah metadata dan indeks. Dengan demikian, lebih banyak tabel, volume data yang lebih besar, serta lebih banyak indeks akan menyebabkan penggunaan memori lebih tinggi.

• Indeks tidak dikonfigurasi dengan tepat. Misalnya, sebuah tabel memiliki banyak kolom, sebagian besar bertipe TEXT, dan terlalu banyak indeks bitmap atau dictionary yang diaktifkan. Dalam kasus ini, pertimbangkan untuk menghapus beberapa indeks bitmap atau dictionary. Untuk informasi selengkapnya, lihat ALTER TABLE.

Oleh karena itu, jika penggunaan memori tetap mendekati 80% dalam waktu lama, pertimbangkan tindakan berikut.

• Hapus data yang tidak lagi dikueri untuk melepaskan memori yang ditempati oleh metadata.

• Atur indeks yang sesuai. Jika indeks bitmap dan dictionary tidak digunakan dalam skenario bisnis Anda, Anda dapat menghapusnya. Namun, jangan hapus secara langsung tanpa analisis spesifik terhadap kebutuhan bisnis Anda.

• Tingkatkan sumber daya komputasi dan penyimpanan instans. Rekomendasi untuk upgrade sebagai berikut:

  • Skenario umum: Jika Anda dapat mentolerir latensi dari pembacaan data dari disk dan persyaratan waktu respons tidak ketat, 1 CU (1 Core + 4 GB memori) dapat mendukung penyimpanan data 50 GB hingga 100 GB.

  • Skenario serving dengan persyaratan waktu respons rendah: Untuk performa optimal, semua data hot spot untuk kueri harus berada dalam cache memori. Secara default, cache menempati 30% dari total memori. Pada instans 1 CU (1 Core + 4 GB memori), 1,3 GB digunakan untuk cache data. Sebagian cache ini juga digunakan oleh metadata tabel. Misalnya, dalam skenario latensi rendah dengan data hot spot 100 GB, Anda memerlukan setidaknya 100 GB cache yang tersedia. Setelah data dibaca dan didekompresi, data tersebut akan menempati lebih dari 100 GB memori. Oleh karena itu, Anda memerlukan setidaknya 320 GB memori, yang berarti Anda memerlukan minimal 96 CU sumber daya komputasi.

Jika penggunaan CPU instans Hologres tetap mendekati 100% dalam waktu lama (misalnya, 100% selama 3 jam berturut-turut atau di atas 90% selama 12 jam berturut-turut), hal ini menunjukkan beban instans yang sangat tinggi dan kemungkinan besar sumber daya CPU telah menjadi bottleneck sistem. Anda perlu menganalisis skenario bisnis dan kueri Anda untuk menentukan penyebabnya. Diagnosis dapat dilakukan dari aspek-aspek berikut.

• Diagnosis 1: Peningkatan signifikan dalam QPS atau RPS.

  Bandingkan metrik pemantauan QPS dan RPS sebelum dan sesudah peningkatan penggunaan CPU. Jika terdapat tren peningkatan yang jelas yang menyebabkan penggunaan CPU naik, lanjutkan dengan solusi berikut.

  Solusinya sebagai berikut.

  • Jika operasi select menyebabkan penggunaan CPU meningkat, gunakan log kueri lambat untuk mengidentifikasi kueri yang berjalan lama dan optimalkan kueri tersebut.

  • Jika eksekusi operasi insert, update, atau delete menyebabkan peningkatan penggunaan CPU, periksa log kueri lambat untuk menentukan apakah kueri tidak menggunakan Fixed Plan, seperti yang ditunjukkan dalam SQL berikut. Perintah insert, update, atau delete yang tidak menggunakan Fixed Plan akan mengunci tabel. Kueri konkuren kemudian menyebabkan lock waits. Anda dapat mengevaluasi dari perspektif logika bisnis apakah pernyataan SQL dapat ditulis ulang untuk menggunakan Fixed Plan guna menghindari lock tabel dan mengurangi penggunaan CPU.

    -- Contoh: Lihat operasi insert/update/delete yang tidak menggunakan Fixed Plan dalam 3 jam terakhir.
    select *
    from hologres.hg_query_log
    where query_start >= now() - interval '3 h'
        and command_tag in ('INSERT','UPDATE','DELETE')
        and 'HQE'=ANY(engine_type)
    order by query_start desc limit 500;

  • Jika semua pernyataan SQL sudah dioptimalkan tetapi penggunaan CPU masih tinggi, sumber daya instans telah mencapai bottleneck. Anda dapat melakukan scale out instans atau men-deploy beberapa instans dengan shared storage untuk menerapkan read/write splitting. Untuk informasi selengkapnya, lihat Upgrade an instance atau Deploy primary and secondary instances for read/write splitting (shared storage).

• Diagnosis 2: Tidak ada peningkatan signifikan dalam QPS atau RPS, tetapi terdapat kueri yang berjalan lama.

  Jika metrik pemantauan menunjukkan tidak ada peningkatan signifikan dalam QPS atau RPS, tetapi penggunaan CPU tiba-tiba meningkat dan tetap tinggi, periksa metrik Running Query Duration untuk mengidentifikasi kueri yang berjalan lama. Jika metrik menunjukkan kueri yang berjalan lebih dari setengah jam atau satu jam, kueri tersebut adalah penyebab penggunaan CPU tinggi. Gunakan perintah berikut untuk menemukan kueri aktif dan menghentikannya guna mengurangi penggunaan CPU.

  -- Lihat kueri yang berjalan lama.
  SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
      FROM pg_stat_activity
      WHERE state != 'idle'
      order by 1 desc;
  
  -- Batalkan kueri.
  select pg_cancel_backend(<pid>);

• Diagnosis 3: Tidak ada peningkatan signifikan dalam QPS atau RPS, tetapi terdapat kueri yang mengonsumsi CPU tinggi.

  Jika metrik pemantauan menunjukkan tidak ada peningkatan signifikan dalam QPS atau RPS, tetapi penggunaan CPU tiba-tiba meningkat dan tetap tinggi, gunakan perintah berikut untuk menemukan kueri yang mengonsumsi CPU tinggi dalam log kueri lambat. Hal ini membantu Anda mengidentifikasi operasi yang mengonsumsi CPU dan mengoptimalkan pernyataan SQL.

  -- Kueri untuk kueri konsumsi tinggi dalam 3 jam terakhir.
  select status as "Status",
  duration as "Duration (ms)",
  query_start as "Start Time",
  (read_bytes/1048576)::text || ' MB' as "Read Volume",
  (memory_bytes/1048576)::text || ' MB' as "Memory",
  (shuffle_bytes/1048576)::text || ' MB' as "Shuffle",
  (cpu_time_ms/1000)::text || ' s' as "CPU Time",
  physical_reads as "Disk Reads",
  query_id as "QueryID",
  query
  from hologres.hg_query_log
  where query_start > current_timestamp - interval'3 h'
  and command_tag in ('SELECT','INSERT','UPDATE','DELETE')
  and duration > 1000
  order by duration desc,
  read_bytes desc,
  shuffle_bytes desc,
  memory_bytes desc,
  cpu_time_ms desc,
  physical_reads desc
  limit 500;

• Diagnosis 4: Pernyataan SQL PQE menyebabkan penggunaan CPU mencapai 100%.

  Jika metrik pemantauan menunjukkan tidak ada peningkatan signifikan dalam QPS atau RPS, gunakan perintah SQL berikut untuk memeriksa log kueri lambat guna mencari pernyataan SQL PQE baru yang mungkin menyebabkan peningkatan penggunaan CPU. Jika terdapat pernyataan SQL PQE, optimalkan operator dalam SQL yang menggunakan engine PQE. Untuk informasi selengkapnya, lihat Optimize query performance.

  -- Kueri untuk kueri yang menggunakan engine PQE dalam 3 jam terakhir.
  select *
  from hologres.hg_query_log
  where query_start > current_timestamp - interval'3 h'
      and 'PQE'=ANY(engine_type)
  order by query_start desc limit 500;

• Diagnosis 5: Indeks bitmap atau dictionary tabel telah dimodifikasi.

  Memodifikasi indeks bitmap atau dictionary tabel memicu proses kompaksi latar belakang asinkron, yang mengonsumsi sebagian sumber daya CPU. Penggunaan penyimpanan instans mungkin terlebih dahulu meningkat lalu menurun. Gunakan perintah SQL berikut untuk memeriksa log kueri lambat guna mencari catatan modifikasi indeks.

  -- Kueri untuk catatan modifikasi indeks dalam 3 jam terakhir.
  select *
  from hologres.hg_query_log
  where query_start >= now() - interval '3 h'
  and command_tag in ('CALL')
  order by query_start desc limit 500;

Metrik Running Query Duration menunjukkan kueri yang berjalan lama, misalnya kueri dengan waktu proses lebih dari 1 jam. Saat kueri yang berjalan lama muncul, buka halaman Active Query Tasks untuk melihat kueri yang sedang berjalan. Untuk informasi selengkapnya, lihat Manage queries. Kueri yang berjalan lama biasanya terjadi dalam situasi berikut. Lakukan diagnosis berdasarkan skenario Anda.

• Skenario 1: Instans memiliki operasi write yang berjalan lama.

  Solusi: Periksa metrik Real-time Write RPS untuk melihat apakah terdapat task write berkelanjutan yang menyebabkan waktu proses kueri menjadi lama.

• Skenario 2: Idle in transaction.

  • Sebuah client membuka transaksi dan melakukan operasi DDL tetapi tidak melakukan commit. Gunakan perintah SQL berikut untuk memeriksa status kueri aktif. Status kueri ditampilkan sebagai idle in transaction dan waktu prosesnya lama.

    -- Lihat kueri yang berjalan lama.
    SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
        FROM pg_stat_activity
        WHERE state != 'idle'
        order by 1 desc;

  • Kueri macet karena lock waits atau alasan lain, sehingga berjalan lama.

  Solusi: Gunakan contoh SQL berikut untuk menemukan kueri yang berjalan lama. Jika waktu proses yang lama disebabkan oleh idle in transaction, tutup transaksi di client atau atur timeout transaksi idle yang sesuai. Untuk informasi selengkapnya, lihat Modify the idle query timeout.

  -- Lihat kueri yang berjalan lama.
  SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
      FROM pg_stat_activity
      WHERE state != 'idle'
      order by 1 desc;
  
  -- Superuser membatalkan kueri.
  select pg_cancel_backend(<pid>);

• Skenario 3: Kueri melibatkan SQL kompleks dan menggunakan engine PQE.

  Solusi: Gunakan perintah berikut untuk menemukan kueri yang sedang berjalan dan berjalan lama. Kemudian, gunakan rencana eksekusi (`explain sql`) untuk memeriksa apakah ada pernyataan SQL yang menggunakan engine PQE (rencana eksekusi berisi External SQL (Postgres)), yang menyebabkan waktu eksekusi lama.

  -- Lihat kueri yang berjalan lama.
  SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
      FROM pg_stat_activity
      WHERE state != 'idle'
      order by 1 desc;
  
  -- Lihat rencana eksekusi kueri.
  explain sql

  • Gunakan akun superuser untuk menghentikan kueri yang berjalan lama.

  • Optimalkan operator dalam pernyataan SQL yang menggunakan engine PQE. Untuk informasi selengkapnya, lihat Optimize query performance.

• Skenario 4: Eksekusi DDL konkuren menyebabkan lock contention.

  Operasi DDL konkuren mengunci tabel, yang menyebabkan lock contention dan lock waits, sehingga menghasilkan waktu proses yang lama.

  Solusi:

  • Gunakan perintah berikut untuk memeriksa apakah ada operasi DDL yang sedang berlangsung dan hentikan untuk melepaskan lock.

    SELECT datname::text,usename,query,pid::text,state
       FROM pg_stat_activity
       WHERE state != 'idle' ;

  • Jalankan operasi DDL secara berurutan.

Di Hologres, partisi data (shard) menentukan cara data didistribusikan. Sebuah worker dapat mengakses data dari satu atau beberapa shard selama komputasi. Dalam instans yang sama, satu shard hanya dapat diakses oleh satu worker dalam satu waktu. Jika worker yang berbeda dalam suatu instans mengakses jumlah shard yang tidak sama, beban yang tidak merata pada sumber daya worker dapat terjadi. Penyebab utamanya sebagai berikut:

• Alasan 1: Terdapat kesenjangan data (data skew).

  Jika terdapat kesenjangan data yang parah, beban worker akan terkonsentrasi pada shard tertentu, sehingga menyebabkan beban CPU tidak merata.

  Solusi: Gunakan pernyataan berikut untuk memeriksa kesenjangan data. Dalam hasil contoh, jumlah untuk satu shard jauh lebih besar daripada yang lain, menunjukkan adanya kesenjangan data. Tangani data yang miring atau atur kunci distribusi yang sesuai sesuai kebutuhan. Untuk informasi selengkapnya, lihat Optimize query performance.

  select hg_shard_id,count(1) from <table_name> group by hg_shard_id;
  
  -- Hasil contoh: Jumlah untuk shard 39 besar, menunjukkan kesenjangan.
  hg_shard_id | count
  -------------+--------
            53 |  29130
            65 |  28628
            66 |  26970
            70 |  28767
            77 |  28753
            24 |  30310
            15 |  29550
            39 | 164983

• Alasan 2: Jumlah shard yang diatur untuk instans bukan kelipatan bulat dari jumlah worker.

  Ketika jumlah shard dalam kelompok tabel bukan kelipatan bulat dari jumlah total worker dalam instans, jumlah shard yang dialokasikan ke worker yang berbeda menjadi tidak sama, sehingga menyebabkan beban yang tidak merata.

  Solusi: Atur jumlah shard yang sesuai berdasarkan spesifikasi instans. Untuk informasi selengkapnya, lihat Manage table groups and shard counts. Situasi ini biasanya terjadi pada instans spesifikasi besar (lebih dari 256 core). Untuk instans spesifikasi kecil, Anda dapat menggunakan jumlah shard default.

• Alasan 3: Distribusi shard tidak merata setelah failover worker.

  Ketika sebuah worker dihentikan (killed) karena error kehabisan memori (OOM) atau alasan lain, sistem dengan cepat memigrasikan shard dari worker tersebut ke worker lain untuk segera memulihkan kueri. Ketika worker yang dihentikan tersebut dijalankan ulang, sistem mengalokasikan kembali beberapa shard kepadanya, yang dapat menyebabkan distribusi shard yang tidak merata di antara worker.

  Solusi: Jika beban instans rendah, Anda dapat mengabaikan distribusi beban yang tidak merata ini. Jika beban instans tinggi, restart instans untuk mendistribusikan ulang sumber daya shard secara merata.