Hologres：FAQ Metrik

Metrik Koneksi menunjukkan jumlah total koneksi SQL ke instance Hologres, termasuk koneksi Java Database Connectivity (JDBC) ke database PostgreSQL dalam status aktif dan idle. Jumlah koneksi ke suatu instance bergantung pada tipe instance. Jika jumlah koneksi melebihi batas maksimum yang diizinkan atau salah satu kesalahan berikut dilaporkan, Anda perlu memeriksa kemungkinan kebocoran koneksi:

• FATAL: maaf, terlalu banyak klien sudah terhubung batas koneksi terlampaui untuk superuser

• FATAL: slot koneksi tersisa dicadangkan untuk koneksi superuser non-replikasi

Kesalahan ini menunjukkan bahwa jumlah koneksi telah mencapai batas atas. Informasi tentang koneksi saat ini dapat diperoleh melalui konsol HoloWeb atau dengan menjalankan pernyataan SQL. Untuk informasi lebih lanjut, lihat Kelola koneksi. Koneksi tak terduga atau idle dapat ditutup menggunakan akun superuser.

Latensi query tinggi dapat disebabkan oleh beberapa faktor berikut. Anda dapat mengidentifikasi query SQL lambat dengan memeriksa log query lambat. Untuk informasi lebih lanjut, lihat Kueri dan analisis log query lambat.

• Penyebab 1: Permintaan per detik (QPS) rendah, tetapi pernyataan SQL kompleks.

  Solusi: Optimalkan pernyataan SQL dan atur indeks yang sesuai untuk meningkatkan kinerja query. Untuk informasi lebih lanjut, lihat Optimalkan kinerja query dan Optimalkan kinerja query tabel MaxCompute di Hologres.

• Penyebab 2: QPS tinggi.

  Solusi: Jika QPS tinggi dan latensi tetap tinggi setelah optimasi SQL, tambahkan kapasitas instance untuk meningkatkan performa. Untuk informasi lebih lanjut, lihat Tingkatkan instance.

• Penyebab 3: Sejumlah besar data ditulis selama query.

  Solusi:

  • Tulis data selama jam-jam sepi untuk mengurangi dampak pada query.

  • Kurangi jumlah operasi tulis konkuren untuk meningkatkan efisiensi query. Jika Anda menulis data menggunakan tabel asing, jalankan pernyataan berikut untuk mengurangi konkurensi:

    -- Atur jumlah maksimum query yang ingin Anda lakukan pada satu waktu di MaxCompute. Nilai default: 128. Untuk mencegah satu query mempengaruhi query lainnya atau mencegah sistem menjadi tidak tersedia, kami sarankan Anda mengatur parameter ini ke nilai yang kecil.
    set hg_experimental_foreign_table_executor_max_dop = 32; -- Kami sarankan Anda mengatur parameter ini ke nilai yang kecil untuk mengurangi konkurensi.
    
    -- Atur jumlah entri data yang ingin Anda baca pada satu waktu dari tabel MaxCompute. Nilai default: 8192.
    set hg_experimental_query_batch_size = 1024;
    
    -- Baca data dari tabel ORC.
    set hg_experimental_enable_access_odps_orc_via_holo = on;
    
    -- Atur ukuran setiap shard tabel MaxCompute. Nilai default: 64. Unit: MB. Ukuran shard mempengaruhi konkurensi. Jika tabel berukuran besar, Anda dapat meningkatkan nilai parameter ini untuk mencegah shard berlebihan yang memburuk kinerja query.
    set hg_experimental_foreign_table_split_size = 512MB;

Dalam beberapa kasus, penggunaan memori dapat terus meningkat hingga mendekati 80%. Masalah penggunaan memori tinggi dapat disebabkan oleh beberapa faktor berikut:

• Kapasitas komputasi instance menjadi kewalahan karena jumlah tabel dan total ukuran data terus bertambah. Penggunaan memori meningkat secara proporsional dengan ukuran metadata dan jumlah indeks. Seiring dengan bertambahnya jumlah tabel, indeks, dan ukuran data, penggunaan memori juga bertambah.

• Pengaturan indeks tidak sesuai. Misalnya, sejumlah besar indeks bitmap dibuat, atau pengkodean kamus diaktifkan untuk tabel yang berisi sejumlah besar kolom tipe data TEXT. Dalam hal ini, modifikasi indeks bitmap atau properti pengkodean kamus tabel dapat membantu. Untuk informasi lebih lanjut, lihat ALTER TABLE.

Jika penggunaan memori tetap mendekati 80%, kami sarankan Anda melakukan langkah-langkah berikut:

