For "Many to One" rules a cache is kept in memory to keep track of the number of events occuring. The cache is kept for the field(s) specified in the Tracking fields and will count the number of occurences of events which meet the criterias specified in the Event Filter of the rule.

For example:

Create a rule which is trying to track unique combinations of User Name and Source IP and if there are 500 events occurring in an hour matching the criteria in the Event Filter an incident gets created.

The following settings would apply to this rule:

Event count: 500

Time Span: 60 mins

Table Size: 100 000

Tracking fields: User Name, souce IP address

With those settings the SSIM Correlation manager will create a cache of size 200 (100 000 / 500 ) to track the event count of each unique user and IP combination

and it will use a LRU (least recently used) algorithm to update this cache.

For example when SSIM get first unique user & IP combination (User&IP1) it will create first entry in cache with count 1. When it gets second unique combination
(User&IP2), it will add second entry with count 1. After some time the cache will look as below:
 

Combination                      Count
=======================================
User&IP1                            200
User&IP2                            199
User&IP3                            300
.
.
.
.
.
User&IP120                         499
.
.
User&IP200                         120
======================================

The size of the cache table is calculated as below:

Cache Size = Table Size / Event Count

In the above case:

100 000 / 500 = 200

If SSIM now gets a new User & IP combination, then to accommodate it in the cache, one of the entries in the cache will be replaced using the LRU algorithm.

That means the 201st User & IP combination which occurs in the 60 mins (time span)  will cause the entry which hasn't been updated for the  longest to be dropped from the cache.

To avoid this either the event count has to be lowered, resulting in an bigger cache size, or the time span can be lowered, to avoid the cache from overflowing.

Another potential solution to this problem would  be to introduce some grouping either by User or Source IP. Then multiple rules can be created using the grouping information  in the Event Filter of the rules.