This message was deleted.
# troubleshooting
s
This message was deleted.
a
Cc - @Jay Yang
s
The default query timeout is set at
druid.server.http.defaultQueryTimeout=300000
(in millis = 5 minutes) which can be set on historicals, brokers and MMs. You can also set it in the query context with
timeout
. These values are governed by
druid.server.http.maxQueryTimeout
. There is also
druid.broker.http.readTimeout=PT15M
which defines the timeout for reading results from a historical into the broker. What settings do you have on these? Your timeout is occurring in 1 minute, right?
a
Thanks for your response, @Sergio Ferragut! Correct our timeout occurs after a minute, as we set it in the query because our SLA for these types of queries is under 1 min. On broker,
Copy code
druid.broker.http.readTimeOut=PT15M
On Historical,
Copy code
druid.server.http.maxIdleTime=PT5M
We do not have
druid.server.http.maxQueryTimeout
on Broker or Historical.
s
Okay, so your question is why is it taking so long?
What is the query? Perhaps we can help optimize how it is resolving that type of query.
One common reason is that group by queries on large cardinality dimensions bottleneck in the merge step on the broker since this step is executed in a single thread. Depending on the nature of the query, there are techniques that help, like rollup and approximations.
a
Correct, the question is, why are only some queries taking time and others are passing.. I will try to get a gist link for the query, but these type of queries have been running for years together… I think your point of large cardinality makes sense. I know for sure that the cardinality of my dimensions has increased recently. Let me check what can be done. Thanks a lot for your pointers, I will keep the thread updated on the progress