• Hapus data yang tidak lagi di-query untuk melepaskan ruang memori yang ditempati oleh data seperti metadata.

• Atur indeks yang tepat. Anda dapat menghapus indeks bitmap yang tidak perlu atau menonaktifkan pengkodean kamus dalam skenario bisnis tertentu.

• Tingkatkan spesifikasi instance untuk meningkatkan sumber daya komputasi dan penyimpanan instance. Kami sarankan Anda meningkatkan instance berdasarkan skenario tertentu.

  • Dalam skenario di mana data disk dapat dibaca pada latensi tertentu dan waktu respons (RT) tidak ketat, pilih tipe instance yang sesuai berdasarkan ukuran data Anda. Satu unit komputasi (CU) yang mencakup 1 inti CPU dan 4 GB memori dapat mendukung penyimpanan data sebesar 50 GB hingga 100 GB.

  • Dalam skenario layanan yang memerlukan RT pendek, simpan semua data panas di memori. Secara default, cache mencakup 30% dari total memori. Dalam skenario seperti itu, 1,3 GB memori dari 1 CU digunakan untuk menyimpan data, dan metadata tabel disimpan dalam cache. Misalnya, dalam skenario yang memerlukan RT pendek, 100 GB data panas perlu disimpan di memori. Setelah data dibaca dan didekompresi, data tersebut memakan lebih dari 100 GB memori. Dalam hal ini, setidaknya 320 GB memori diperlukan, yang sesuai dengan setidaknya 96 CU.

Jika pemanfaatan CPU instance Hologres tetap mendekati 100%, instance tersebut berada di bawah beban berat. Misalnya, pemanfaatan CPU tetap 100% selama 3 jam berturut-turut atau tetap lebih dari 90% selama 12 jam berturut-turut. Dalam hal ini, sumber daya CPU menjadi hambatan bagi instance. Anda harus menganalisis skenario bisnis spesifik dan pernyataan query data untuk mengidentifikasi penyebab pemanfaatan CPU tinggi. Anda dapat mendiagnosis masalah ini berdasarkan kemungkinan penyebab berikut:

• Penyebab 1: QPS atau RPS meningkat signifikan.

  Bandingkan metrik QPS dan RPS sebelum dan sesudah masalah pemanfaatan CPU tinggi terjadi. Jika QPS atau RPS meningkat signifikan, ini adalah penyebab pemanfaatan CPU tinggi.

  Solusi:

  • Jika eksekusi pernyataan SELECT untuk query data menyebabkan masalah pemanfaatan CPU tinggi, Anda dapat melihat query lambat yang sesuai dengan memeriksa log query lambat dan mengoptimalkan query tersebut.

  • Jika eksekusi pernyataan INSERT, UPDATE, atau DELETE menyebabkan masalah pemanfaatan CPU tinggi, kami sarankan Anda memeriksa log query lambat dengan menjalankan pernyataan berikut untuk memeriksa apakah pernyataan INSERT, UPDATE, atau DELETE menggunakan rencana tetap. Jika rencana tetap tidak digunakan untuk mengeksekusi pernyataan INSERT, UPDATE, atau DELETE, tabel dikunci. Jika query dieksekusi secara bersamaan, terjadi tunggu kunci. Untuk mencegah penguncian tabel dan menurunkan pemanfaatan CPU, Anda dapat memeriksa apakah pernyataan SQL dapat dioptimalkan menggunakan rencana tetap berdasarkan kebutuhan bisnis Anda.

    -- Contoh: Query pernyataan INSERT, UPDATE, atau DELETE yang tidak dieksekusi menggunakan rencana tetap dalam satu 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 pernyataan SQL telah dioptimalkan, tetapi pemanfaatan CPU masih tinggi, sumber daya instance mencapai hambatan. Anda dapat menambah kapasitas instance atau menerapkan penyimpanan bersama pada beberapa instance untuk memungkinkan pemisahan baca/tulis. Untuk informasi lebih lanjut, lihat Tingkatkan instance atau Konfigurasikan pemisahan baca/tulis untuk instance utama dan sekunder (penyimpanan bersama).

• Penyebab 2: QPS atau RPS tidak meningkat signifikan, tetapi query jangka panjang ada.

  Data metrik menunjukkan bahwa QPS atau RPS tidak meningkat signifikan. Namun, pemanfaatan CPU tiba-tiba meningkat, dan masalah pemanfaatan CPU tinggi berlanjut selama periode waktu tertentu. Anda dapat melihat metrik Ongoing Query Duration untuk memeriksa query jangka panjang. Jika data metrik menunjukkan bahwa query yang berlangsung lebih dari setengah jam atau 1 jam ada, query ini menyebabkan masalah pemanfaatan CPU tinggi. Anda dapat menjalankan pernyataan berikut untuk melihat query jangka panjang dengan memeriksa query aktif dan menghentikan query tersebut. Ini menurunkan pemanfaatan CPU.

  -- Query query jangka panjang.
  SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
      FROM pg_stat_activity
      WHERE state != 'idle'
      order by 1 desc;
  
  -- Hentikan query jangka panjang.
  select pg_cancel_backend(<pid>);

• Penyebab 3: QPS atau RPS tidak meningkat signifikan, tetapi query yang mengonsumsi sejumlah besar sumber daya CPU ada.

  Data metrik menunjukkan bahwa QPS atau RPS tidak meningkat signifikan. Namun, pemanfaatan CPU tiba-tiba meningkat, dan masalah pemanfaatan CPU tinggi berlanjut selama periode waktu tertentu. Anda dapat menjalankan pernyataan berikut untuk melihat query dengan pemanfaatan CPU tinggi dengan memeriksa log query lambat, lalu optimalkan pernyataan SQL yang digunakan untuk query data.

  -- Query query lambat yang mengonsumsi sejumlah besar sumber daya CPU dalam 3 jam terakhir.
  select status as "Status",
  duration as "Waktu yang dikonsumsi (ms)",
  query_start as "Dimulai pada",
  (read_bytes/1048576)::text || ' MB' as "Bytes",
  (memory_bytes/1048576)::text || ' MB' as "Memori",
  (shuffle_bytes/1048576)::text || ' MB' as "Shuffle",
  (cpu_time_ms/1000)::text || ' s' as "Waktu CPU",
  physical_reads as "Baca fisik",
  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;

• Penyebab 4: Pemanfaatan CPU meningkat hingga 100% karena pernyataan SQL yang dieksekusi di PostgreSQL Query Engine (PQE).

  Jika data metrik menunjukkan bahwa QPS atau RPS tidak meningkat signifikan, Anda dapat menjalankan pernyataan SQL berikut untuk memeriksa apakah pernyataan SQL baru dieksekusi di PQE dengan memeriksa log query lambat. Jika pernyataan SQL dieksekusi di PQE, pernyataan ini menyebabkan masalah pemanfaatan CPU tinggi. Jika pernyataan SQL dieksekusi di PQE, Anda harus mengoptimalkan operator SQL yang dieksekusi di PQE. Untuk informasi lebih lanjut, lihat Optimalkan kinerja query.

  -- Query query yang dieksekusi di 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;

• Penyebab 5: Indeks bitmap atau properti pengkodean kamus tabel dimodifikasi.

  Jika indeks bitmap atau properti pengkodean kamus tabel dimodifikasi, operasi kompaksi dilakukan secara asinkron di backend. Dalam hal ini, sumber daya CPU dikonsumsi, dan kapasitas penyimpanan instance dapat meningkat lalu menurun. Anda dapat menjalankan pernyataan SQL berikut untuk memeriksa apakah indeks bitmap atau properti pengkodean kamus tabel dimodifikasi dengan memeriksa log query lambat.

  -- Query catatan yang indeks bitmap atau properti pengkodean kamusnya dimodifikasi 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 Ongoing Query Duration menunjukkan durasi query yang sedang berlangsung selama periode waktu tertentu. Misalnya, jika query berlangsung lebih dari 1 jam, query tersebut dianggap sebagai query jangka panjang. Jika terdapat query jangka panjang, Anda dapat melihat query tersebut di halaman Active Query. Untuk informasi lebih lanjut, lihat Kelola query. Query jangka panjang dapat disebabkan oleh faktor-faktor berikut:

• Penyebab 1: Operasi penulisan jangka panjang.

  Solusi: Pantau metrik Real-time Import (RPS) untuk memeriksa apakah ada operasi penulisan jangka panjang.

• Penyebab 2: Beberapa query berada dalam status idle in transaction.

  • Jika klien memulai transaksi tetapi tidak melakukan commit setelah pernyataan bahasa definisi data (DDL) dieksekusi, query yang sesuai memasuki status idle in transaction. Anda dapat menjalankan pernyataan SQL berikut untuk memeriksa query aktif yang berada dalam status idle in transaction dan telah berjalan lama:

  • Query berjalan lama karena tunggu kunci.

  Solusi: Jalankan pernyataan SQL sampel berikut untuk melihat query jangka panjang. Jika query jangka panjang berada dalam status idle in transaction, Anda dapat menghentikan transaksi di klien atau mengatur periode timeout yang tepat untuk transaksi idle. Untuk informasi lebih lanjut, lihat Ubah periode timeout query idle.

