mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-12-14 16:12:15 +01:00
lib/vmselectapi: properly calculate query timeout
vmselect passes query timeout to vmstorage in seconds.
The commit 20e9598254
treated it as timeout in nanoseconds.
Fix this in order to prevent from the following errors under vmstorage load:
cannot process vmselect request: cannot execute "search_v7": couldn't start executing the request in 0.000 seconds,
since -search.maxConcurrentRequests=... concurrent requests are already executed.
This commit is contained in:
parent
f7130d571d
commit
af58ac25f6
@ -17,6 +17,7 @@ The following tip changes can be tested by building VictoriaMetrics components f
|
||||
|
||||
|
||||
* BUGFIX: return correct query results over time series with gaps. The issue has been introduced in [v1.86.0](https://docs.victoriametrics.com/CHANGELOG.html#v1860).
|
||||
* BUGFIX: properly take into account the timeout passed by `vmselect` to `vmstorage` during query execution. This issue could result in the following error logs at `vmstorage` under load: `cannot process vmselect request: cannot execute "search_v7": couldn't start executing the request in 0.000 seconds, since -search.maxConcurrentRequests=... concurrent requests are already executed`. The issue has been introduced in [v1.86.0](https://docs.victoriametrics.com/CHANGELOG.html#v1860).
|
||||
|
||||
|
||||
## [v1.86.0](https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.86.0)
|
||||
|
@ -505,7 +505,7 @@ func (s *Server) processRPCWithConcurrencyLimit(ctx *vmselectRequestCtx, rpcName
|
||||
select {
|
||||
case s.concurrencyLimitCh <- struct{}{}:
|
||||
default:
|
||||
d := time.Duration(ctx.timeout)
|
||||
d := time.Duration(ctx.timeout) * time.Second
|
||||
if d > s.limits.MaxQueueDuration {
|
||||
d = s.limits.MaxQueueDuration
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user