On 2013-06-28 16:49, Matt wrote:
maybe the updates will cause a service restart/reset?
Rulebase updates (all updates in fact) happen without restarting
anything. SNF simply loads the new configuration, validates it, uses it
for new scans, and when all of the old scans are complete it drops th
I just looked through my history of the SNFclient.exe.err log and I was
a bit off. There were two small occurrences before 5/22, and both were
so small they were without a doubt unnoticeable. Here's my history
since installation on 4/10/2012 with the number of occurrences of "Could
Not Connec
I should add that Sniffer has been pretty much trouble free for us. We have
been using it since before the ARM research days (10+ years as a guess).
One of the specialized clients we host for goes through a cycle every few
years where they are very publically visible and there are a number of
atte
Matt:
Coincidentally (I hope) this happened to us on the 22nd also. It did not
stop working completely although we didn't get the throughput you did. We
also saw the messages indicating it was not able to open the file. Pretty
much the same message as in your first post and not one I've seen b
Eric,
I'm guessing based on what you were seeing, that it was unrelated to
what I was seeing. Sniffer never actually died, it just got over 100
times slower, and 1/8th of the time it timed out. This never happened
before 5/22, and this same server has been there for years, and the same
inst
I'll certainly look more closely next time. Hopefully I'll be migrated
before this happens again :)
Matt
On 6/28/2013 1:44 PM, Darin Cox wrote:
How about running performance monitor to watch disk I/O, mem, cpu,
page file, etc. over time in the hopes of catching one of the events?
Darin.
*F
Matt:
I mentioned in a previous post that we had experienced something similar at
about that time and resolved it a day or so later by re-installing sniffer
when service restarts, reboots and some basic troubleshooting did not give
us the results we needed. At this point that still seems to have
How about running performance monitor to watch disk I/O, mem, cpu, page
file, etc. over time in the hopes of catching one of the events?
Darin.
From: Matt
Sent: Friday, June 28, 2013 12:10 PM
To: Message Sniffer Community
Subject: [sniffer] Re: Slow processing times, errors
Pete,
I'm near po
Pete,
Just after the restart of the Sniffer service, times dropped back down
into the ms from 30+ seconds before, so what I am saying is that if I/O
was the issue, it was merely the trigger for something that put the
service in a bad state when it started. I/O issues are not persistent,
but
On 2013-06-28 12:10, Matt wrote:
I am looking to retool presently just because it's time. So if you
are convinced that this is due to low resources, don't concern
yourself with it.
Ok. It makes sense that the ~200 messages all at once could have happend
at the restart. SNFClient will keep tr
Pete,
I'm near positive that it's not system resources that are causing
Sniffer to not be able to _access the files_. I believe these errors
are a symptom and not the cause.
You have to keep in mind that on the messages that don't throw errors,
they were taking 30-90 seconds to scan, but im
On 2013-06-27 20:01, Matt wrote:
I'm
attaching a snippet of my log. About 100 lines past the start,
where you see a smattering of error messages, you then see a large
block of them while the Sniffer service is restarting, and then
after that no errors at
12 matches
Mail list logo