• Penyebab 3: Beberapa query mencakup pernyataan SQL kompleks yang dieksekusi di PQE.

  Solusi: Jalankan pernyataan SQL berikut untuk memeriksa query aktif yang telah berjalan lama. Lalu, jalankan pernyataan EXPLAIN untuk memeriksa rencana eksekusi query. Jika rencana eksekusi berisi External SQL (Postgres), query mencakup pernyataan SQL yang dieksekusi di PQE.

  -- Query query jangka panjang.
  SELECT current_timestamp - query_start as runtime, datname::text, usename, query, pid::text
      FROM pg_stat_activity
      WHERE state != 'idle'
      order by 1 desc;
  
  -- Query rencana eksekusi query.
  explain sql

  • Hentikan query jangka panjang dengan akun superuser.

  • Optimalkan operator SQL yang dieksekusi di PQE. Untuk informasi lebih lanjut, lihat Optimalkan kinerja query.

• Penyebab 4: Konflik kunci terjadi karena operasi DDL konkuren.

  Jika beberapa pernyataan DDL dijalankan pada saat yang sama, tabel akan terkunci. Akibatnya, konflik kunci terjadi, dan pernyataan DDL harus menunggu dalam antrian hingga kunci tersedia.

  Solusi:

  • Jalankan pernyataan SQL berikut untuk memeriksa apakah pernyataan DDL sedang dijalankan. Hentikan pernyataan DDL yang sedang dijalankan untuk melepaskan kunci.

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

  • Jalankan pernyataan DDL satu per satu.

Di Hologres, data didistribusikan di antara shard. Seorang pekerja dapat mengakses data dari satu atau lebih shard selama komputasi. Di setiap instance, sebuah shard hanya dapat diakses oleh satu pekerja pada satu waktu. Jika jumlah total shard yang diakses oleh setiap pekerja bervariasi, beban pada pekerja mungkin tidak seimbang. Masalah ini dapat terjadi karena kemungkinan penyebab berikut:

• Penyebab 1: Ketidakseimbangan data ada.

  Jika ketidakseimbangan data parah terjadi, seorang pekerja mengakses shard tetap. Hal ini menyebabkan beban CPU tidak seimbang di antara pekerja.

  Solusi: Jalankan pernyataan SQL berikut untuk memeriksa apakah ketidakseimbangan data ada. Dalam hasil sampel berikut, nilai count dari sebuah shard jauh lebih besar daripada shard lainnya. Ini menunjukkan bahwa ketidakseimbangan data ada. Jika ketidakseimbangan data ada, Anda dapat memproses data yang didistribusikan secara tidak merata atau mengatur kunci distribusi yang tepat berdasarkan kebutuhan bisnis Anda. Untuk informasi lebih lanjut, lihat Optimalkan kinerja query.

  select hg_shard_id,count(1) from <table_name> group by hg_shard_id;
  
  -- Hasil sampel: Nilai count dari shard 39 lebih besar daripada shard lainnya. Ini menunjukkan bahwa ketidakseimbangan data ada.
  hg_shard_id | count
  -------------+--------
            53 |  29130
            65 |  28628
            66 |  26970
            70 |  28767
            77 |  28753
            24 |  30310
            15 |  29550
            39 | 164983

• Penyebab 2: Jumlah shard bukan kelipatan dari jumlah pekerja di instance.

  Jika jumlah shard dalam grup tabel bukan kelipatan dari jumlah pekerja, jumlah shard yang dialokasikan ke setiap pekerja bervariasi. Hal ini menyebabkan ketidakseimbangan beban di antara pekerja.

  Solusi: Atur jumlah shard berdasarkan tipe instance. Untuk informasi lebih lanjut, lihat Panduan pengguna grup tabel dan jumlah shard. Dalam kebanyakan kasus, kesalahan ini terjadi pada instance yang memiliki lebih dari 256 inti CPU. Untuk instance dengan spesifikasi lebih kecil, Anda dapat menggunakan jumlah shard default.

• Penyebab 3: Shard dialokasikan secara tidak merata ke pekerja setelah pekerja gagal pulih.

  Jika seorang pekerja dihentikan karena alasan seperti out of memory (OOM), sistem mengalokasikan shard yang sesuai ke pekerja lain untuk memulihkan query. Setelah pekerja yang dihentikan pulih, sistem mengalokasikan beberapa shard ke pekerja ini. Hal ini menyebabkan alokasi shard yang tidak merata di antara pekerja.

  Solusi: Jika beban instance rendah, abaikan masalah ketidakseimbangan beban. Jika beban instance tinggi, mulai ulang instance untuk mengalokasikan shard secara merata.