[1.x] Flux Engine -- Query Controls

[timhallinflux]

With InfluxQL, we introduced a number of mechanisms to control queries over the course of the 1.x releases. These are documented here: https://docs.influxdata.com/influxdb/v1.7/troubleshooting/query_management

With the introduction of Flux into the 1.x release line as a parallel query engine, the question is whether similar controls need to exist for Flux.

It seems that the Flux engine can limit resource usage in a number of ways such as:

• Max Compute count - the number of go-routines allowed to service the query
• Max RAM - a counter of the memory a query is using, if the query goes over this limit the query is canceled. There are some soft/hard limits that can be leveraged as well.
• Concurrent query limits - Limit the number of concurrent queries.

Proposal:
The request is to determine the appropriate interface and controls to expose to limit resource exhaustion by the Flux engine. Providing sufficient guardrails for InfluxDB admins to put in place which are similar in principle to the ones that exist for the InfluxQL engine.

It may be that the end user doesn't necessarily know why their query exhausted resources, but we should be able to log queries which exceed the defined limits. This allows for admins to review expensive queries with their users and potentially communicate them as issues for review (and optimization).

[timhallinflux]

These are in OSS 2.x -- need config options for setting these in 1.x

query-concurrency
query-initial-memory-bytes
query-max-memory-bytes
query-memory-bytes
query-queue-size

[lesam]

Here's the new stanza in the config:

[flux-controller]
  query-concurrency = 0
  query-initial-memory-bytes = 0
  query-max-memory-bytes = 0
  total-max-memory-bytes = 0
  query-queue-size = 0

[lesam]

Note that zeros mean unlimited - this is new behaviour in 1.x, in 2.x some of the limits are required and default pretty low.

[lesam]

Closed in PR 21108