Major Description
Has:
| servicers optional |
The number of service threads for the query. The default is 4 times the number of cores on the query node. Note that the overall node memory quota is this setting multiplied by the node-level memory-quota setting. Default : 32 Example : 8 |
integer (int32) |
The text "Note that the overall node memory quota is this setting multiplied by the node-level memory-quota setting" can be misread as this setting influencing the setting for quota. It may be better to omit this information here.
Of course "servicers" only determines the number of concurrent requests and doesn't impact any memory quota setting. It is probably unnecessary in this context to mention any relationship - but we must have had a reason (that I can't recall).
"servicers" does influence node memory quota (if set) as a minimum node quota is enforced to be 1 MiB per servicer - strictly:
(servicers + plus_servicers) * 1 MiB
(Most settings will be well above this so it is really an edge case only.)
"servicers" does influence the theoretical maximum amount of quota in use as would be the sum of the "servicers" number of active requests and their individual (all could be different) request-level quota settings. This should be obvious though as "servicers" controls the concurrently running requests.
So perhaps a new section on the page before "References" would be a better place to describe the inter-relation between the maximum number of active requests and the various memory quota settings? Perhaps something along the lines of:
Memory quota can be set at the cluster (node) and request level, and overall maximum requirement is determined by the maximum number of concurrently running requests and their quota settings. When set for the cluster (node), memory-quota is the upper boundary for the request-level settings. The number of servicers (both plus-servicers and servicers) determines how many requests can be processed at any one time. If memory-quota is not set (or is 0) then there is no per-request limit on memory use.
When set, the maximum quota use is further constrained by the node-quota and node-quota-val-percent settings. The node-quota is the soft memory target for the garbage collector and node-quota-val-percent determines what percentage of that should be the maximum amount of memory available for document memory. If node-quota is not set (is 0) then there is no overall restriction per node on document memory use.
The theoretical maximum quota requirement for document memory is therefore (assuming all are set):
min((servicers + plus-servicers) * memory-quota, node-quota * node-quota-val-percent / 100)
The limit can be enforced solely by either route or by both simultaneously with a memory-quota setting limiting individual requests and node-quota (+node-quota-val-percent) limiting the overall requirement.
The opposite reference:
| memory-quota optional |
Specifies the maximum amount of memory a request may use on this node, in MB. Note that the overall node memory quota is this setting multiplied by the node-level servicers setting. Specify 0 (the default value) to disable. When disabled, there is no quota. This parameter enforces a ceiling on the memory used for the tracked documents required for processing a request. It does not take into account any other memory that might be used to process a request, such as the stack, the operators, or some intermediate values. Within a transaction, this setting enforces the memory quota for the transaction by tracking the delta table and the transaction log (approximately). The cluster-level queryMemoryQuota setting specifies this property for the whole cluster. When you change the cluster-level setting, the node-level setting is over-written for all nodes in the cluster. In addition, the request-level memory_quota parameter specifies this property per request. If a request includes this parameter, it will be capped by the node-level memory-quota setting. Default : 0 Example : 4 |
integer (int32) |
also needs revision - again, only a theoretical maximum if the individual concurrently active requests have overridden (smaller only) this default setting with their request parameter.