NDB Cluster Configuration Files • ReservedConcurrentOperations • ReservedLocalScans • ReservedConcurrentTransactions • ReservedTransactionBufferMemory • ReservedConcurrentScans If the parameters just listed are not set, the reserved setting is 25% of transaction memory. The number of reserved records is per data node; these records are split among the threads handling them (LDM and TC threads) on each node. In most cases, it is sufficient to set  TransactionMemory  alone, and to allow the number of records in pools to be governed by its value. MaxNoOfConcurrentScans  limits the number of concurrent scans that can be active in each TC thread. This is important in guarding against cluster overload. MaxNoOfConcurrentOperations  limits the number of operations that can be active at any one time in updating transactions. (Simple reads are not affected by this parameter.) This number needs to be limited because it is necessary to preallocate memory for node failure handling, and a resource must be available for handling the maximum number of active operations in one TC thread when conmtending with node failures. It is imperative that  MaxNoOfConcurrentOperations  be set to the same number on all nodes (this can be done most easily by setting a value for it once, in the  [ndbd default]  section of the  config.ini  global configuration file). While its value can be increased using a rolling restart (see Section 23.5.5, “Performing a Rolling Restart of an NDB Cluster” ), decreasing it in this way is not considered safe due to the possibility of a node failure occurring during the rolling restart. It is possible to limit the size of a single transaction in NDB Cluster through the MaxDMLOperationsPerTransaction  parameter. If this is not set, the size of one transaction is limited by  MaxNoOfConcurrentOperations  since this parameter limits the total number of concurrent operations per TC thread. Schema memory size is controlled by the following set of configuration parameters: • MaxNoOfSubscriptions • MaxNoOfConcurrentSubOperations • MaxNoOfSubscribers • MaxNoOfAttributes • MaxNoOfTables • MaxNoOfOrderedIndexes • MaxNoOfUniqueHashIndexes • MaxNoOfTriggers The number of nodes and the number of LDM threads also have a major impact on the size of schema memory since the number of partitions in each table and each partition (and its fragment replicas) have to be represented in schema memory. In addition, a number of other records are allocated during startup. These are relatively small. Each block in each thread contains block objects that use memory. This memory size is also normally quite small compared to the other data node memory structures. 4235