WMI, Reading Event Log Entries is VERY slow!
Shawn
I am jumping into this feet first. I have taken a Microsoft sample and
modified it very little. I want to write a Script (WSH,VBS) that will parse
the Event Log records for certain events form the Security Event Log on a
remote machine, it will also remember the last Record Number it obtained
(the day before) and continue from there. I am pretty sure I can do this by
looking at the Docs.
The issue I have is that as the sample walks through the event records it
gets slower and slower and slower till it is putting up 1 record to the
screen each 1-2 seconds. I tried just counting the number of records, still
slow, I tried not formatting the WMI Date (FormatDMTFDate) it had no effect.
WHY is this so memory intensive (my Event Log is set for 512K in size) and
continuously slower, it doesn't matter which property I retrieve, does
anyone have a clue?
I am on NT 4.0 Sp6a and WMI 1.5
............Here's the snippet:
set LogFileSet = GetObject("winmgmts:").ExecQuery("select * from
Win32_NTLogEvent where Logfile='Application'")
'Wscript.Echo "The Collection Count = " & LogFileSet.Count
'Wscript.Quit
For each Logfile in LogFileSet
strTmp = FormatDMTFDate(LogFile.TimeGenerated)
Wscript.Echo "Time Generated = " & strTmp
Next
TIA!
Shawn
Dominic Marks
Its not slow on my machine? Maybe a problem on with yours? I would reccomend
narrowing your query to only information you actually use.
Dominic
Shawn
Thanks for trying it Dominic! I obviously need to run this on another
machine and see if the problem persists. Everything else works real good??
Narrowing is a good idea but I wanted to solve the slowness issue first. It
should just fly through.....
thanks again!
Shawn
"Dominic Marks" <dominic_marks*@hotmail.com> wrote in message
news:#Q9OFpHNAHA.249@cppssbbsa05...
Manfred Braun
I think, it depends on a large number of facts:The speed of your WAN line,
the CPU of the remote machine (because that will execute your query) and
naturally, the number of events in the log. I work with such a script since
6 month, with very different results (but the same script). On a machine
having lots of errors (and ours are configured to hold up to 2MB) with
disks, and having WAN traffice, I had to wait up to 5 minutes, until the
display starts. But then, displaying the messages was nearly fast [ :-) ],
means up to 3-5 events per second.
If you simply want to have a central, consolidated message store for
importent things, try using the ScriptEventConsumer, let it's query fire
only on the spcified list of imoptent events and just let it write the
result to, for sample, a central SQL server. That's what I'll do since
month, but found no time to implement.
Additionally, If you've gotten the results (for sample, if you do it each
night), clear all the logs (you even have the option to make a backup).
Yust my two cents.
Best regards,
Manfred Braun
(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany
mailto:_mbr...@manfred.mannheim-netz.de
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)
"Shawn" <m...@viser.net> wrote in message news:#sXAA9JNAHA.258@cppssbbsa05...
Shawn
Manfred....
Yes I know about the fire event ability, I've actually got it working, but
figured this would be a less intrusive to the PDC because this way I don't
have a running process all the time.
We're interested in Events that only are registered on the PDC. Our PDC is
having problems so much that we actually have the MS NT/2000 Dev Engineers
helping with the issue they can't figure it out either....yet! They are
making us special DLL's and such so it can be debugged easier. So the Fire
Event method would not meet with great enthusiasm until the PDC problem is
solved :) I have to wait..... hence the querying method remotely.
I saw the Backup Event log and clear it and...and... and... That's what got
me interested. I have batch files that do what the script will do right now
except it outputs ALL dates, which is a bad thing when the security people
get tired of seeing repeats because of my limitations with batching and the
Dumpel tool from the reskit. So I told them I would write a script to do it
better, now I have a learning curve with WMI and it's syntax and methods
etc...... :)
Thanks for the 2 cents :)
Shawn
"Manfred Braun" <mbr...@manfred.mannheim-netz.de> wrote in message
news:OD2vSDVNAHA.196@cppssbbsa05...
Manfred Braun
It's me again......
Oops, it looks like DEFENS (in the WMI group) has the right answer......It
looks like, I was to lazy to read your script carefully.....I personally use
always async methods.
Sorry,
Manfred
Shawn
Dominic, Manfred, and others......
FIXED the problem!!!!
I finally got a reply from the WBEM Newsgroup, it was not my machine causing
the issue but rather the way I was calling the query, informative answer
below so I thought I would share it here seems how I had not cross posted
from there intially......Shawn
Hi Shawn:
The main reason is that what you are doing is a synchronous call and WMI is
having to queue up all the events in the log before it sends them to you.
This can burn a lot of memory and cause a lot of paging which drastically
slows performance.
You have two options:
1) Use the ExecQueryAsync call which will return instances to you
asynchronously as WMI gets them without queuing them up first. You will
need to define a sink (see the WMI docs, its pretty easy in script) to catch
them as they come in.
2) You can specify the return immediately and forward only flags to
ExecQuery to put yourself in semi-sync mode. The instances will be
delivered as they come in and not queued. You don't need to define a sink
for this one, just specify the flags in your code like so:
set LogFileSet = GetObject("winmgmts:").ExecQuery("select * from
Win32_NTLogEvent where Logfile='Application'",,&H30)
&H30 is the hex value of the logical OR of the two flags (&H20 and &H10).
You should see much better performance this way. Note, you can do this in
general with ExecQuery for any class. I recommend the semi-synch mechanism
as it gives you the same results without creating a sink subroutine.
Shawn
I just reposted that here :)
I Appreciate your attention though :) You've helped me many times in the
past not to mention a thousand others!
Shawn
"Manfred Braun" <mbr...@manfred.mannheim-netz.de> wrote in message
news:ODXCHVVNAHA.281@cppssbbsa05...
> It's me again......
>
> Oops, it looks like DEFENS (in the WMI group) has the right
answer......It
> looks like, I was to lazy to read your script carefully.....I personally
use
> always async methods.
>
> Sorry,
> Manfred
>
Manfred Braun
See inline.... :-)
"Shawn" <m...@viser.net> wrote in message news:OmQEhSVNAHA.75@cppssbbsa04...
> Manfred....
>
> Yes I know about the fire event ability, I've actually got it working, but
> figured this would be a less intrusive to the PDC because this way I don't
> have a running process all the time.
>
> We're interested in Events that only are registered on the PDC. Our PDC is
> having problems so much that we actually have the MS NT/2000 Dev Engineers
> helping with the issue they can't figure it out either....yet! They are
> making us special DLL's and such so it can be debugged easier. So the Fire
> Event method would not meet with great enthusiasm until the PDC problem is
> solved :) I have to wait..... hence the querying method remotely.
I run all my WMI queries to remote machines asynchronous!! This works like
real multithreading for scripts.....even if you run queries against 35
servers (my limit), it works like a charm....
>
> I saw the Backup Event log and clear it and...and... and... That's what
got
> me interested. I have batch files that do what the script will do right
now
> except it outputs ALL dates, which is a bad thing when the security people
> get tired of seeing repeats because of my limitations with batching and
the
> Dumpel tool from the reskit. So I told them I would write a script to do
it
> better, now I have a learning curve with WMI and it's syntax and methods
> etc...... :)
>
> Thanks for the 2 cents :)
> Shawn
>
>
>
>
>
>
>
> "Manfred Braun" <mbr...@manfred.mannheim-netz.de> wrote in message