Hello Pi-Web, Friday, November 2, 2007, 6:46:26 PM, you wrote:
> On 8438 "<t" today we got a average T=111,1176819 > Min=0, Max=7211. (57 scans took above 1000, 6384 scans took less than 101). > The server is rather old and serving both web mail, pop3 and smtp. > And heavy usage of web mail does slow it down. This might be the case on the > slow scans. > The long scans is not at the same time, but from time to time during the day. > Still this should not "lock up" snfserver. True. Is the server at least a p3? I have many production servers running now (hundreds) that never lock up -- so it's not likely that I will be able to reproduce this error. I recommend running the SNFServer component from the command line and pumping it's output to a file -- you might even run it in a loop in a .cmd script so that it will be sure to restart after a crash. By sending it's output to a file we should be able to see any errors that it reports on it's way down. This will give us somewhere to look. > To call snf we use a dll of own development (pluged in to Merak mail server). > The call to snfclient is done using a: WaitforSingleObject with INFINITE wait > time. > (perhaps we should change this). I think that's correct. However, since you've developed your own DLL, you might consider bypassing the client altogether and connecting to the SNFServer w/ TCP using the XCI protocol. On your somewhat overloaded server, launching an external process may be lending to performance reduction at the very least. > When it finish - and it does - we get the snf result using GetExitCodeProcess. > This return zero (whitch is good, else all messages would be rejected) when > the > snfserver is in the "Could Not Connect!" state. Right. The client will return a fail-safe result when it has a problem getting a real result. I have changed the maximum number of evaluators in the code. I hope to be able to put it up on the server some time today. However, I doubt that has anything to do with what's happening here. The max eval error is handled properly in the code and recovery is very simple and tidy. This particular case has been around for as long as the engine has been in place. Also, the max evals number is 1024 (now 2048) while almost every scan recorded is well below 100. This does cause me to wonder if it's a good idea to change this safety check at all. It seems more likely that the test is doing what it should - and perhaps detecting some corrupt memory (you did say the server is old). The test was originally designed as a sanity check to avoid having the scanner run off in a tight loop allocating itself out of memory due to a corrupt rulebase file. Anyway --- I doubt that the max evals condition is directly connected to the SNF Server shutdowns. SNFServer should tell us why it shuts down when that happens and we should be able to get that info if we run it from the command line and capture it's output. Hope this helps, _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]>
