Is this a normal situation that duration is higher when the number of request decreased after reaching peak?

[sykp241095]

Original author: stardung86
Original time: 2023-03-20 01:18:43.798794
Original ID/Slug: 470 / is-this-a-normal-situation-that-duration-is-higher-when-the-number-of-request-decreased-after-reaching-peak

Hi, I’m new to TiDB and trying to test performance of it.

The below screenshot shows the statement OPS and the Duration and yes, trying to select massive amount of data.

I’m curious about the duration that shows shorter value when the number of OPS value is high and vice versa.

According to my short knowledge, I thought it should have long duration when OPS are high. Can anybody explain about this situation?

Thanks in advance!

스크린샷 2023-03-20 오전 10.12.102758×500 138 KB

[sykp241095]

Original author: winkyao
Original time: 2023-03-20 01:59:06.749435

Yes, it is a little weird. But it depends on your workload, there are some possible reason:

1. the select workload requiring the same range data that can be cache, so the duration are lower
2. Are there any background tasks are running? Like Auto Analyze(Introduction to Statistics | PingCAP Docs) and GC(GC Overview | PingCAP Docs)

[sykp241095]

Original author: stardung86
Original time: 2023-03-20 05:42:31.338316

Thanks for your answer!

1. Is there anyway to check what tables or rows are cached in the system?
2. Not sure about it. Those Auto Analyze and GC running every time when query has submitted? or if it’s not, how Can I see them running?

[sykp241095]

Original author: winkyao
Original time: 2023-03-20 06:15:15.880608

1. Block cache hit, Please refer to Key Monitoring Metrics of TiKV | PingCAP Docs
2. GC worker CPU in Grafana.
3. In terms of auto analyze, you can find the running and historical tasks by ‘show analyze status;’ SHOW ANALYZE STATUS | PingCAP Docs

[sykp241095]

Original author: stardung86
Original time: 2023-03-21 03:32:16.558944

Ah yes seems like cache system was worked at that time. Thanks for answering!