Hi, I would like to know exactly what this metric ...
# questions-and-troubleshooting
u
Hi, I would like to know exactly what this metric
lake_get_tablet_metadata_count
means.
k
this is a counter for shared-data native table retrieving tablet metadata from remote storage.
u
@Kevin Cai This metric is increasing linearly. This means: 1. Metadata lookups on remote storage are steadily increasing. 2. If it's increasing linearly, could metadata lookups become increasingly slower? For example, could the response from show proc '/dbs' become slow, or could the stream load response fail? 3. Is there an upper limit for this metric? Can you elaborate or point me to documentation?
Copy code
lake_get_tablet_metadata_count{namespace="~~~"}
k
its an accumulated counter, so the number will increase infinitely, shall check the rate(lake_get_tablet_metadata_count), if there is an increment.
1
u
Is there an upper limit for this metric?
lake_get_tablet_metadata_latency_99
this metric also increase infinitely ?
k
Is there an upper limit for this metric?
no, it is a int64 counter.
1
u
Copy code
lake_get_tablet_metadata_latency_9999
lake_get_tablet_metadata_latency_99
lake_get_tablet_metadata_latency_90
lake_get_tablet_metadata_latency_80
lake_get_tablet_metadata_max_latency
Copy code
Is there a description of these metrics?
I can't find it in the official Starrocks documentation, so I'm asking.
u
@Kevin Cai I have a question. I upgraded from version 3.4.5 to 3.5.6. This is a shared-data deployment. After the upgrade, stream load kept failing. The symptoms were as follows: 1. I couldn’t access the information_schema tables. 2.
SHOW PROC '/dbs'
didn’t work either. 3. In the FE log, I found the following warning:
Copy code
starrocks-fe-2 fe 2025-10-21 21:58:59.763+09:00 WARN (tablet stat mgr|30)
[TabletStatMgr$CollectTabletStatJob.sendTasks():382] Skip sending tablet stat task
for partition db_name.table_name.948008 because exception: 
No alive backend or compute node in warehouse name: default_warehouse.
In case (3), all compute nodes were alive at the time this log appeared. I believe the problem occurred because metadata access failed, but I’d like to understand the exact cause and the proper resolution.
This symptom persisted, so I downgraded to 3.4.5. Even after downgrading, the problem persisted until stream load stopped and statements like "show proc '/dbs'" were executed.
k
what's the result of 'show compute nodes' or 'show backends' when the issue happens.
u
when the issue happens > always all compute node is alive
Even now, I couldn't access the information_schema tables. SHOW PROC '/dbs' didn't work either. I'm experiencing two symptoms. I'm using a spot instance for the compute node.