Bir Hologres örneği yavaş yanıt verdiğinde veya sorgular çok uzun sürdüğünde, yavaş sorgu günlükleri sorunu belirlemenize ve teşhis etmenize yardımcı olur. Bu konu, hologres.hg_query_log tablosunun nasıl sorgulanacağını, temel alanların nasıl yorumlanacağını ve performans sorunlarını tespit etmek için tanısal SQL'in nasıl kullanılacağını açıklar.
Sürüm kılavuzu
| Sürüm | Değişiklik |
|---|---|
| V0.10 | Yavaş sorgu günlükleri tanıtıldı. FAILED durumundaki sorguların günlükleri çalışma zamanı istatistiklerini (bellek, disk okumaları, okunan veri hacmi, CPU süresi veya query_stats) içermez. |
| V2.2 | hg_query_log tablosuna digest sütunu (SQL parmak izi) eklendi. |
| V2.2.7 | log_min_duration_statement parametresinin varsayılan değeri 1.000 ms'den 100 ms'ye değiştirildi. |
| V3.0.2 | 100 ms altında çalışan DML ve DQL işlemleri için toplu kayıtlar eklendi. Ayrıca calls ve agg_stats alanları eklendi. |
| V3.0.27 | hg_query_log_retention_time_sec aracılığıyla günlük saklama süresinin değiştirilmesi için destek eklendi. |
Bu özellik Hologres V0.10 veya sonraki bir sürümü gerektirir. Örnek sürümünüzü kontrol etmek için Hologres konsolundaki örnek ayrıntıları sayfasına gidin. Daha eski bir örneği yükseltmek için bkz. Yaygın yükseltme hazırlık hataları veya Hologres desteği ile iletişime geçin. Daha fazla bilgi için bkz. Daha fazla çevrimiçi desteği nasıl alabilirim? .
Sınırlamalar
Yavaş sorgu günlükleri varsayılan olarak bir ay süreyle saklanır.
Tek bir sorgu en fazla 10.000 yavaş sorgu günlüğü girişi döndürür. Bazı alanların uzunluk sınırları vardır —
hg_query_logtablosu bölümündeki alan açıklamalarına bakın.Yavaş sorgu günlükleri Hologres meta veri ambarının bir parçasıdır. Başarısız bir yavaş sorgu günlüğü araması iş sorgularınızı etkilemez ve günlüklerin kullanılabilirliği Hologres Hizmet Seviyesi Sözleşmesi (SLA) kapsamında değildir.
Çalışma biçimi
Hologres, yavaş sorgu günlüklerini hologres.hg_query_log sistem tablosunda saklar. Tablo yalnızca tamamlanan SQL deyimlerini kaydeder; devam eden sorgular tabloya yazılmaz. Bu davranış V2, V3 ve sonraki sürümlerde tutarlıdır.
Neler günlüğe kaydedilir:
V0.10'a yükselttikten sonra: 100 ms'den uzun süren yavaş DML sorguları ve tüm DDL işlemleri.
V3.0.2'den itibaren: 100 ms'den uzun süren sorgular için ayrıntılı kayıtlara ek olarak, 100 ms altında tamamlanan DQL ve DML sorguları için de toplu kayıtlar yazılır.
Toplama işleyişi (V3.0.2+):
Hızlı sorgular (100 ms altı) için sistem, aynı SQL parmak izine (digest) sahip başarılı DQL ve DML sorgularını gruplar. Toplama anahtarı şunlardır: server_addr, usename, datname, warehouse_id, application_name ve digest. Her bağlantı, dakikada bir toplu kayıt gönderir.
hg_query_log tablosu
Tablo, aynı şemayı paylaşan ancak farklı anlamlara sahip iki tür kayıt içerir:
| Alan | Veri türü | Ayrıntılı kayıtlar (100 ms üzeri) | Toplu kayıtlar (100 ms altı) |
|---|---|---|---|
usename |
text | Sorguyu yapan kullanıcı adı. | Sorguyu yapan kullanıcı adı. |
status |
text | SUCCESS veya FAILED. |
Her zaman SUCCESS (yalnızca başarılı sorgular toplanır). |
query_id |
text | Benzersiz sorgu kimliği. Başarısız bir sorgunun her zaman bir query_id değeri vardır; başarılı bir sorguda olmayabilir. |
Aynı toplama anahtarına sahip toplama dönemindeki ilk sorgunun query_id değeri. |
digest |
text | SQL parmak izi (MD5 karması). V2.2'de eklendi. Daha fazla bilgi için bkz. SQL parmak izi. | SQL parmak izi. |
datname |
text | Veritabanı adı. | Veritabanı adı. |
command_tag |
text | Sorgu türü: DML (COPY, DELETE, INSERT, SELECT, UPDATE), DDL (ALTER TABLE, BEGIN, COMMENT, COMMIT, CREATE FOREIGN TABLE, CREATE TABLE, DROP FOREIGN TABLE, DROP TABLE, IMPORT FOREIGN SCHEMA, ROLLBACK, TRUNCATE TABLE) veya Diğer (CALL, CREATE EXTENSION, EXPLAIN, GRANT, SECURITY LABEL). | Toplama dönemindeki ilk sorgunun command_tag değeri. |
warehouse_id |
integer | Sorgu için kullanılan sanal depo kimliği. | Toplama dönemindeki ilk sorgunun sanal depo kimliği. |
warehouse_name |
integer | Sorgu için kullanılan sanal depo adı. | Toplama dönemindeki ilk sorgunun sanal depo adı. |
warehouse_cluster_id |
integer | V3.0.2'de eklendi. Sanal depodaki küme kimliği. Küme kimlikleri 1'den başlar. | Toplama dönemindeki ilk sorgunun küme kimliği. |
duration |
integer | Milisaniye cinsinden toplam sorgu süresi. Üç aşamaya ayrılır — aşağıya bakın. | Toplama dönemindeki tüm sorguların ortalama süresi. |
message |
text | Başarısız sorgular için hata mesajı. | Boş. |
query_start |
timestamptz | Sorgu başlangıç zamanı. | Toplama dönemindeki ilk sorgunun query_start değeri. |
query_date |
text | Sorgu başlangıç tarihi. | Toplama dönemindeki ilk sorgunun query_date değeri. |
query |
text | Sorgu metni. Maksimum 51.200 karakter; daha uzun sorgular kırpılır. | Toplama dönemindeki ilk sorgunun sorgu metni. |
result_rows |
bigint | Döndürülen satır sayısı. INSERT için, eklenen satır sayısı. | Toplama dönemindeki tüm sorguların ortalama değeri. |
result_bytes |
bigint | Döndürülen bayt sayısı. | Ortalama değer. |
read_rows |
bigint | Okunan satır sayısı (tam değil; bitmap dizini kullanıldığında gerçek taranan satırlardan farklı olabilir). | Ortalama değer. |
read_bytes |
bigint | Okunan bayt sayısı. | Ortalama değer. |
affected_rows |
bigint | DML deyimi tarafından etkilenen satır sayısı. | Ortalama değer. |
affected_bytes |
bigint | DML deyimi tarafından etkilenen bayt sayısı. | Ortalama değer. |
memory_bytes |
bigint | Tüm düğümlerdeki kümülatif tepe bellek kullanımı (tam değil). Sorgu tarafından okunan veri miktarını yansıtır. | Ortalama değer. |
shuffle_bytes |
bigint | Ağ üzerinden karıştırılan tahmini bayt sayısı (tam değil). | Ortalama değer. |
cpu_time_ms |
bigint | Tüm hesaplama görevlerindeki toplam CPU süresi milisaniye cinsinden (tam değil). Sorgu karmaşıklığını yansıtır. | Ortalama değer. |
physical_reads |
bigint | Diskten okunan kayıt yığını sayısı. Önbellek isabet oranını yansıtır. | Ortalama değer. |
pid |
integer | Sorgu hizmetinin işlem kimliği. | Toplama dönemindeki ilk sorgunun işlem kimliği. |
application_name |
text | Uygulama tanımlayıcısı. Bkz. application_name değerleri. | Uygulama türü. |
engine_type |
text[] | Kullanılan yürütme motoru. Bkz. Motor türleri. | Toplama dönemindeki ilk sorgunun motoru. |
client_addr |
text | Kaynak IP adresi (uygulamanın giden IP'si, mutlaka gerçek uygulama IP'si değildir). | Toplama dönemindeki ilk sorgunun kaynak adresi. |
table_write |
text | Verinin yazıldığı tablo. | Toplama dönemindeki ilk sorgunun yazma hedefi. |
table_read |
text[] | Verinin okunduğu tablolar. | Toplama dönemindeki ilk sorgunun okuma kaynakları. |
session_id |
text | Oturum kimliği. | Toplama dönemindeki ilk sorgunun oturum kimliği. |
session_start |
timestamptz | Bağlantının kurulduğu zaman. | Toplama dönemindeki tüm sorguların oturum başlangıç zamanı. |
command_id |
text | Komut veya deyim kimliği. | Toplama dönemindeki tüm sorguların komut kimliği. |
optimization_cost |
integer | Sorgu yürütme planını oluşturma süresi (ms). Yüksek değerler karmaşık bir SQL deyimine işaret eder. | Toplama dönemindeki tüm sorguların plan oluşturma süresi. |
start_query_cost |
integer | Sorgu başlatma süresi (ms). Yüksek değerler sorgunun kilitler veya kaynaklar için beklediğine işaret eder. | Toplama dönemindeki tüm sorguların başlatma süresi. |
get_next_cost |
integer | Sorgu yürütme süresi (ms). Yüksek değerler hesaplamanın büyük olduğunu ve yürütmenin uzun sürdüğünü gösterir. | Toplama dönemindeki tüm sorguların yürütme süresi. |
extended_cost |
text | Diğer zamanlama ayrıntıları, şunları içerir: build_dag (hesaplama yönlendirilmiş asiklik grafiğini (DAG) oluşturma süresi; yüksek değerler yabancı tablolar için yavaş meta veri erişimine işaret eder), prepare_reqs (yürütme motoru için istekleri hazırlama süresi; yüksek değerler yavaş parça adresi çözümlemesine işaret eder) ve Serverless'e özel alanlar (serverless_allocated_cores, serverless_allocated_workers, serverless_resource_used_time_ms). |
Toplama dönemindeki ilk sorgunun genişletilmiş maliyeti. |
plan |
text | Sorgu yürütme planı. Maksimum 102.400 karakter; daha uzun planlar kırpılır. log_min_duration_query_plan tarafından kontrol edilir. |
Toplama dönemindeki ilk sorgunun yürütme planı. |
statistics |
text | Sorgu yürütme istatistikleri. Maksimum 102.400 karakter. log_min_duration_query_stats tarafından kontrol edilir. |
Toplama dönemindeki ilk sorgunun yürütme istatistikleri. |
visualization_info |
text | Sorgu planı görselleştirme verileri. | Toplama dönemindeki ilk sorgunun görselleştirme verileri. |
query_detail |
text | JSON formatında genişletilmiş sorgu bilgileri. Maksimum 10.240 karakter; daha uzun değerler kırpılır. | Toplama dönemindeki ilk sorgunun genişletilmiş bilgileri. |
query_extinfo |
text[] | Dizi formatında genişletilmiş sorgu bilgileri. Serverless sorguları için serverless_computing içerir. V2.0.29'dan itibaren hesabın AccessKey ID'sini de yakalar. Not: Yerel hesaplar, Hizmet Bağlantılı Roller (SLR) veya Security Token Service (STS) oturum açmaları için AccessKey ID kaydedilmez. Geçici hesaplar için yalnızca geçici AccessKey ID kaydedilir. |
Toplama dönemindeki ilk sorgunun genişletilmiş bilgileri. |
calls |
INT | Ayrıntılı kayıtlar için her zaman 1 (toplama yok). V3.0.2'de eklendi. |
Toplama döneminde aynı toplama anahtarına sahip sorgu sayısı. |
agg_stats |
JSONB | Boş. V3.0.2'de eklendi. | Sayısal alanlar (duration, memory_bytes, cpu_time_ms, physical_reads, optimization_cost, start_query_cost, get_next_cost) için MIN, MAX ve AVG istatistikleri. |
extended_info |
JSONB | Sorgu Kuyruğu ve Serverless Computing hakkında genişletilmiş bilgiler. Bkz. extended_info değerleri. | Boş. |
duration dökümünü anlama:
duration alanı toplam sorgu süresini temsil eder ve üç aşamadan oluşur:
| Aşama | Alan | Anlamı | Yüksek olduğunda |
|---|---|---|---|
| Plan oluşturma | optimization_cost |
Yürütme planını derleme süresi | SQL deyimi karmaşıktır |
| Başlatma | start_query_cost |
Yürütme başlamadan önceki süre | Kilitler veya kaynaklar için bekleniyor |
| Yürütme | get_next_cost |
Sorguyu çalıştırma süresi | Hesaplama büyüktür ve yürütme uzun sürer |
Bu üç aşamanın ötesinde ek zamanlama ayrıntıları için extended_cost kullanın.
application_name değerleri
| Kaynak | Format |
|---|---|
| Realtime Compute for Apache Flink (VVR) | {client_version}_ververica-connector-hologres |
| Açık kaynak Flink | {client_version}_hologres-connector-flink |
| DataWorks çevrimdışı okuma senkronizasyonu | datax_{jobId} |
| DataWorks çevrimdışı yazma senkronizasyonu | {client_version}_datax_{jobId} |
| DataWorks gerçek zamanlı senkronizasyon | {client_version}_streamx_{jobId} |
| HoloWeb | holoweb |
| MaxCompute yabancı tablo erişimi | MaxCompute |
| Auto Analyze | AutoAnalyze |
| Quick BI | QuickBI_public_{version} |
| DataWorks zamanlama | {client_version}_dwscheduler_{tenant_id}_{scheduler_id}_{scheduler_task_id}_{bizdate}_{cyctime}_{scheduler_alisa_id} |
| Data Security Guard | dsg |
Diğer uygulamalar için, bağlantı dizesinde application_name değerini açıkça ayarlayın.
Motor türleri
| Motor | Açıklama |
|---|---|
| HQE | Hologres'in yerel özel mülkiyet motoru. Çoğu sorgu yüksek yürütme verimliliği için HQE kullanır. |
| PQE | PostgreSQL motoru. PQE göründüğünde, bazı SQL operatörleri HQE tarafından yerel olarak desteklenmez. Bunları Sorgu performansını optimize etme bölümünde açıklandığı gibi yeniden yazmak performansı artırabilir. |
| FixedQE | Sabit Plan için yürütme motoru. Nokta okumaları, nokta yazmaları ve PrefixScan gibi sunum tipi SQL'leri verimli bir şekilde işler. Daha önce SDK olarak adlandırılıyordu (V2.2'de yeniden adlandırıldı). Daha fazla bilgi için bkz. Fixed Plan ile SQL yürütmeyi hızlandırma. |
| PG | Sistem tablolarındaki meta veri sorguları için ön uç yerel hesaplama. Kullanıcı tablosu verilerini okumaz. DDL deyimleri de PG kullanır. |
extended_info değerleri
extended_info alanı, Serverless Computing yürütmesinin kaynağını kaydeder:
**serverless_computing_source değeri** |
Anlamı |
|---|---|
user_submit |
Sorgu, Sorgu Kuyruğundan bağımsız olarak Serverless kaynaklarında çalıştırılmak üzere manuel olarak gönderildi. |
query_queue |
Belirtilen sorgu kuyruğundaki tüm sorgular Serverless kaynaklarında çalışır. Bkz. Sorgu kuyruğundaki sorguları yürütmek için Serverless Computing kaynaklarını kullanma. |
query_queue_rerun |
Sorgu, Sorgu Kuyruğunun büyük sorgu denetimi özelliği tarafından Serverless kaynaklarında otomatik olarak yeniden çalıştırıldı. Bkz. Büyük sorgu denetimi. |
serverless_computing_source değeri query_queue_rerun olduğunda, query_id_of_triggered_rerun alanı da görünür ve yeniden çalıştırma deyiminin orijinal sorgu kimliğini gösterir.
Ön koşullar
Yavaş sorgu günlüklerini görüntülemek için aşağıdaki izinlerden birine ihtiyacınız vardır:
View logs for all databases in an instance:
-
Superuser: Aşağıdaki komutu çalıştırın.
Alibaba Cloud account IDifadesini gerçek kullanıcı adıyla değiştirin. RAM kullanıcıları içinp4_AccountID(RAM kullanıcı adı değil, hesap kimliği) kullanın.ALTER USER "Alibaba Cloud account ID" SUPERUSER; -
pg_read_all_stats grubu (superuser olmayanlar için): Bu gruba eklenmeniz için bir superuser ile iletişime geçin.
-- Standard PostgreSQL authorization GRANT pg_read_all_stats TO "Alibaba Cloud account ID"; -- Simple permission model (SPM) CALL spm_grant('pg_read_all_stats', 'Alibaba Cloud account ID'); -- Schema-level permission model (SLPM) CALL slpm_grant('pg_read_all_stats', 'Alibaba Cloud account ID');
View logs for the current database only:
SPM veya SLPM'yi etkinleştirin ve kullanıcıyı db_admin rolüne ekleyin.
-- SPM
CALL spm_grant('<db_name>_admin', 'Alibaba Cloud account ID');
-- SLPM
CALL slpm_grant('<db_name>.admin', 'Alibaba Cloud account ID');
Normal kullanıcılar yalnızca geçerli veritabanındaki kendi sorgularını görüntüleyebilir ve ek kurulum gerekmez.
Yavaş sorgu günlüklerini görüntüleme
Hologres, yavaş sorgu günlüklerini görüntülemek için iki yol sunar. Görsel keşif için HoloWeb'i kullanın; özel filtreler, zaman aralıkları ve dışa aktarma için SQL'i kullanın.
| Yöntem | En uygun olduğu durum | Kısıtlamalar |
|---|---|---|
| HoloWeb | Görsel keşif ve eğilim analizi | Yalnızca superuser; yalnızca son 7 gün |
SQL (hg_query_log tablosu) |
Özel zaman aralıkları, filtreleme ve dışa aktarma | Uygun izinler gerekir |
HoloWeb'de görüntüleme
HoloWeb konsolunda oturum açın.
Üst gezinme çubuğunda, Diagnostics and Optimization seçeneğine tıklayın.
Sol gezinme bölmesinde, Historical Slow Query seçeneğine tıklayın.
Historical Slow Query sayfasının üst kısmındaki sorgu koşullarını ayarlayın. Parametrelerin açıklaması için bkz. Geçmiş Yavaş Sorgular.
-
Search seçeneğine tıklayın. Sonuçlar iki alanda görünür:
Sorgu Eğilimi Analizi: Zaman içinde yavaş ve başarısız sorguların sıklığını göstererek sorunlu dönemleri belirlemenize yardımcı olur.
Sorgular: Her yavaş veya başarısız sorgu için ayrıntılı bilgileri listeler. Görüntülenecek sütunları seçmek için Customize Columns seçeneğine tıklayın.
SQL ile sorgulama
Tam esneklik için hologres.hg_query_log tablosunu doğrudan sorgulayın. Hazır SQL örnekleri için bkz. Sorguları teşhis etme.
SQL parmak izi
V2.2'den itibaren, hg_query_log içindeki digest sütunu her sorgu için bir SQL parmak izi saklar. SELECT, INSERT, DELETE ve UPDATE için Hologres, parmak izi olarak bir MD5 karması hesaplar.
digest mi yoksa query_id mi kullanmalı:
Aynı türdeki sorguları gruplandırmak ve analiz etmek için
digestkullanın; örneğin, hangi sorgu desenlerinin ortalama olarak en çok CPU tükettiğini bulmak için.Belirli bir sorgu yürütmesini izlemek için
query_idkullanın; örneğin, belirli bir başarısız sorgunun tam ayrıntılarını almak için.
Parmak izleri nasıl hesaplanır:
Parmak izleri yalnızca SELECT, INSERT, DELETE ve UPDATE için toplanır.
Boşluklar yoksayılır (boşluklar, satır sonları, sekmeler).
Sabit değerler yoksayılır:
SELECT * FROM t WHERE a > 1veSELECT * FROM t WHERE a > 2aynı parmak izini üretir.Dizi eleman sayıları yoksayılır:
WHERE a IN (1, 2)veWHERE a IN (3, 4, 5)aynı parmak izini üretir.Sabit verili INSERT için, parmak izi eklenen satır sayısından etkilenmez.
Harf durumu Hologres sorgu kurallarını takip eder.
Parmak izi, veritabanı adını ve tam nitelikli şemayı içerir, bu nedenle
SELECT * FROM tveSELECT * FROM public.tyalnızcatpublicşemasındaysa ve her iki sorgu da aynı tabloya başvuruyorsa aynı parmak izine sahiptir.
Sorguları teşhis etme
Aşağıdaki SQL örnekleri en yaygın teşhis senaryolarını kapsar. Tüm sorgular hologres.hg_query_log hedeflidir.
Günlükteki tüm sorguları sayma (varsayılan: son bir ay):
SELECT count(*) FROM hologres.hg_query_log;
Örnek çıktı — son bir ayda 44 yavaş sorgu:
count
-------
44
(1 row)
Kullanıcı başına yavaş sorguları sayma:
SELECT usename AS "User",
count(1) AS "Query count"
FROM hologres.hg_query_log
GROUP BY usename
ORDER BY count(1) DESC;
Örnek çıktı:
User | Query count
---------------------+-------------
1111111111111111 | 27
2222222222222222 | 11
3333333333333333 | 4
4444444444444444 | 2
(4 rows)
Kimliğe göre belirli bir sorguyu arama:
SELECT * FROM hologres.hg_query_log WHERE query_id = '13001450118416xxxx';
Döndürülen alanların açıklaması için bkz. hg_query_log tablosu.
Son 10 dakikadaki kaynak yoğun sorguları bulma:
Hedef zaman pencerenize uyacak şekilde aralığı ayarlayın.
SELECT status AS "Status",
duration AS "Duration (ms)",
query_start AS "Start time",
(read_bytes / 1048576)::text || ' MB' AS "Data read",
(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 "Query ID",
query::char(30)
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '10 min'
ORDER BY duration DESC,
read_bytes DESC,
shuffle_bytes DESC,
memory_bytes DESC,
cpu_time_ms DESC,
physical_reads DESC
LIMIT 100;
Örnek çıktı:
Status | Duration (ms) | Start time | Data read | Memory | Shuffle | CPU time | Disk reads | Query ID | query
---------+---------------+------------------------+-----------+--------+---------+----------+------------+--------------------+--------------------------------
SUCCESS | 149 | 2021-03-30 23:45:01+08 | 0 MB | 25 MB | 454 MB | 321 s | 0 | 13001450118416xxxx | explain analyze SELECT * FROM
SUCCESS | 137 | 2021-03-30 23:49:18+08 | 247 MB | 21 MB | 213 MB | 803 s | 7771 | 13001491818416xxxx | explain analyze SELECT * FROM
FAILED | 53 | 2021-03-30 23:48:43+08 | 0 MB | 0 MB | 0 MB | 0 s | 0 | 13001484318416xxxx | SELECT ds::bigint / 0 FROM pub
(3 rows)
Senaryo: Bir örnek sürüm yükseltmesinden sonra yüksek CPU veya bellek kullanımını teşhis etme
Bu sorgu, Hologres örneğiniz yeni bir sürüme yükseltildikten sonra CPU veya bellek kullanımının arttığı durumlarda özellikle kullanışlıdır. Yüksek kaynak tüketimine neden olan sorguları belirlemek için:
CPU veya bellek kullanımının anormal derecede yüksek olduğu dönemi kapsamak için
WHEREyan tümcesindeki zaman aralığını ayarlayın. Örneğin,interval '10 min'ifadesini artışın olduğu zaman penceresine uygun bir aralıkla değiştirin.CPU yoğun sorguları bulmak için
ORDER BY cpu_time_ms DESCveya bellek yoğun sorguları bulmak içinORDER BY memory_bytes DESCekleyin.Belirli sorguları ve sahiplerini belirlemek için sonuçlardaki
query_id,usenamevequerysütunlarını kontrol edin, ardından bu sorguları buna göre analiz edin ve optimize edin.
Süreyi aşamalara göre ayırma:
Hangi aşamanın (optimization_cost, start_query_cost veya get_next_cost) gecikmenin çoğundan sorumlu olduğunu belirlemek için bunu kullanın. Her aşamayla ilgili ayrıntılar için hg_query_log tablosu bölümündeki süre döküm tablosuna bakın.
SELECT status AS "Status",
duration AS "Duration (ms)",
optimization_cost AS "Optimization cost (ms)",
start_query_cost AS "Startup cost (ms)",
get_next_cost AS "Execution cost (ms)",
duration - optimization_cost - start_query_cost - get_next_cost AS "Other cost (ms)",
query_id AS "Query ID",
query::char(30)
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '10 min'
ORDER BY duration DESC,
start_query_cost DESC,
optimization_cost,
get_next_cost DESC,
duration - optimization_cost - start_query_cost - get_next_cost DESC
LIMIT 100;
Örnek çıktı:
Status | Duration (ms) | Optimization cost (ms) | Startup cost (ms) | Execution cost (ms) | Other cost (ms) | Query ID | query
---------+---------------+------------------------+-------------------+---------------------+-----------------+--------------------+--------------------------------
SUCCESS | 4572 | 521 | 320 | 3726 | 5 | 6000260625679xxxx | -- /* user: wang ip: xxx.xx.x
SUCCESS | 1490 | 538 | 98 | 846 | 8 | 12000250867886xxxx | -- /* user: lisa ip: xxx.xx.x
SUCCESS | 1230 | 502 | 95 | 625 | 8 | 26000512070295xxxx | -- /* user: zhang ip: xxx.xx.
(3 rows)
Saat başına sorgu hacmini ve okunan veriyi görüntüleme (son 3 saat):
SELECT date_trunc('hour', query_start) AS query_start,
count(1) AS query_count,
sum(read_bytes) AS read_bytes,
sum(cpu_time_ms) AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
GROUP BY 1;
Trafiği dün aynı pencereyle karşılaştırma:
SELECT query_date,
count(1) AS query_count,
sum(read_bytes) AS read_bytes,
sum(cpu_time_ms) AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
GROUP BY query_date
UNION ALL
SELECT query_date,
count(1) AS query_count,
sum(read_bytes) AS read_bytes,
sum(cpu_time_ms) AS cpu_time_ms
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '1d 3h'
AND query_start <= now() - interval '1d'
GROUP BY query_date;
Bir zaman penceresindeki ilk başarısız sorguyu bulma:
SELECT status AS "Status",
regexp_replace(message, '\n', ' ')::char(150) AS "Error message",
duration AS "Duration (ms)",
query_start AS "Start time",
query_id AS "Query ID",
query::char(100) AS "Query"
FROM hologres.hg_query_log
WHERE query_start BETWEEN '2021-03-25 17:00:00'::timestamptz
AND '2021-03-25 17:42:00'::timestamptz + interval '2 min'
AND status = 'FAILED'
ORDER BY query_start ASC
LIMIT 100;
Örnek çıktı:
Status | Error message | Duration (ms) | Start time | Query ID | Query
--------+--------------------------------------------------------------+---------------+------------------------+--------------------+-------
FAILED | Query:[1070285448673xxxx] code: kActorInvokeError msg: "..." | 1460 | 2021-03-25 17:28:54+08 | 1070285448673xxxx | S...
FAILED | Query:[1016285560553xxxx] code: kActorInvokeError msg: "..." | 131 | 2021-03-25 17:28:55+08 | 1016285560553xxxx | S...
(2 rows)
Dünden yeni sorgu desenlerini bulma (toplam sayı):
Bir önceki güne kıyasla ilk kez görünen sorgular, parmak izine göre gruplandırılmış.
SELECT COUNT(1)
FROM (
SELECT DISTINCT t1.digest
FROM hologres.hg_query_log t1
WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
AND t1.query_start < CURRENT_DATE
AND NOT EXISTS (
SELECT 1
FROM hologres.hg_query_log t2
WHERE t2.digest = t1.digest
AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
)
AND digest IS NOT NULL
) AS a;
Örnek çıktı — dün 10 yeni sorgu deseni:
count
-------
10
(1 row)
Dünden yeni sorgu desenlerini bulma (türe göre):
SELECT a.command_tag,
COUNT(1)
FROM (
SELECT DISTINCT t1.digest, t1.command_tag
FROM hologres.hg_query_log t1
WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
AND t1.query_start < CURRENT_DATE
AND NOT EXISTS (
SELECT 1
FROM hologres.hg_query_log t2
WHERE t2.digest = t1.digest
AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
)
AND t1.digest IS NOT NULL
) AS a
GROUP BY 1
ORDER BY 2 DESC;
Örnek çıktı:
command_tag | count
-------------+-------
INSERT | 8
SELECT | 2
(2 rows)
Dünden yeni sorgu desenlerini bulma (ayrıntılı):
SELECT a.usename, a.status, a.query_id, a.digest,
a.datname, a.command_tag, a.query, a.cpu_time_ms, a.memory_bytes
FROM (
SELECT DISTINCT
t1.usename, t1.status, t1.query_id, t1.digest,
t1.datname, t1.command_tag, t1.query, t1.cpu_time_ms, t1.memory_bytes
FROM hologres.hg_query_log t1
WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
AND t1.query_start < CURRENT_DATE
AND NOT EXISTS (
SELECT 1
FROM hologres.hg_query_log t2
WHERE t2.digest = t1.digest
AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
)
AND t1.digest IS NOT NULL
) AS a;
Dünden yeni sorgu desenlerini bulma (saate göre):
SELECT to_char(a.query_start, 'HH24') AS query_start_hour,
a.command_tag,
COUNT(1)
FROM (
SELECT DISTINCT t1.query_start, t1.digest, t1.command_tag
FROM hologres.hg_query_log t1
WHERE t1.query_start >= CURRENT_DATE - INTERVAL '1 day'
AND t1.query_start < CURRENT_DATE
AND NOT EXISTS (
SELECT 1
FROM hologres.hg_query_log t2
WHERE t2.digest = t1.digest
AND t2.query_start < CURRENT_DATE - INTERVAL '1 day'
)
AND t1.digest IS NOT NULL
) AS a
GROUP BY 1, 2
ORDER BY 3 DESC;
Örnek çıktı — dün saat 21:00'de 8 INSERT deseni; saat 11:00 ve 13:00'te her biri 1 SELECT deseni:
query_start_hour | command_tag | count
------------------+-------------+-------
21 | INSERT | 8
11 | SELECT | 1
13 | SELECT | 1
(3 rows)
Parmak izine göre yavaş sorguları sayma (dün):
SELECT digest,
command_tag,
count(1)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '1 day'
AND query_start < CURRENT_DATE
GROUP BY 1, 2
ORDER BY 3 DESC;
Ortalama CPU süresi en yüksek olan ilk 10 sorgu desenini bulma (son gün):
SELECT digest,
avg(cpu_time_ms)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '1 day'
AND query_start < CURRENT_DATE
AND digest IS NOT NULL
AND usename != 'system'
AND cpu_time_ms IS NOT NULL
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;
Ortalama bellek kullanımı en yüksek olan ilk 10 sorgu desenini bulma (son hafta):
SELECT digest,
avg(memory_bytes)
FROM hologres.hg_query_log
WHERE query_start >= CURRENT_DATE - INTERVAL '7 day'
AND query_start < CURRENT_DATE
AND digest IS NOT NULL
AND memory_bytes IS NOT NULL
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;
Yapılandırma parametreleri
Nelerin günlüğe kaydedileceğini ve ne kadar ayrıntının yakalanacağını kontrol etmek için bu GUC parametrelerini kullanın.
log_min_duration_statement
Günlüğe kaydetme için minimum sorgu süresini kontrol eder.
Varsayılan: 100 ms (V2.2.7'den itibaren; önceki sürümlerde varsayılan 1.000 ms'dir).
Minimum değer: 100 ms.
Yavaş sorgu günlüklerini tamamen devre dışı bırakmak için
-1olarak ayarlayın.Yalnızca superuser'lar bunu veritabanı düzeyinde değiştirebilir. Normal kullanıcılar bunu oturum düzeyinde değiştirebilir.
Değişiklikler yalnızca yeni sorgular için geçerlidir.
-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_statement = '250ms';
-- Session level
SET log_min_duration_statement = '250ms';
log_min_duration_query_stats
Bir sorgu için yürütme istatistiklerinin yakalanıp yakalanmayacağını kontrol eder.
Varsayılan: 10 saniyeden uzun süren sorgular için istatistikleri kaydeder.
İstatistik toplamayı devre dışı bırakmak için
-1olarak ayarlayın.İstatistikler önemli depolama alanı kullanır. Bu değeri yalnızca hedefli sorun giderme için düşürün; ardından geri yükleyin.
Değişiklikler yalnızca yeni sorgular için geçerlidir.
-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_query_stats = '20s';
-- Session level
SET log_min_duration_query_stats = '20s';
log_min_duration_query_plan
Bir sorgu için yürütme planının yakalanıp yakalanmayacağını kontrol eder.
Varsayılan: 10 saniyeden uzun süren sorgular için planları kaydeder.
Plan yakalamayı devre dışı bırakmak için
-1olarak ayarlayın.Geçici sorun giderme için bunun yerine
EXPLAINkullanın; planı günlüğe kaydetmeden anında döndürür.Değişiklikler yalnızca yeni sorgular için geçerlidir.
-- Database level (superuser only)
ALTER DATABASE dbname SET log_min_duration_query_plan = '10s';
-- Session level
SET log_min_duration_query_plan = '10s';
Günlük saklama süresini değiştirme
V3.0.27'den itibaren, yavaş sorgu günlüklerinin ne kadar süreyle saklanacağını veritabanı düzeyinde değiştirebilirsiniz.
ALTER DATABASE <db_name> SET hg_query_log_retention_time_sec = 2592000;
| Yön | Ayrıntı |
|---|---|
| Birim | Saniye |
| Aralık | 3–30 gün (259.200–2.592.000 saniye) |
| Kapsam | Yalnızca yeni günlükler (mevcut günlükler orijinal saklama sürelerini korur) |
| Uygulama alanı | Yalnızca yeni bağlantılar |
| Temizleme | Süresi dolan günlükler eşzamansız olarak değil, hemen silinir |
Yavaş sorgu günlüklerini dışa aktarma
Uzun vadeli depolama veya analiz için hg_query_log verilerini bir Hologres iç tablosuna, MaxCompute yabancı tablosuna veya OSS'e dışa aktarın.
Dışa aktarmadan önce not edin:
INSERT INTO ... SELECT ... FROM hologres.hg_query_logkomutunu çalıştıran hesabınhg_query_logerişimine sahip olması gerekir. Örnek çapında dışa aktarmalar için superuser veyapg_read_all_statsizinleri gereklidir; aksi takdirde dışa aktarılan veriler eksik olur.query_startdizinlenmiş bir sütundur. Performansı artırmak ve kaynak kullanımını azaltmak için WHERE yan tümcesine her zaman dahil edin.-
WHERE yan tümcesinde
query_startüzerine işlevler uygulamayın; bu, dizinin kullanılmasını engeller.-- Correct: use range conditions on query_start directly WHERE query_start >= '2022-08-03' AND query_start < '2022-08-04' -- Incorrect: wrapping query_start in a function bypasses the index WHERE to_char(query_start, 'yyyymmdd') = '20220101'
Bir Hologres iç tablosuna dışa aktarma
-- Step 1: Create the target table
CREATE TABLE query_log_download (
usename text,
status text,
query_id text,
datname text,
command_tag text,
duration integer,
message text,
query_start timestamp with time zone,
query_date text,
query text,
result_rows bigint,
result_bytes bigint,
read_rows bigint,
read_bytes bigint,
affected_rows bigint,
affected_bytes bigint,
memory_bytes bigint,
shuffle_bytes bigint,
cpu_time_ms bigint,
physical_reads bigint,
pid integer,
application_name text,
engine_type text[],
client_addr text,
table_write text,
table_read text[],
session_id text,
session_start timestamp with time zone,
trans_id text,
command_id text,
optimization_cost integer,
start_query_cost integer,
get_next_cost integer,
extended_cost text,
plan text,
statistics text,
visualization_info text,
query_detail text,
query_extinfo text[]
);
-- Step 2: Export logs for a specific date
INSERT INTO query_log_download
SELECT
usename, status, query_id, datname, command_tag, duration, message,
query_start, query_date, query, result_rows, result_bytes, read_rows,
read_bytes, affected_rows, affected_bytes, memory_bytes, shuffle_bytes,
cpu_time_ms, physical_reads, pid, application_name, engine_type,
client_addr, table_write, table_read, session_id, session_start,
trans_id, command_id, optimization_cost, start_query_cost, get_next_cost,
extended_cost, plan, statistics, visualization_info, query_detail, query_extinfo
FROM hologres.hg_query_log
WHERE query_start >= '2022-08-03'
AND query_start < '2022-08-04';
Bir MaxCompute yabancı tablosuna dışa aktarma
-
MaxCompute'te, verileri almak için bölümlenmiş bir tablo oluşturun:
CREATE TABLE IF NOT EXISTS mc_holo_query_log ( username STRING COMMENT 'The username for the query', status STRING COMMENT 'The final status of the query: success or failed', query_id STRING COMMENT 'The query ID', datname STRING COMMENT 'The name of the database for the query', command_tag STRING COMMENT 'The type of query', duration BIGINT COMMENT 'The query duration in milliseconds (ms)', message STRING COMMENT 'The error message', query STRING COMMENT 'The text content of the query', read_rows BIGINT COMMENT 'The number of rows read by the query', read_bytes BIGINT COMMENT 'The number of bytes read by the query', memory_bytes BIGINT COMMENT 'The peak memory consumption on a single node (not exact)', shuffle_bytes BIGINT COMMENT 'The estimated number of bytes for data shuffle (not exact)', cpu_time_ms BIGINT COMMENT 'The total CPU time in milliseconds (not exact)', physical_reads BIGINT COMMENT 'The number of physical reads', application_name STRING COMMENT 'The query application type', engine_type ARRAY<STRING> COMMENT 'The engine used for the query', table_write STRING COMMENT 'The table to which the SQL statement writes data', table_read ARRAY<STRING> COMMENT 'The table from which the SQL statement reads data', plan STRING COMMENT 'The execution plan for the query', optimization_cost BIGINT COMMENT 'The time to generate the query execution plan', start_query_cost BIGINT COMMENT 'The query startup time', get_next_cost BIGINT COMMENT 'The query execution duration', extended_cost STRING COMMENT 'Other detailed costs of the query', query_detail STRING COMMENT 'Other extended information about the query (JSON format)', query_extinfo ARRAY<STRING> COMMENT 'Other extended information about the query (ARRAY format)', query_start STRING COMMENT 'The query start time', query_date STRING COMMENT 'The query start date' ) COMMENT 'Hologres instance query log' PARTITIONED BY (ds STRING COMMENT 'stat date') LIFECYCLE 365; ALTER TABLE mc_holo_query_log ADD PARTITION (ds=20220803); -
Hologres'te, MaxCompute tablosunu bir yabancı tablo olarak içe aktarın ve günlükleri dışa aktarın:
IMPORT FOREIGN SCHEMA project_name LIMIT TO (mc_holo_query_log) FROM SERVER odps_server INTO public; INSERT INTO mc_holo_query_log SELECT usename AS username, status, query_id, datname, command_tag, duration, message, query, read_rows, read_bytes, memory_bytes, shuffle_bytes, cpu_time_ms, physical_reads, application_name, engine_type, table_write, table_read, plan, optimization_cost, start_query_cost, get_next_cost, extended_cost, query_detail, query_extinfo, query_start, query_date, '20220803' FROM hologres.hg_query_log WHERE query_start >= '2022-08-03' AND query_start < '2022-08-04';
SSS
Hologres V1.1'de döndürülen satır sayıları ve okunan satır sayıları eksik.
Bu durum, etkilenen V1.1 sürümlerinde yavaş sorgu günlüğü toplamanın eksik olmasından kaynaklanır. V1.1.36 ile V1.1.49 arasında, tam istatistikleri toplamak için aşağıdaki GUC parametresini etkinleştirin:
-- Database level (recommended — set once per database)
ALTER DATABASE <db_name> SET hg_experimental_force_sync_collect_execution_statistics = ON;
-- Session level
SET hg_experimental_force_sync_collect_execution_statistics = ON;
<db_name> ifadesini veritabanı adınızla değiştirin.
Örneğiniz V1.1.36'dan önceyse, bkz. Yaygın yükseltme hazırlık hataları veya Hologres desteği ile iletişime geçin. Daha fazla bilgi için bkz. Daha fazla çevrimiçi desteği nasıl alabilirim? .
Bu davranış, V1.1.49 ve sonraki sürümlerde varsayılan olarak çözülmüştür.
Yavaş sorgu günlüklerindeki süre Fetching zamanını içerir mi?
Hayır. Hologres yavaş sorgu günlüklerindeki duration alanı yalnızca sunucu tarafı yürütme süresini ölçer; bu süre, plan oluşturma (optimization_cost), başlatma (start_query_cost) ve hesaplama (get_next_cost) aşamalarından oluşur. İstemcinin sonuç verilerini getirmesi için harcadığı zamanı (Fetching aşaması) içermez.
Quick BI gibi bir BI aracından gelen sorgular, HoloWeb'den veya komut satırından çalıştırılan aynı SQL deyimine kıyasla önemli ölçüde daha uzun sürüyorsa, yaygın nedenler şunlardır:
BI aracı, yüksek paralellik altında genel yanıt süresini artıran birden çok sorguyu eşzamanlı olarak gönderir.
get_next_costalanı, sonuç verilerinin sunucudan istemciye gönderilmesi için ağ aktarım süresini içerir. Yüksek birget_next_costdeğeri, yavaş sunucu tarafı hesaplamadan ziyade istemci tarafı veri alma gecikmesini yansıtabilir.
Sunucu tarafı ve istemci tarafı gecikmelerini ayırt etmek için sorguyu EXPLAIN ANALYZE ile çalıştırın ve get_next_cost alanını inceleyin. Düşük optimization_cost ve start_query_cost ile birlikte yüksek bir get_next_cost değeri, genellikle sürenin sorgu yürütmesinden ziyade veri aktarımı için harcandığını gösterir.
Sırada ne var
Örneğinizdeki etkin sorguları izlemek ve yönetmek için bkz. Sorguları yönetme.