Workload Management

Certain TigerGraph operations, such as running online analytical processing (OLAP) queries that touch a lot of data, can be memory-intensive. TigerGraph provides the following mechanisms for you to manage workload in your TigerGraph instances.

Limit number of current built-in heavy queries

TigerGraph has a few built-in queries that are memory-intensive, here referred to as "heavy". These queries tend to be invoked by applications such as GraphStudio. You can set a limit of how many of these heavy queries are allowed to run concurrently by configuring the parameter RESTPP.WorkLoadManager.MaxHeavyBuiltinQueries with the gadmin config command.

For example, to set the maximum number of heavy built-in queries to 10, run the following command:

$ gadmin config set RESTPP.WorkLoadManager.MaxHeavyBuiltinQueries 10

You must restart the RESTPP service for the change to take effect.

Limit number of concurrent queries

You can use the RESTPP.WorkLoadManager.MaxConcurrentQueries parameter to set a limit of how many queries are allowed to be running concurrently. The count of these queries does not include the built-in heavy queries.

For example, to specify that there can only be 50 concurrent queries at a time, excluding the heavy built-in queries, change the value of the configuration parameter to 50 with the gadmin config command:

$ gadmin config set RESTPP.WorkLoadManager.MaxConcurrentQueries 50

If the maximum number of concurrent queries is reached, newly submitted queries are placed in a delay queue, and begin to run as the currently running queries finish. If the queue is at capacity, newly submitted queries are rejected. and you need wait until there is capacity to run the query again. You can adjust the size of the queue with the configuration parameter RESTPP.WorkLoadManager.MaxDelayQueueSize.

For example, to specify that a maximum 20 queries may remain in the queue, run the following command:

$ gadmin config set RESTPP.WorkLoadManager.MaxDelayQueueSize 20

You must restart the RESTPP service for the change to take effect.

Specify number of threads used by a query

You can specify the limit of the number of threads that can be used by one query through the Run Query REST endpoint.

For example, to specify a limit of four threads that can be used by a query, use the GSQL-THREAD-LIMIT parameter and set its value to 4:

Specify that the query run with a limit of 4 threads
curl -X POST -H "GSQL-THREAD-LIMIT: 4" -d '{"p":{"id":"Tom","type":"person"}}' "http://localhost:9000/query/social/hello"

Query Routing Schemes

In a distributed or replicated cluster, REST++ automatically routes queries to different GPEs, in order to spread the workload.

If GSQL-REPLICA header is used when invoking a query, this header overrides the routing scheme for that query.

Round Robin routing

The default query routing scheme is round-robin. The first query is managed by GPE 0, the next query by GPE 1, and so on. After the last GPE, the cycle returns to GPE 0.

Version 3.9.3 adds a system configuration parameter RESTPP.CPULoadAware.Mode to enable system administrators to select other query routing schemes:

  • Mode = 0 (default): Round-Robin

  • Mode = 1: CPU Load Aware

CPU Load Aware Query Routing

When this query routing mode is selected, REST++ tries to direct incoming queries to the GPEs that are currently less busy.

Specifically, the system periodically polls CPU usage data to find a GPE whose CPU usage percentage is below RESTPP.QueryRouting.TargetSelectionCPUThreshold (default 50).

If no GPE satisfies the CPU threshold condition, REST++ falls back to the default behavior (round-robin selection).

Example: Change CPU Load Threshold and Enable CPU Load Aware routing
$ gadmin config entry RESTPP.QueryRouting.TargetSelectionCPUThreshold 40
$ gadmin config entry RESTPP.QueryRouting.Mode 1

Specify replica to run query on

On a distributed cluster, you can specify on which replica you want a query to be run through the Run Query REST endpoint.

For example, to run the query on the primary cluster, use the GSQL-REPLICA header when running a query and set its value to 1:

Specify that the query run on the primary cluster
curl -X POST -H "GSQL-REPLICA: 1" -d '{"p":{"id":"Tom","type":"person"}}'
"http://localhost:9000/query/social/hello"