The true meaning of Storage async snapshot duration

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: Storage async snapshot duration 代表的真正含义

| username: Raymond

Dear teachers, could you please explain which stage is monitored by the “Storage async snapshot duration” in Grafana’s tikv-details → storage? According to the official website, it represents the time spent on asynchronous snapshot processing, which should be less than 1 second in 99% of cases. However, what exactly does this asynchronous snapshot processing refer to? Could you provide a more detailed explanation?

| username: Ming | Original post link

Whether it goes through the Storage read pool or the Coprocessor pool thread pool, a Snapshot will be constructed before processing the request.

| username: Ming | Original post link

When TiKy writes under high pressure, the absence of a separate thread for obtaining snapshots may lead to extended snapshot acquisition times. The sell request uses index read, and poor network conditions can also affect the time taken to obtain the snapshot (since data and indexes are not stored on the same TiKV instance). Local Read is not used: To ensure data read consistency, our reads are always taken from the Region Leader. If the read request is sent to the TiKV node that happens to be the Leader of this Region, then we use local read to reduce additional overhead.

| username: Raymond | Original post link

Starting from version 5.0, isn’t the unify read pool used to handle all read requests?

| username: Raymond | Original post link

I don’t quite understand this part.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.