[sniffer] Re: IP Change on rulebase delivery system

[Pete McNeil]

On 2013-03-29 12:59, Richard Stupek wrote:
well when all else fails restarting snf seems to have corrected the 
issue for now.


In that case, it is likely that RAM fragmentation was involved. Dropping 
the process allowed the fragmentation to be cleared. (theory).


Best,
_M

--
Pete McNeil
Chief Scientist
ARM Research Labs, LLC
www.armresearch.com
866-770-1044 x7010
twitter/codedweller


#
This message is sent to you because you are subscribed to
 the mailing list .
This list is for discussing Message Sniffer,
Anti-spam, Anti-Malware, and related email topics.
For More information see http://www.armresearch.com
To unsubscribe, E-mail to: 
To switch to the DIGEST mode, E-mail to 
To switch to the INDEX mode, E-mail to 
Send administrative queries to  

[sniffer] Re: IP Change on rulebase delivery system

[Richard Stupek]

well when all else fails restarting snf seems to have corrected the issue
for now.


On Thu, Mar 28, 2013 at 11:50 AM, Darin Cox  wrote:

>   Richard,
>
> Do you have any directories with a large number of files (>4k)?  We had a
> similar problem a few months back with sniffer scans taking much longer to
> complete and sniffer temporary files being left over.  We finally traced
> the performance issues to a frequently accessed directory with thousands of
> files.  We’ve also seen issues in the past with directories with a large
> number of files being very poor performing.
>
> Darin.
>
>
>  *From:* Richard Stupek 
> *Sent:* Thursday, March 28, 2013 12:10 PM
> *To:* Message Sniffer Community 
> *Subject:* [sniffer] Re: IP Change on rulebase delivery system
>
>  Ok looking at the log I see quite a few messages taking over a second to
> process (samples below):
>
>  
> 
> 
> 
>
>  
> 
> 
> 
>  r='Normal'/>
> 
>
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>  
> 
> 
> 
> 
> 
> 
> 
>  r='Normal'/>
> 
>
>
>
> On Wed, Mar 27, 2013 at 4:42 PM, Pete McNeil  > wrote:
>
>> On 2013-03-27 17:16, Richard Stupek wrote:
>>
>>> The spikes aren't as prolonged at the present.
>>>
>>
>> Interesting. A short spike like that might be expected if the message was
>> longer than usual, but on average SNF should be very light-weight.
>>
>> One thing you can check is the performance data in your logs. That will
>> show how much time in cpu milleseconds it is taking for each scan and how
>> long the scans are in bytes. This might shed some light.
>>
>> http://www.armresearch.com/**support/articles/software/**
>> snfServer/logFiles/**activityLogs.jsp
>>
>> Look for something like  in each scan.
>>
>> >From the documentation:
>>
>>  - Scan Performance Monitoring (performance='yes')
>>> p:s = Setup time in milliseconds
>>> p:t = Scan time in milliseconds
>>> p:l = Scan length in bytes
>>> p:d = Scan depth (peak evaluator count)
>>>
>>>
>> Best,
>>
>>
>> _M
>>
>>
>> --
>> Pete McNeil
>> Chief Scientist
>> ARM Research Labs, LLC
>> www.armresearch.com
>> 866-770-1044 x7010 <866-770-1044%20x7010>
>> twitter/codedweller
>>
>>
>> ##**##**#
>> This message is sent to you because you are subscribed to
>> the mailing list .
>> This list is for discussing Message Sniffer,
>> Anti-spam, Anti-Malware, and related email topics.
>> For More information see http://www.armresearch.com
>> To unsubscribe, E-mail to: 
>> To switch to the DIGEST mode, E-mail to 
>> 
>> >
>> To switch to the INDEX mode, E-mail to 
>> Send administrative queries to  
>> 
>> >
>>
>>
>