Atasi error OOM di Hologres - Hologres - Alibaba Cloud Documentation Center

Error OOM (Out of Memory) terjadi ketika suatu kueri melebihi batas memori yang tersedia di Hologres. Topik ini menjelaskan cara memantau penggunaan memori, mengidentifikasi error OOM, dan menanganinya.

Analisis konsumsi memori

Lihat konsumsi memori
- Konsumsi total: Konsol Hologres menampilkan konsumsi memori agregat di seluruh node. Untuk informasi lebih lanjut, lihat Metrik pemantauan.
- Konsumsi per kueri: Bidang memory_bytes memperkirakan konsumsi memori per kueri. Nilai ini mungkin tidak akurat. Untuk informasi lebih lanjut, lihat Dapatkan dan analisis log kueri lambat.
Tangani penggunaan memori tinggi

Pantau penggunaan memori keseluruhan di Konsol Hologres (lihat Metrik pemantauan). Penggunaan berkelanjutan di atas 80% termasuk tinggi. Hologres mengalokasikan memori sebelumnya untuk metadata dan cache, sehingga penggunaan idle sebesar 30–50% adalah normal. Penggunaan mendekati 100% menurunkan stabilitas dan performa.
- Penyebab
  - Konsumsi memori tinggi dari metadata
    
    Memori metadata meningkat seiring volume tabel dan dapat menyebabkan penggunaan tinggi meskipun tidak ada tugas yang berjalan. Batasi setiap Table Group hingga maksimal 10.000 tabel (termasuk partisi, tidak termasuk foreign table). Terlalu banyak shard dalam satu Table Group meningkatkan fragmentasi dan beban overhead metadata.
  - Konsumsi memori tinggi dari komputasi
    
    Memori kueri yang tinggi biasanya disebabkan oleh pemindaian volume data besar atau operasi kompleks seperti beberapa fungsi COUNT DISTINCT, operasi JOIN kompleks, GROUP BY pada beberapa kolom, atau window function.
  - Penggunaan memori tinggi di modul Other
    
    Saat pemantauan memori menunjukkan peningkatan tiba-tiba pada penggunaan memori modul Other bersamaan dengan tingginya utilisasi memori keseluruhan, penyebabnya mungkin parameter eksperimental hg_experimental_enable_hash_partitioned_sort_v2. Parameter ini mengaktifkan algoritma sort berbasis partisi hash untuk filtering nomor baris window. Algoritma ini memiliki isu konsumsi sumber daya yang diketahui dan menyebabkan akumulasi memori tak terklasifikasi di bawah kategori modul Other.
    
    Solusi
    
    Nonaktifkan parameter eksperimental tersebut dengan menjalankan pernyataan SQL berikut:
```
SET hg_experimental_enable_hash_partitioned_sort_v2 = off;
```
    Setelah menonaktifkan parameter ini, pantau penggunaan memori instans. Memori yang dikaitkan ke modul Other seharusnya turun ke level normal.
- Dampak utama
  - Stabilitas
    
    Konsumsi memori berlebihan, terutama dari metadata, mengurangi memori yang tersedia untuk kueri dan dapat menyebabkan error sporadis seperti SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED, atau Total memory used by all existing queries exceeded memory limitation.
  - Performa
    
    Penggunaan memori tinggi akibat metadata berlebihan mengurangi ruang cache, menurunkan tingkat hit cache, dan meningkatkan latensi kueri.
- Solusi
  - Jika penggunaan memori tinggi disebabkan oleh metadata berlebihan: Gunakan tabel hg_table_info untuk mengelola tabel Anda. Untuk informasi lebih lanjut, lihat Kueri dan analisis statistik tabel. Hapus data atau tabel yang tidak digunakan dan kurangi partisi yang tidak perlu untuk membebaskan memori.
  - Jika penggunaan memori tinggi disebabkan oleh komputasi: Optimalkan SQL secara terpisah untuk kasus penggunaan write dan query. Untuk informasi lebih lanjut, lihat Atasi error OOM saat kueri dan Atasi error OOM saat impor dan ekspor data.
  - Solusi umum: Tingkatkan spesifikasi compute dan storage. Daftar instans.

Identifikasi error OOM

