Resolution:
Description:
============

ActiveSpaces 2.0.1 documentation does not provide details on how much memory a metaspace requires regarding space allocation for each tuple and any overhead on each tuple and overhead on the metaspace when a new member joins. This knowledge base article will give some idea on ActiveSpaces memory management of tuples and its space members.

Environment:
==========

TIBCO ActiveSpaces


Tuple Field Sizes:

Short                         2 bytes
Int                              4 bytes
Long                          8 bytes
Float                          4 bytes
Double                       8 bytes
String                        8 bytes + UTF-8 encoded + 1 null char, that’s 1 byte per char for basic ascii + 1
Blob                           8 bytes + byte length
Datetime                    20 bytes (AS 2.0.1)
9 bytes (AS 2.0.2)

AS Security related memory overhead:

With data_encryption=true in policy:

Short: 32 bytes
Int: 32 bytes    
Long: 32 bytes
Float: 32 bytes    
Double: 32 bytes    
String: size + 32 bytes (min 32 bytes)
Blob: size + 32 bytes (min 32 bytes)
Datetime: 32 bytes

The minimum encrypted size is due to the IV + 1 block for the AES128CBC transformation on the plain encoded content.


The size of the Tuple is the aggregate of the fields + ~400 bytes of overhead per entry (not including additional indexes). Also, double the above to account for memory fragmentation to project memory requirements. Secondary indexes defined on the spaces requires more memory and TREE indexing will required more memory then HASH

The memory footprint formula for tuple is

Memory = (entry_overhead + payload_bytes) x (1 + replication_count) x (memory_fragmentation)

Memory = (400 bytes + payload_bytes) x (1 + replication_count) x 1.5 or 2

1.5 is a realistic value adjustment for memory_fragmentation although the worst case is 2.



Space and member size details:

Some experimental tests on Win64 with AS 2.0.1 were done to derive the following equation:

Overhead = 1,620 KB per member + 2.2 KB per space per member

So with 10 members and 100 spaces, that will be:

Overhead = (1,620 KB x 10 members) + (2.2 KB x 10 members x 100 spaces) or
Overhead = 16,200 KB + 2,200 KB = 18,400 KB

The overall footprint will be:

Footprint = initial process size + overhead

Footprint = 10,000 KB + 18,400 KB = 28,400 KB

These are just ballpark numbers and do not take into account memory fragmentation and other system dependent factors. The numbers above can be doubled to account for worst case memory fragmentation.

Space definition will not have any overhead of memory but each member will have 1,620KB of overhead. Hint: Space capacity, replication and eviction_policy attributes will play a vital role in memory management. While estimating the size, consider the degree of replication. While defining the space for metaspace we can specify the numbers tuples that can be stored using Space Attributes capacity replication and eviction policy.

Capacity: Specifies a maximum number of entries per seeder for the space. When the capacity is reached, the result of any additional request to put (insert) a new entry into the space will depend on the value of the eviction_policy attribute. The default value is -1 (nocapacity).

eviction_policy: If a put operation on a space would cause a seeder to exceed the space's capacity attribute, then the value of this attribute will dictate the result of the operation. If the value is 'none' (in quotes) then there will be no eviction and the operation will fail because the seeder is already at capacity. If the value is 'lru' (in quotes) then the seeder will evict another entry from the space using the 'least recently used' eviction method.