Hi, I have encountered a weird situation where querying for the count of “value” (my measurement) is extremely slow (17min to respond) after a given point, more precisely at 1416225559920ms. If I query for the point 1ms before (1416225559919ms), it quickly returns no answer. If I query for the time before with an actual answer (1416225559880ms) it returns in 0.1s. If I query for the point after (1416225559960ms) it again takes 17 minutes to respond. If I query sufficiently long after it is fast again (but I have not binary search to exactly where it gets slow).
The query in question is (but with different times substituted):
“q=SELECT count(“value”) FROM “autogen”.“database” WHERE time = 1416225559920ms AND “tag1” = ‘Val1’ AND “Tag2” = ‘Val2’”
If I instead ask for just “value” at time= 1416225559920ms it returns in 0.2 seconds.
The database consists of 186 series (as reported by ‘influx_inspect report -exact’).
In this database I experimented with adding a tag “week_nr” which includes the week_nr of the point, to see if this would let me parallelize the queries. As you see this tag is unspecified in the query. This could be relevant, but I don’t see why it would make the query slow for only these time-points. Could it be that 1416225559920ms is in some unfortunate slow block?
There is only one shard (retention policy 9000weeks).
The tsm-files is fully compacted at the time of query.
How to proceed debugging this?