Error OOM terjadi ketika memori komputasi melebihi batas alokasinya (misalnya, 20 GB atau lebih). Contoh pesan error khas:

Total memory used by all existing queries exceeded memory limitation. 
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100

Interpretasi pesan error sebagai berikut:

queries=(query_id, memory_used_by_query)

Setiap entri, seperti queries=(2031xxxx,184yy), menunjukkan konsumsi memori per kueri. Misalnya, queries=(2031xxxx,18441803528) berarti kueri query_id=2031xxxx mengonsumsi ~18 GB pada satu node. Lima kueri dengan konsumsi memori tertinggi akan ditampilkan. Untuk informasi lebih lanjut, lihat Dapatkan dan analisis log kueri lambat.
Used/Limit: xy1/xy2

Menunjukkan compute_memory_used_on_node / compute_memory_limit_on_node dalam byte. Used adalah total memori komputasi yang dikonsumsi oleh semua kueri yang sedang berjalan di node tersebut. Misalnya, Used/Limit: 33288093696/33114697728 berarti kueri menggunakan 33,2 GB, melebihi batas 33,1 GB dan memicu OOM.
quota/sum_quota: zz/100

zz adalah persentase total sumber daya instans yang dialokasikan ke kelompok sumber daya. Misalnya, quota/sum_quota: 50/100 berarti kelompok sumber daya tersebut menggunakan 50% dari total sumber daya instans.

Penyebab dasar error OOM

Hologres memprioritaskan komputasi in-memory demi efisiensi kueri optimal. Berbeda dengan sistem yang melakukan spill ke disk saat memori tidak mencukupi, Hologres langsung memunculkan error OOM ketika suatu kueri melebihi memori yang tersedia.

Alokasi dan batas memori

Instans Hologres beroperasi sebagai sistem terdistribusi, terdiri dari beberapa node yang jumlahnya bervariasi sesuai spesifikasi instans. Untuk detail lebih lanjut, lihat Manajemen instans.

Setiap node biasanya memiliki 16 vCPU dan memori 64 GB. Error OOM terjadi jika salah satu node kehabisan memorinya. Memori 64 GB tersebut dibagi untuk komputasi kueri, proses backend, cache, dan metadata. Sebelum V1.1.24, memori komputasi dibatasi maksimal 20 GB. Di V1.1.24 dan versi setelahnya, memori yang tersedia dialokasikan secara dinamis ke kueri saat konsumsi metadata rendah.

Atasi error OOM saat kueri

Penyebab.
- Rencana eksekusi salah: Hal ini dapat disebabkan oleh statistik yang tidak akurat, urutan join yang tidak tepat, atau isu optimasi lainnya.
- Konkurensi kueri tinggi: Banyak kueri yang secara simultan mengonsumsi memori dalam jumlah besar.
- Kueri kompleks: Kueri yang secara inheren kompleks atau melakukan pemindaian volume data besar.
- UNION ALL operations: Kueri yang mengandung UNION ALL dapat meningkatkan paralelisme pelaksana, sehingga meningkatkan penggunaan memori.
- Alokasi kelompok sumber daya tidak mencukupi: Kelompok sumber daya telah dikonfigurasi tetapi dialokasikan sumber daya yang tidak memadai.
- Data skew atau shard pruning: Kondisi ini dapat menyebabkan beban tidak seimbang dan tekanan memori tinggi pada node tertentu.

Analisis dan solusi:

Penyebab: Alokasi kelompok sumber daya tidak mencukupi

Solusi: Gunakan fitur Serverless Computing untuk melengkapi sumber daya dedicated instans Anda dengan kapasitas komputasi tambahan. Untuk ikhtisar dan instruksi penggunaan, lihat Serverless computing dan Work with serverless computing.

Di Hologres V3.0 dan versi setelahnya, Query Queue secara otomatis menjalankan ulang kueri OOM pada sumber daya serverless computing. Control large queries.

Penyebab: Rencana eksekusi salah

Tipe 1: Statistik tidak akurat

Jalankan EXPLAIN <SQL> untuk melihat rencana eksekusi. rows=1000 menunjukkan statistik hilang atau tidak akurat, sehingga menghasilkan rencana eksekusi tidak efisien yang mengonsumsi sumber daya berlebihan dan memicu error OOM.

tt=# explain  select count(1) from tmp join tmp1 on tmp.a = tmp1.b;
                                    QUERY PLAN
----------------------------------------------------------------------------------
Partial Aggregate  (cost=0.00..10.11 rows=1 width=8)
  ->  Gather Motion  (cost=0.00..10.11 rows=10 width=8)
    ->  Partial Aggregate  (cost=0.00..10.11 rows=10 width=8)
      ->  Hash Join  (cost=0.00..10.11 rows=1 width=1)
            Hash Cond: (tmp.a = tmp1.b)
            ->  Parallelism (Gather Exchange)  (cost=0.00..5.04 rows=1000 width=1)
                  ->  DecodeNode  (cost=0.00..5.04 rows=1000 width=1)
                        ->  Seq Scan on tmp  (cost=0.00..5.01 rows=1000 width=1)
            ->  Hash  (cost=5.04..5.04 rows=1000 width=1)
                  ->  Parallelism (Gather Exchange)  (cost=0.00..5.04 rows=1000 width=1)
                        ->  DecodeNode  (cost=0.00..5.04 rows=1000 width=1)
                              ->  Seq Scan on tmp1  (cost=0.00..5.01 rows=1000 width=1)
Optimizer: HQO version 0.8.0
(13 rows)

Solusi meliputi hal-hal berikut:

Jalankan perintah ANALYZE <tablename> untuk memperbarui statistik tabel.
Aktifkan auto analyze agar statistik diperbarui secara otomatis. Untuk informasi lebih lanjut, lihat ANALYZE and AUTO ANALYZE.

Tipe 2: Urutan join salah

Pada Hash Join, tabel yang lebih kecil seharusnya menjadi sisi build. Gunakan EXPLAIN <SQL> untuk memeriksa rencana eksekusi. Jika tabel yang lebih besar digunakan untuk membangun tabel hash, maka urutan join tidak efisien dan dapat menyebabkan OOM. Penyebab umum:

Statistik tabel usang. Misalnya, statistik tabel bagian atas tidak diperbarui, sehingga menghasilkan rows=1000.

Dalam rencana eksekusi, node Result di sisi kiri Hash Left Join memiliki perkiraan jumlah baris hanya 1.000, sedangkan sisi build Hash di kanan memiliki perkiraan jumlah baris sebesar 6.754.108.416 (sekitar 6,75 miliar). Perbedaan besar ini menunjukkan bahwa tabel besar digunakan untuk membangun tabel Hash.

Gather  (cost=0.00..56428622.14 rows=6754109416 width=496)
  -> Insert  (cost=0.00..49020180.01 rows=6754109416 width=496)
    -> Result  (cost=0.00..79269.98 rows=6754109416 width=742)
      -> Hash Left Join  (cost=0.00..54211.24 rows=6754109416 width=660)
            Hash Cond: (row_pk = dws_tb_crm_itm_prf_exp_analysis_nd.row_pk)
            -> Result  (cost=0.00..7.03 rows=1000 width=600)
                  -> Redistribution  (cost=0.00..6.01 rows=1000 width=496)
                        -> Result  (cost=0.00..6.00 rows=1000 width=496)
                              Filter: ((ds = ‘${bizdate}’::text) AND (NOT (row_pk IS NULL)))
                              -> Forward  (cost=0.00..6.00 rows=1000 width=504)
                                    -> Sequence  (cost=0.00..5.00 rows=1000 width=504)
                                          -> Partition Selector for dws_tb_crm_itm_prf_exp_analysis_nd_extl (dynamic scan id: 1)  (cost=10.00..100.00 rows=100 width=4)
                                                Partitions selected: 0 (out of 33)
                                          -> DynamicSeqScan  (cost=0.00..5.00 rows=1000 width=504)
            -> Hash  (cost=11717.79..11717.79 rows=6754108416 width=60)
                  -> Exchange (Gather Exchange)  (cost=0.00..11717.79 rows=6754108416 width=60)
                        -> Decode  (cost=0.00..2755.96 rows=6754108416 width=60)
                              -> Seq Scan on dws_tb_crm_itm_prf_exp_analysis_nd  (cost=0.00..871.47 rows=6754108416 width=60)
Optimizer: HQO version 0.10.0
(19 rows)

Pengoptimal gagal menghasilkan rencana eksekusi optimal.

Solusi:

Jalankan ANALYZE <tablename> pada semua tabel yang terlibat dalam join untuk memastikan statistik mutakhir. Hal ini membantu pengoptimal menentukan urutan join yang benar.

Jika urutan join tetap salah setelah menjalankan ANALYZE <tablename>, sesuaikan parameter GUC. Tetapkan optimizer_join_order = query untuk memaksa pengoptimal mengikuti urutan join yang ditentukan dalam pernyataan SQL. Pendekatan ini sangat cocok untuk kueri kompleks.

SET optimizer_join_order = query;
SELECT * FROM a JOIN b ON a.id = b.id; -- Tabel b digunakan sebagai sisi build tabel hash.

Anda juga dapat menyesuaikan kebijakan urutan join sesuai kebutuhan.

Parameter

Deskripsi

set optimizer_join_order = <value>

Parameter ini mengontrol algoritma Join Order pengoptimal. Nilai valid:

query: Tidak melakukan transformasi Join Order. Join dieksekusi secara ketat sesuai urutan yang ditentukan dalam kueri SQL. Pengaturan ini memiliki overhead pengoptimal paling rendah.
greedy: Menggunakan algoritma greedy untuk mengeksplorasi kemungkinan Join Order. Opsi ini menghasilkan overhead pengoptimal moderat.
exhaustive (default): Menggunakan algoritma perencanaan dinamis untuk transformasi Join Order. Bertujuan menghasilkan rencana eksekusi optimal tetapi memiliki overhead pengoptimal paling tinggi.

Tipe 3: Estimasi tabel hash salah

Pada hash join, input yang lebih kecil seharusnya membangun tabel hash. Namun, kompleksitas kueri atau statistik yang tidak akurat dapat menyebabkan sistem memilih relasi yang lebih besar sebagai input build, sehingga membuat tabel hash terlalu besar dan memicu OOM.

Hash (cost=727353.45..627353.35 , rows=970902134 width=94) merepresentasikan input build, dan rows=970902134 menunjukkan volume data perkiraan untuk membangun tabel hash. Jika tabel aktual berisi data lebih sedikit, estimasinya tidak akurat.

Node Hash di bagian bawah rencana eksekusi memiliki perkiraan jumlah baris sebesar rows=970902134 (sekitar 970 juta baris), yang merupakan gejala khas dari volume data Build Side yang sangat dilebih-lebihkan atau dipilih secara salah.

-> Broadcast  (cost=0.00..5.17 rows=119488 width=16)
                    -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=16)
                        -> Decode  (cost=0.00..5.10 rows=1867 width=16)
                            -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=16)
            -> Hash  (cost=5.17..5.17 rows=119488 width=16)
                -> Broadcast  (cost=0.00..5.17 rows=119488 width=16)
                    -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=16)
                        -> Decode  (cost=0.00..5.10 rows=1867 width=16)
                            -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=16)
        -> Hash  (cost=5.13..5.13 rows=119488 width=8)
            -> Broadcast  (cost=0.00..5.13 rows=119488 width=8)
                -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=8)
                    -> Decode  (cost=0.00..5.10 rows=1867 width=8)
                        -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=8)
    -> Hash  (cost=5.10..5.10 rows=896 width=3)
        -> Broadcast  (cost=0.00..5.10 rows=896 width=3)
            -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=14 width=3)
                -> Decode  (cost=0.00..5.10 rows=14 width=3)
                    -> Seq Scan on xxx  (cost=0.00..5.00 rows=14 width=3)
-> Hash  (cost=627353.45..627353.45 rows=970902134 width=94)
    -> Partial HashAggregate  (cost=0.00..627353.45 rows=970902134 width=94)

Solusi:

Verifikasi statistik: Periksa apakah statistik tabel subkueri mutakhir dan akurat. Jika tidak, jalankan ANALYZE <tablename> untuk memperbaruinya.
Nonaktifkan estimasi tabel hash: Matikan estimasi ukuran tabel hash mesin eksekusi menggunakan parameter berikut:

Catatan
Parameter ini secara default bernilai off. Namun, mungkin telah diaktifkan dalam skenario tuning tertentu. Jika saat ini diaktifkan, pastikan Anda mengembalikannya ke off.
```
SET hg_experimental_enable_estimate_hash_table_size =off;
```

