Oracle 5.0 Reference Manual page 1579

understand how
DataMemory
reflect actual usage by the cluster:
•
DataMemory
Effective Version
MySQL 5.0.0
Restart Type: N
This parameter defines the amount of space (in bytes) available for storing database records. The
entire amount specified by this value is allocated in memory, so it is extremely important that the
machine has sufficient physical memory to accommodate it.
The memory allocated by
record is currently of fixed size. (Even
is a 16-byte overhead on each record; an additional amount for each record is incurred because it
is stored in a 32KB page with 128 byte page overhead (see below). There is also a small amount
wasted per page due to the fact that each record is stored in only one page.
The maximum record size is currently 8052 bytes.
The memory space defined by
10 bytes per record. Each table row is represented in the ordered index. A common error among
users is to assume that all indexes are stored in the memory allocated by IndexMemory, but this
is not the case: Only primary key and unique hash indexes use this memory; ordered indexes use
the memory allocated by DataMemory. However, creating a primary key or unique hash index
also creates an ordered index on the same keys, unless you specify
creation statement. This can be verified by running
management client.
Currently, MySQL Cluster can use a maximum of 512 MB for hash indexes per partition, which
means in some cases it is possible to get
when
ndb_mgm -e "ALL REPORT MEMORYUSAGE"
This can also pose a problem with data node restarts on nodes that are heavily loaded with data.
You can force to create extra partitions for MySQL Cluster tables and thus have more memory
NDB
available for hash indexes by using the
to twice the number of rows that you expect to store in the table should be sufficient.
MAX_ROWS
The memory space allocated by
fragments. Each table is normally partitioned into the same number of fragments as there are data
nodes in the cluster. Thus, for each node, there are the same number of fragments as are set in
NoOfReplicas.
In addition, due to the way in which new pages are allocated when the capacity of the current page
is exhausted, there is an additional overhead of approximately 18.75%. When more
required, more than one new page is allocated, according to the following formula:
number of new pages = FLOOR(number of current pages × 0.1875) + 1
For example, if 15 pages are currently allocated to a given table and an insert to this table requires
additional storage space, the number of new pages allocated to the table is
+ 1 = FLOOR(2.8125) + 1 = 2 + 1 =
to the table. When the last of these 18 pages becomes full,
FLOOR(3.3750) + 1 = 3 + 1 = 4
allocated to the table is now 22.
Once a page has been allocated, it is currently not possible to return it to the pool of free pages,
except by deleting the table. (This also means that
MySQL Cluster Configuration Files
and are used, as they usually need to be updated to
IndexMemory
Type/Units
bytes
is used to store both the actual records and indexes. Each
DataMemory
columns are stored as fixed-width columns.) There
VARCHAR
is also used to store ordered indexes, which use about
DataMemory
Table is full
MAX_ROWS
consists of 32KB pages, which are allocated to table
DataMemory
3. Now 15 + 3 = 18 memory pages are allocated
new pages are allocated, so the total number of pages
1559
Default
80M
USING HASH
ndb_desc -d db_name table_name
errors in MySQL client applications even
shows significant free
option for TABLE. In general, setting
CREATE
FLOOR(18 × 0.1875) + 1 =
pages, once allocated to a given
DataMemory
Range/Values
1M - 1024G
in the index
in the
[1559].
DataMemory
is
DataMemory
FLOOR(15 × 0.1875)