Q & A Home
Customizing SNF
Errors
False Positives
Functionality
Integration
Log Files
Resellers
Result Codes
Rulebase Updates
Software
Spam
Subscriptions
Trials
Version 3 Architecture
Documentation Home

Functionality

Does version 3 require more RAM than version 2?

The new (V3) SNF does use more ram than the old SNF (V2).

GBUdb adds records over time as it learns new IP data.

The amount of RAM that will be used by GBUdb depends on how quickly it is learning new IPs and how frequently the database is condensed.

You can set an upper limit on the size of GBUdb in the configuration file:

<condense minimum-seconds-between='600'>
     <time-trigger on-off='on' seconds='86400'/>
     <posts-trigger on-off='off' posts='1200000'/>
     <records-trigger on-off='off' records='600000'/>
     <size-trigger on-off='on' megabytes='150'/>
</condense>

By default GBUdb will condense once per day or when it reaches 150 MBytes. Roughly twice as much RAM is needed for the condensing process since the GBUdb data must be copied to a new location. Condensing the GBUdb data is relatively expensive, so if sufficient RAM is not released by the first pass GBUdb will condense again every 10 minutes (600 seconds above) until GBUdb is below the size limit you have set.

I recommend you determine how much ram you want to make available for SNF and then set your <size-trigger/> to 40% of that size. This should leave room for GBUdb to condense and for the rest of SNF to fit inside your memory limit.

You can monitor your GBUdb status in your status.minute or status.second reports. Here is some sample data from one of our spamtrap processors. It has been stable for months so this should be indicative of what you would see on a busy machine that's been up for a while:

<gbudb>
     <size bytes="142606336"/>
     <records count="650314"/>
     <utilization percent="95.8431"/>
</gbudb>

For information on reading your status reports check out the Status Logs page.