Tipe 4: Broadcasting tabel besar

Broadcasting menyalin data ke semua shard dan hanya efisien untuk tabel kecil dengan jumlah shard sedikit. Saat join, input build di-broadcast ke setiap shard. Dataset besar atau jumlah shard berlebihan dapat mengonsumsi memori signifikan, menyebabkan error OOM.

Misalnya, tabel dengan 80 juta baris mungkin hanya menunjukkan estimasi 1 baris dalam rencana eksekusi. Broadcast aktual seluruh 80 juta baris mengonsumsi memori berlebihan, memicu OOM.

Gather  (cost=0.00..119000614.54 rows=495989952 width=5537)
  ->  Insert  (cost=0.00..112801537.07 rows=495989952 width=5537)
        ->  Redistribution  (cost=0.00..428813.57 rows=991979904 width=2320)
              ->  Result  (cost=0.00..338771.55 rows=991979904 width=2320)
                    ->  Result  (cost=0.00..338771.55 rows=991979904 width=2320)
                          ->  Hash Left Join  (cost=0.00..310003.14 rows=991979904 width=5561)
                                Hash Cond: ((olap_event_1480807263997566978.pub_distinct_id = olap_event_1480807263997566978_new.pub_distinct_id) AND (olap_event_1480807263997566978.pub_event_name = olap_event_1480807263997566978_new.pub_event_name) AND (olap_event_1480807263997566978.uuid = olap_event_1480807263997566978_new.uuid))
                                ->  Exchange (Gather Exchange)  (cost=0.00..68102.40 rows=495989952 width=5537)
                                      ->  Decode  (cost=0.00..65774.92 rows=495989952 width=5537)
                                            ->  Seq Scan on olap_event_1480807263997566978  (cost=0.00..1923.43 rows=495989952 width=5537)
                                ->  Hash  (cost=5.10..5.10 rows=80 width=24)
                                      ->  Broadcast  (cost=0.00..5.10 rows=80 width=24)
                                            ->  Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1 width=24)
                                                  ->  Decode  (cost=0.00..5.10 rows=1 width=24)
                                                        ->  Seq Scan on olap_event_1480807263997566978_new  (cost=0.00..5.00 rows=1 width=24)
Optimizer: HQO version 1.1.0

Solusi:

Periksa apakah perkiraan jumlah baris dalam rencana eksekusi sesuai dengan kenyataan. Jika tidak, jalankan ANALYZE tablename untuk memperbarui statistik.
Nonaktifkan broadcasting dan tulis ulang sebagai operator redistribution menggunakan parameter GUC berikut.
```
SET optimizer_enable_motion_broadcast = off;
```

Penyebab: Konkurensi kueri tinggi
Jika QPS melonjak signifikan, atau error OOM menunjukkan HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); dengan setiap kueri menggunakan memori minimal, kemungkinan besar penyebabnya adalah konkurensi tinggi. Solusi:
- Kurangi konkurensi write: Jika operasi write berkontribusi, kurangi konkurensinya. Untuk informasi lebih lanjut, lihat Atasi error OOM saat impor dan ekspor data.
- Terapkan pemisahan baca/tulis: Terapkan arsitektur pemisahan baca/tulis dengan instans primary dan secondary (shared storage).
- Tingkatkan spesifikasi compute instans Anda.
Penyebab: Kueri kompleks
Jika satu kueri memicu OOM karena kompleksitas atau volume data besar, pertimbangkan pendekatan berikut:
- Pre-compute data: Tulis data hasil pre-compute ke Hologres untuk menghindari operasi ETL skala besar di dalam Hologres.
- Tambahkan kondisi filter.
- Optimalkan SQL: Gunakan teknik seperti Fixed Plan atau optimasi Count Distinct. Untuk informasi lebih lanjut, lihat Optimize internal table query performance.
Penyebab: UNION ALL

