Important
Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.
In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.
Error: "Query execution memory use (XXX MB) has reached the maximum memory for its resource pool 'xxx' (XX%). “
This error occurs due to resource limits for users that you configured.maximum_ limit which you set on each node.
Issue Example: Query execution memory use (13118.
Solution: Perform the following troubleshooting steps.
1.
Check whether the resource limit you set for this pool is adequate.
SHOW USERS;
+--------------------+--------+-------------+------------+-----------------------+
| User | Type | Connections | Is deleted | Default resource pool |
+--------------------+--------+-------------+------------+-----------------------+
| 'general_user'@'%' | Native | 0 | | general |
| 'root'@'%' | Native | 1 | | |
+--------------------+--------+-------------+------------+-----------------------+Or
SELECT * FROM INFORMATION_SCHEMA.USERS;
+--------------+------+-------------+------------+---------------------+-----------------------+
| USER | HOST | CONNECTIONS | IS_DELETED | LAST_UPDATED | DEFAULT_RESOURCE_POOL |
+--------------+------+-------------+------------+---------------------+-----------------------+
| root | % | 1 | 0 | 2018-06-29 11:51:51 | |
| general_user | % | 0 | 0 | 2018-06-29 11:54:38 | general |
+--------------+------+-------------+------------+---------------------+-----------------------+The Default resource pool column indicates the default pool assigned to each user.
2.
If the limit is correct for the users, then consider what queries the users run.
3.
If 13 GB is not expensive for your cluster, then are you running many inexpensive queries concurrently? Consider spreading out your workload, or reducing concurrency.
4.
It is also possible that there is already one expensive query running, which is affecting the rest of your workload.
In CR to determine whether it is caused by one expensive query, or many inexpensive queries, or something expensive blocking other workloads and causing inexpensive queries to build up or queue.
sdb-report collect
Last modified: