ALLOCATOR_USAGE

Provides real-time information on the allocation and reuse of memory pools for a Vertica node.

Provides real-time information on the allocation and reuse of memory pools for a Vertica node.

There are two memory pools in Vertica, global and SAL. The global memory pool is related to Vertica catalog objects. The SAL memory pool is related to the system storage layer. These memory pools are physical structures from which Vertica allocates and reuses portions of memory.

Within the memory pools, there are two allocation types. Both global and SAL memory pools include chunk and object memory allocation types.

  • Chunk allocations are from tiered storage, and are grouped into sizes, in bytes, that are powers of 2.

  • Object allocations are object types, for example, a table or projection. Each object assumes a set size.

The table provides detailed information on these memory pool allocations.

Column Name Data Type Description
NODE_NAME VARCHAR The name of the node from which Vertica has collected this allocator information.
POOL_NAME VARCHAR

One of two memory pools:

  • global: Memory pool is related to Vertica catalog objects.

  • SAL: Memory pool is related to the system storage layer.

ALLOCATION_TYPE VARCHAR

One of two memory allocation types:

  • chunk: Chunk allocations are grouped into sizes that are powers of 2.

  • object: Object allocations assume a set amount of memory based upon the specific object.

UNIT_SIZE INTEGER

The size, in bytes, of the memory allocation.

For example, if the allocation type is a table (an object type), then Vertica allots 8 bytes.

FREE_COUNT INTEGER

Indicates the count of blocks of freed memory that Vertica has reserved for future memory needs.

For example, if you delete a table, Vertica reserves the 8 bytes originally allotted for the table. The 8 bytes freed become 1 unit of memory that Vertica adds to this column.

FREE_BYTES INTEGER

Indicates the number of freed memory bytes.

For example, with a table deletion, Vertica adds 8 bytes to this column.

USED_COUNT INTEGER

Indicates the count of in-use blocks for this allocation.

For example, if your database includes two table objects, Vertica adds 2 to this column.

USED_BYTES INTEGER

The number of bytes of in-use blocks of memory.

For example, if your database includes two table objects, each of which assume 8 bytes, Vertica adds 16 to this column.

TOTAL_SIZE INTEGER Indicates the number of bytes that is the sum of all free and used memory.
CAPTURE_TIME TIMESTAMPTZ Indicates the current timestamp for when Vertica collected the for this table.
ALLOCATION_NAME VARCHAR

Provides the name of the allocation type.

  • If the allocation is an object type, provides the name of the object. For example, CAT::Schema. Object types can also have the name internal, meaning that the object is an internal data structure.

    Those object types that are not internal are prefaced with either CAT or SAL. Those prefaced with CAT indicate memory from the global memory pool. SAL indicates memory from the system storage memory pool.

  • If the allocation type is chunk, indicates a power of 2 in this field to represent the number of bytes assumed by the chunk. For example, 2^5.

Sample: how memory pool memory is allotted, retained, and freed

The following table shows sample column values based upon a hypothetical example. The sample illustrates how column values change based upon addition or deletion of a table object.

  • When you add a table object (t1), Vertica assumes a UNIT_SIZE of 8 bytes, with a USED_COUNT of 1.

  • When you add a second table object (t2), the USED_COUNT increases to 2. Since each object assumes 8 bytes, USED_BYTES increases to 16.

  • When you delete one of the two table objects, Vertica USED_COUNT decreases to 1, and USED_BYTES decreases to 8. Since Vertica retains the memory for future use, FREE_BYTES increases to 8, and FREE_COUNT increases to 1.

  • Finally, when you create a new table object (t3), Vertica frees the memory for reuse. FREE_COUNT and FREE_BYTES return to 0.

Column Names Add One Table Object (t1) Add a Second Table Object (t2) Delete a Table Object (t2) Create a New Table Object (t3)
NODE_NAME v_vmart_node0001 v_vmart_node0001 v_vmart_node0001 v_vmart_node0001
POOL_NAME global global global global
ALLOCATION_TYPE object object object object
UNIT_SIZE 8 8 8 8
FREE_COUNT 0 0 1 0
FREE_BYTES 0 0 8 0
USED_COUNT 1 2 1 2
USED_BYTES 8 16 8 16
TOTAL_SIZE 8 16 16 16
CAPTURE_TIME 2017-05-24 13:28:07.83855-04 2017-05-24 14:16:04.480953-04 2017-05-24 14:16:32.077322-04 2017-05-24 14:17:07.320745-04
ALLOCATION_NAME CAT::Table CAT::Table CAT::Table CAT::Table

Examples

The following example shows one sample record for a chunk allocation type, and one for an object type.

=> \x
Expanded display is on.


=> select * from allocator_usage;
-[ RECORD 1 ]---+-----------------------------
node_name       | v_vmart_node0004
pool_name       | global
allocation_type | chunk
unit_size       | 8
free_count      | 1069
free_bytes      | 8552
used_count      | 7327
used_bytes      | 58616
total_size      | 67168
capture_time    | 2017-05-24 13:28:07.83855-04
allocation_name | 2^3
.
.
.
-[ RECORD 105 ]-+------------------------------
node_name       | v_vmart_node0004
pool_name       | SAL
allocation_type | object
unit_size       | 128
free_count      | 0
free_bytes      | 0
used_count      | 2
used_bytes      | 256
total_size      | 256
capture_time    | 2017-05-24 14:44:30.153892-04
allocation_name | SAL::WOSAlloc
.
.
.