Seperti ditunjukkan di bawah, ketika pernyataan SQL mengandung banyak subkueri UNION ALL, pelaksana memprosesnya secara konkuren. Hal ini dapat membebani memori dan menyebabkan error OOM.
```
subquery1 UNION ALL subquery2 UNION ALL subquery3 ...
```
Solusi: Paksa eksekusi serial menggunakan parameter berikut untuk mengurangi error OOM. Perlu diketahui bahwa hal ini akan mengakibatkan performa kueri lebih lambat.
```
SET hg_experimental_hqe_union_all_type=1;
SET hg_experimental_enable_fragment_instance_delay_open=on;
```
Penyebab: Konfigurasi kelompok sumber daya tidak memadai
Error OOM melaporkan: memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100. Jika zz kecil—misalnya, 10 (hanya 10% sumber daya dialokasikan)—kueri dalam kelompok tersebut memiliki memori terbatas, sehingga meningkatkan kemungkinan OOM.
```
AcquireOrRelease] HGERR code 53200 HGERR msge Total memory used by all existing queries
exceeded memory limitation. HGERR detl memory usage for existing
queries=(7001xxx 5,4367295472)(673125xxx9,1701576)(6731xxx 3,3590736)(6731xxx 5,3510024) (673116xxx ,3088256
Used/Limit: 4408213504/42552795136 quota/sum_quota: 10/100.
```
Solusi: Atur ulang kuota kelompok sumber daya. Alokasikan minimal 30% dari total sumber daya instans ke setiap kelompok sumber daya.

Penyebab: Data skew atau shard pruning

Jika penggunaan memori keseluruhan rendah tetapi OOM tetap terjadi, data skew atau shard pruning mungkin memusatkan tekanan memori pada node tertentu.

Catatan

Shard pruning adalah teknik optimasi kueri yang hanya memindai subset shard, bukan semua shard.

Periksa data skew: Gunakan kueri SQL berikut. hg_shard_id adalah bidang tersembunyi bawaan di setiap tabel yang menunjukkan shard tempat setiap baris berada.
```
SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id;
```

Periksa shard pruning: Periksa rencana eksekusi untuk indikasi Shard Pruning. Misalnya, jika selector shard menunjukkan l0[1], artinya hanya data dari satu shard spesifik yang dipilih untuk kueri.

-- Kunci distribusi adalah x. Berdasarkan kondisi filter x=1, Anda dapat dengan cepat menemukan shard.
SELECT count(1) FROM bbb WHERE x=1 GROUP BY y;

                          QUERY PLAN
--------------------------------------------------------------
Result  (cost=0.00..5.10 rows=1 width=8)
  ->  HashAggregate  (cost=0.00..5.10 rows=1 width=8)
        Group Key: y
        ->  Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1 width=4)
            ->  Decode  (cost=0.00..5.10 rows=1 width=4)
                ->  Seq Scan on bbb  (cost=0.00..5.00 rows=1 width=4)
                      Filter: (x = 1)
                      Shard Selector(Eagerly):
                        ->: l0 [1]
Optimizer: HQO version 1.3.0
(10 rows)

Solusi:

Rancang kunci distribusi yang sesuai untuk mencegah data skew.
Jika logika bisnis secara inheren menyebabkan data skew, modifikasi logika aplikasi yang sesuai.

Penyebab: GROUP BY multi-tahap dengan kardinalitas tinggi

Di Hologres V3.0 dan versi setelahnya, agregasi multi-tahap pada data kardinalitas tinggi dapat menyebabkan OOM ketika kolom GROUP BY tidak sejajar dengan kunci distribusi (kunci distribusi bukan subset dari kunci GROUP BY). Setiap instance konkuren mempertahankan tabel hash besar, menciptakan tekanan memori tinggi. Untuk menguranginya, tetapkan parameter berikut:
```
-- Gunakan parameter GUC untuk mengatur jumlah maksimum baris dalam tabel hash agregasi. Pernyataan SQL berikut menunjukkan bahwa partial_agg_hash_table dapat memiliki maksimal 8192 baris. Nilai default adalah 0, yang berarti tidak ada batas.
SET hg_experimental_partial_agg_hash_table_size = 8192;
```

Atasi error OOM saat impor dan ekspor data

Error OOM dapat terjadi selama transfer data di Hologres, termasuk antar tabel internal, interaksi dengan foreign table, dan impor dari MaxCompute.

Solusi 1: Gunakan Serverless Computing untuk impor dan ekspor

Gunakan Serverless Computing untuk melengkapi sumber daya instans Anda dalam tugas impor dan ekspor, menghindari konflik sumber daya. Untuk ikhtisar, lihat Serverless computing. Untuk instruksi penggunaan, lihat Work with serverless computing.

Solusi 2: Kontrol konkurensi pemindaian untuk tabel lebar atau kolom lebar

Pada impor MaxCompute, error OOM dapat muncul dari tabel lebar atau kolom lebar yang dikombinasikan dengan konkurensi pemindaian tinggi. Gunakan parameter berikut untuk mengontrol konkurensi.

Kontrol konkurensi pemindaian untuk tabel lebar (skenario umum)

Catatan

Terapkan parameter berikut bersama pernyataan SQL Anda. Utamakan dua parameter pertama. Jika error OOM masih terjadi, kurangi nilai-nilainya lebih lanjut.

-- Tetapkan konkurensi maksimum untuk mengakses foreign table. Nilai default sama dengan jumlah vCPU instans. Nilai maksimum adalah 128. Jangan tetapkan nilai besar untuk mencegah kueri pada foreign table, terutama dalam skenario impor data, memengaruhi kueri lain dan menyebabkan error system busy. Parameter ini berlaku di Hologres V1.1 dan versi setelahnya.
SET hg_foreign_table_executor_max_dop = 32;

-- Sesuaikan ukuran batch untuk setiap pembacaan dari tabel MaxCompute. Nilai default adalah 8192.
SET hg_experimental_query_batch_size = 4096;

-- Tetapkan konkurensi maksimum untuk mengeksekusi pernyataan DML saat mengakses foreign table. Nilai default adalah 32. Parameter ini dioptimalkan untuk skenario impor dan ekspor data guna mencegah operasi impor mengonsumsi sumber daya sistem berlebihan. Parameter ini berlaku di Hologres V1.1 dan versi setelahnya.
SET hg_foreign_table_executor_dml_max_dop = 16;

-- Tetapkan ukuran split untuk mengakses tabel MaxCompute. Parameter ini dapat menyesuaikan konkurensi. Nilai default adalah 64 MB. Jika tabel besar, tingkatkan nilai ini untuk mencegah terlalu banyak split memengaruhi performa. Parameter ini berlaku di Hologres V1.1 dan versi setelahnya.
SET hg_foreign_table_split_size = 128;

Kontrol konkurensi pemindaian untuk kolom lebar

Jika Anda telah menyetel parameter untuk tabel lebar tetapi masih mengalami error OOM, periksa apakah data Anda mengandung kolom lebar. Jika iya, sesuaikan parameter berikut untuk mengatasi masalah tersebut.

-- Sesuaikan paralelisme shuffle untuk kolom lebar guna mengurangi akumulasi data.
SET hg_experimental_max_num_record_batches_in_buffer = 32;

-- Sesuaikan ukuran batch untuk setiap pembacaan dari tabel MaxCompute. Nilai default adalah 8192.
SET hg_experimental_query_batch_size=128;

Penyebab: Data duplikat berlebihan dalam foreign table

Saat foreign table berisi data duplikat dalam jumlah besar, performa impor menurun dan dapat menyebabkan error OOM. Misalnya, tabel berisi 100 juta baris dengan 80 juta duplikat termasuk sangat terduplikasi. Evaluasi tingkat duplikasi berdasarkan konteks bisnis Anda.

Solusi: Deduplikasi data sebelum impor, atau impor dalam batch lebih kecil.

Apa penyebab error "The shards are incomplete, the workers or shards are unhealthy"?

Error ini biasanya tidak disebabkan langsung oleh masalah kehabisan memori (OOM). Error ini terjadi ketika penggunaan CPU instans Hologres sangat tinggi, sehingga menyebabkan node Worker atau Shard masuk ke kondisi tidak sehat.

Untuk mengatasi masalah ini:

Periksa metrik pemantauan instans Hologres untuk memverifikasi apakah penggunaan CPU tinggi.
Jika penggunaan CPU tinggi, tunggu hingga beban kerja menurun lalu coba ulang kueri.
Jika error tetap terjadi, periksa apakah kueri kompleks atau konkurensi berlebihan menyebabkan saturasi CPU. Optimalkan kueri yang intensif sumber daya atau kurangi konkurensi untuk menurunkan penggunaan CPU.