Hello Pi-Web, Friday, November 2, 2007, 2:01:30 PM, you wrote:
<snip/> > 31st oct. spam level raised, SNF was not validating the mails, the > "snfclient.exe.err" > shows lines like: > C:\Program Files\Merak\temp\2007110215013101AF.tmp: Could Not Connect! Could not connect indicates (most likely) that the SNFServer was down. Any time the client produces a .err it is unusual. Normal errors are reported to the SNFengine's log file(s). > We restrated the SNFserver (running as a service) and scans run smoothly > until today (2nd nov.), > where same issue happen: "Could Not Connect!". No errors in between. Something is knocking the server offline. > The log also show: (first line). > C:\Program Files\Merak\temp\200711021416181623.tmp: XCI Error!: > snf_EngineHandler::MaxEvals > Think this "MaxEvals" is what cause the error. > Is it due to the engine getting to many mails to evaluate? No. MaxEvals is a condition that is theoretically possible but extremely rare. As a message is scanned, little "creatures" called evaluators are created and re-used during the scan to identify any patterns that might exist in the message. The scan depth metric indicates the peak number of evaluators that were alive during the scan. Normally this number is between 60 and 150 though it changes all the time. In order to detect possible rulebase corruption there is a hard-coded limit to the number of evaluators that are allowed to live for a particular scan. It is possible that this number needs to be adjusted. That hasn't happened in a while - but since you're not getting any other errors (that we know of) that's the most likely scenario. The number of evaluators that are alive at one time for a particular scan depends on the active rules in the rulebase and the data in the message. The number is almost impossible to predict though it does (and should) normally stay in a fairly restricted range. > How do we avoid this? First, let's verify that there were no other errors. Please look in your snf log files and check for any <e/> elements. These will describe any other errors that occurred. If we find no other errors then I will make an adjustment to the maximum evals metric and we will go from there. While you are in your logs -- look a the <p/> (performance) elements and get an idea what the scan depth is typically. That will help us compare your system to others and to determine what the new limit should be. Originally the scan depth limit was designed to help detect possible corruption or unexpected conditions in the scanning engine. It's been there since the first version. It's a kind of sanity check -- Most likely it just needs to be adjusted since spam has changed so much over the years. In the early days scan depths were consistently well below 100 -- even in the 40-60 range. These days there are more abstracts in the rulebase so more creatures are required to get a comprehensive idea of what is in each message. Another thing I will look at is that this exception should be handled gracefully. I will look into this -- it may be that we want the SNFServer to fail under these conditions because it is a clue to something being out of adjustment -- In this case, probably just the limit setting. In the mean time, if you automatically restart your SNFServer after a failure it should be safe and will pick up any waiting clients before they fail in most cases. > We also see this error, but this might be while restarting the service: > C:\Program Files\Merak\temp\2007103119380319A0.tmp: XCI Error!: > snf_EngineHandler::FileError Most likely this is a request coming from an snfclient after the message file has already been handled and moved out of the temp folder. The FileError exception indicates that the SNFServer could not open and/or read the file. Normally this wouldn't appear in a .err file - it would appear in the normal logs. If this error was in a snfclient .err file then I may need to look at the client code again. Hope this helps, Thanks, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
