Multi-File Disk Stores
Persistent events on channels and queues are stored in a file-based store that uses one or more files for each channel and queue on that realm. See the sections
Channel Attributes and
Queue Attributes for related information about the channel/queue type
Persistent.
If you set the value of the storage property Events Per Spindle for any channel or queue to 0, the store will persist all events for that channel or queue in a single disk file. If you set this storage property to a value greater than 0, the events for the channel or queue will be persisted in multiple files, also known as spindles. The maximum number of events that can be stored in a spindle is given by Events Per Spindle. When the capacity of a spindle is reached, a new spindle will be created. Each spindle has the file type mem.
See the description of
Events Per Spindle in the section
Storage Properties of Channels and Queues for related information.
Note:
It is possible that events in a spindle get flagged as "purged" (for example, if an event's time-to-live setting has been reached and the event is therefore no longer required). This can happen while there is still capacity to append new events at the end of the spindle, or even after the spindle capacity has been reached. However, space for purged events in a spindle is never freed up for storing new events; new events are only ever appended to the end of the most recent, unfilled spindle. Thus, a spindle is considered full, i.e. its capacity is reached, when the total number of purged and non-purged events in the spindle is equal to Events Per Spindle.
Having multiple spindles allows you to optimize the use of disk space by being able to delete individual spindles if they are no longer required. A single spindle will be deleted only if BOTH of the following conditions are met:
When the spindle is full, i.e. when the total number of purged and non-purged events defined by the
Events Per Spindle property are stored in it. Before the spindle gets full it cannot be deleted and a new spindle will not be created.
When all events from the spindle have been flagged as "purged". If there are non-purged events in the spindle, it will not be deleted or resized.
Note:
For stores of type Mixed, when only non-persistent events are used, new spindles still will be created; however, they will not contain the original events but instead just some metadata for each event.
Sizing Recommendation
Depending of the size of the events in a channel or queue, the value of Events Per Spindle should be adjusted properly. A smaller setting for Events Per Spindle is recommended for big events and a bigger setting for Events Per Spindle is recommended for small events.
As a general guideline, we suggest you use a spindle size no bigger than 1GB, and ensure that number of events stored per spindle is at least 1000. If the spindle files are too big, this can affect disk usage. Similarly, if the spindle files are too small, this can affect read/write performance.
Examples
Here are some examples for recommended values of events per spindle, based on event size:
small events (<1KB per event): 100 000 events per spindle.
medium events (>= 1KB and < 20KB per event): 50 000 events per spindle. This is the default value.
large events (>= 20KB and =< 100KB per event): 10 000 events per spindle.
very large events (>= 1MB per event): 1000 events per spindle (though you need to consider that 1000 events at 1MB each are going to require 1GB on disk).
The above values are just recommendations and using values different from the above will not break the system.
Note:
To override the default value of Events Per Spindle (currently 50 000), the following system Java property can be set on the client side:
com.softwareag.um.client.store.EventPerSpindle
Cache Recommendation
By default, caching is not enabled for multi-file disk stores. If you want to store events from a multi-file store in the cache, set the EnableStoreCaching and EnableCaching realm configuration properties to true and restart the Universal Messaging server instance.
When creating a channel with a multi-file store, set the
Cache on Reload and
Enable Caching channel storage properties to
true. For details about the channel storage properties, see
Storage Properties of Channels and Queues.
All multi-file disk stores use a default cache of size 10 000 events.
To cater for the publish/subscribe rates, available heap size and individual event sizes in your environment, the cache size can be changed with the system property
CACHE_SIZE, as described in the section
Server Parameters.
For example, when your publishers are fast and subscribers are slow, the event size is small and you have more than 10 000 events awaiting delivery, then subscribers might not be accessing cached events and are instead loading the events from disk. In this case you can increase the cache size in order to achieve a possible performance gain.