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 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"

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"