On Thursday, December 2, 2004, 7:20:24 AM, cespears wrote: c> I started getting a large Number of files in my sniffer dir that end in c> .FIN ( like a thousand a day) a few that end in .ABT ( may be 12) and one c> .LOCK File. They never seem to go away.
Any of these files that are more than a few minutes old should be deleted. When running in peer-server mode (the default) each instance will sense how busy the system is by counting the files in the working directory... Everything slows down when more files are present. c> I normaly saw a few, but they dissapere by them self after a few seconds. c> These seem to be in large groups with time stamp in a small window of time. c> like 7:00 am then hours go by then more 12:58 and so on..???? This is happening when some event interrupts the normal operation of the system. From the spacing this might be due to a rulebase update (if not handled properly) or it could be some other event on your system that has a profound effect on CPU or I/O availability. You should find some indication of this event in your SNF log files - either a small group of errors, or a stretch of extremely long setup and/or processing times. Please take a moment to stop your server and sniffer then clean out all of the .FIN, .ABT, .SVR, .QUE, .WRK, and .FIN files that have been orphaned. Be sure you are running the latest version of SNF (V2-3.2). There were some recent changes in the timing functions that will make the system more resilient. It seems that you are probably not running a persistent instance of SNF since these issues almost never arise when a persistent instance is running. I recommend that you do run a persistent instance of SNF if you are not already. The newest version uses a .stat file to synchronize client instances to the persistent instance for optimum performance. This new mechanism is generally able to handle large spikes in system loads that might previously have caused a catastrophic failure --- so I'm pretty sure it should be able to resolve whatever is happening on your system at 0700 and 1258 etc. If it turns out that these are rulebase update times then please be sure that you are handling the final swap of the rulebase file using a pair of rename operations since this minimizes the time that the rulebase file will be unavailable. Hope this helps, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
