The SQL Process was using 80% of the memory. I configured
it to use half of the memory so now its using about 55% of
it. SQL is running on a duel xeon 1200 ghz box and really
isnt getting hit that much. I dont know where to start
looking so any ideas would be helpful.If you have it configured at 50%, it makes "sense" that it is at 55% =consumption because there is some additional overhead that is not =included in the 50% cap. I know, it is a bit strange.
High memory usage does not necessarily indicate a problem or a memory =leak. SQL Serveris designed to grab memory and use it. It is only supposed to =relese
memory if other applications on the same box need it.
You may find this information helpful:
INF: SQL Server Memory Usage
http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;q321363
Does SQL Server have memory leaks? How can I tell? Why is SQL Server =using so much memory?
http://www.mssqlserver.com/faq/troubleshooting-memoryleak.asp
-- Keith
"Eddie" <anonymous@.discussions.microsoft.com> wrote in message =news:0f0d01c3aa07$bef276c0$a501280a@.phx.gbl...
> The SQL Process was using 80% of the memory. I configured > it to use half of the memory so now its using about 55% of > it. SQL is running on a duel xeon 1200 ghz box and really > isnt getting hit that much. I dont know where to start > looking so any ideas would be helpful.|||Keith
With regards to memory usage, I have 4GB of RAM and sqlservr.exe is using about 1.8GB or so Taskmgr shows it using. My server is NOT a heavy transaction SQL server, but I need the RAM for IIS
Can't I force throttle it back via Ent. Mgr to say like 1GB of RAM?
SQL is supposed to release RAM when not used, but I don't think it releases immediately which might cause the memory hits on my IIS service running? What do you think? Thanks
Steve|||You cam limit the amount of RAM that SQL Server uses. Probably the =easiest method would be to use the Enterprise Manager GUI. You could =also use sp_configure if you are comfortable with that method.
SQL Server will release memory ONLY if it needs to. It does not release =memory when SQL Server is not being used. The database server caches =data and query plans to memory and will only release it if other apps on =the box need it.
-- Keith
"steve schroeder" <anonymous@.discussions.microsoft.com> wrote in message =news:1F515B86-6AC2-49C8-B36D-FCF15CBE4FF5@.microsoft.com...
> Keith;
> > With regards to memory usage, I have 4GB of RAM and sqlservr.exe is =using about 1.8GB or so Taskmgr shows it using. My server is NOT a =heavy transaction SQL server, but I need the RAM for IIS.
> Can't I force throttle it back via Ent. Mgr to say like 1GB of RAM? > SQL is supposed to release RAM when not used, but I don't think it =releases immediately which might cause the memory hits on my IIS service =running? What do you think? Thanks.
> > Stevesql
Showing posts with label utilization. Show all posts
Showing posts with label utilization. Show all posts
Wednesday, March 21, 2012
Monday, March 19, 2012
High CPU Utilization on Periodic basis
My db is supporting a high traffic website. It seems that
every 2-3 days, the total cpu utilization suddenly shoots
up to 100% and stays there until I restart sql server.
I've used perf monitor to log total cpu, sql cpu, sql
threads, etc over a period of days and it is relatively
stable with plenty of resources until this sudden spike
occurs. This is not gradual, and I do not see any sudden
spike in memory. Spike is only in cpu, and also # of sql
threads (goes up to around 100). Average total cpu
normally is around 50%.
I've run the blocker script, but there do not seem to be
any blocks going on. I've run profiler to try to catch any
never-ending sp calls or sp hogs, but haven't been able to
catch it either.
It may be that we just need to add more resources, but the
fact that this occurs on a semi-regular schedule is what
is troubling. We don't appear to be getting a sudden
increase in traffic during the problm. Could this be
symptom of an attack? It doesn't seem to be a slow leak-
type, since the graphs show a sudden spike, not a ramp up.
What is unusual, is that the sp that shows up in profiler
as a the most predominant hog during the abnormal high cpu
utlization condition, doesn't normally show up under
normal conditions.What is your system setup (Win Vers, SQL Vers, Service Packs)|||some thoughts...
* cpu spikes like this are very common. I do a lot of tuning and see this
regulalry...
* you would not expect to see blocking during a CPU spike you would expect
to see lower CPU if there are significant waits due to blocking...
* you point out that a particular proc seems to be run during the spike?
Have you looked at the cpu utilization for this proc?
* many times... when I tune things like this... it's not a single big,
expensive proc that causes the spike... but a piece of app code that is
causing a large number of relatively inexpensive procs to be run VERY
frequently. Don't rule that option out by looking just for procs that are
consuming a lot of CPU...
* all the symptoms you're outlined are consistent with a pretty run of the
mill application induced spike. Nothing that seems to strongly suggest an
attack of any kind. Don't rule that out of course... but I'd focus on
profiler to see what sql is using most of the CPU...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||Turn off autogrow for dbs, log files and especially temp db.....manage
growth manually.
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||I agree that you should manage growth by doing it manually (or pre arranged
scheduled task) but you should leave auto grow on just in case. Hopefully
you won't ever use it if you manage it correctly but it is a good fail safe.
--
Andrew J. Kelly
SQL Server MVP
"Tiffany" <tiffany.edwards@.vodafone.net> wrote in message
news:evJbGui9DHA.3404@.TK2MSFTNGP09.phx.gbl...
> Turn off autogrow for dbs, log files and especially temp db.....manage
> growth manually.
>
> "Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
> news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> > My db is supporting a high traffic website. It seems that
> > every 2-3 days, the total cpu utilization suddenly shoots
> > up to 100% and stays there until I restart sql server.
> >
> > I've used perf monitor to log total cpu, sql cpu, sql
> > threads, etc over a period of days and it is relatively
> > stable with plenty of resources until this sudden spike
> > occurs. This is not gradual, and I do not see any sudden
> > spike in memory. Spike is only in cpu, and also # of sql
> > threads (goes up to around 100). Average total cpu
> > normally is around 50%.
> >
> > I've run the blocker script, but there do not seem to be
> > any blocks going on. I've run profiler to try to catch any
> > never-ending sp calls or sp hogs, but haven't been able to
> > catch it either.
> >
> > It may be that we just need to add more resources, but the
> > fact that this occurs on a semi-regular schedule is what
> > is troubling. We don't appear to be getting a sudden
> > increase in traffic during the problm. Could this be
> > symptom of an attack? It doesn't seem to be a slow leak-
> > type, since the graphs show a sudden spike, not a ramp up.
> >
> > What is unusual, is that the sp that shows up in profiler
> > as a the most predominant hog during the abnormal high cpu
> > utlization condition, doesn't normally show up under
> > normal conditions.
> >
>|||the bad thing about profiler is that it won't catch infinite loop
problems.
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
try checking the current activity in enterprise manager (or check
sysprocesses) to find the spid(s) that are using the high cpu and go
from there.
i've had the exact same problem as you (although it was a random
event). i simply killed the problematic spid and everything returned to
normal.
Cynthia wrote:
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.|||<<
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
depends on how you define an infinite loop. Loops just mean you're doing the
same thing over and over. Of course there will be stmt ending events...
you will not see the end event if there is a bug in sql and the command
truly never ends, but that is quite rare. A command may run for a while...
but it will eventually end... and if something is running THAT long...
it's VERY easy to find the culprit in sysprocesses as you point out.
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"ch" <ch@.dontemailme.com> wrote in message
news:40337E84.50912EDB@.dontemailme.com...
> the bad thing about profiler is that it won't catch infinite loop
> problems.
> you can get the sqlstatement started event (which doesn't show you how
> much it cpu it is using), and you'll never get the sqlstatement ended
> event because it's in an infinite loop. the ended event is the one that
> will show you how much cpu the statement or sp used.
> try checking the current activity in enterprise manager (or check
> sysprocesses) to find the spid(s) that are using the high cpu and go
> from there.
> i've had the exact same problem as you (although it was a random
> event). i simply killed the problematic spid and everything returned to
> normal.
>
> Cynthia wrote:
> > My db is supporting a high traffic website. It seems that
> > every 2-3 days, the total cpu utilization suddenly shoots
> > up to 100% and stays there until I restart sql server.
> >
> > I've used perf monitor to log total cpu, sql cpu, sql
> > threads, etc over a period of days and it is relatively
> > stable with plenty of resources until this sudden spike
> > occurs. This is not gradual, and I do not see any sudden
> > spike in memory. Spike is only in cpu, and also # of sql
> > threads (goes up to around 100). Average total cpu
> > normally is around 50%.
> >
> > I've run the blocker script, but there do not seem to be
> > any blocks going on. I've run profiler to try to catch any
> > never-ending sp calls or sp hogs, but haven't been able to
> > catch it either.
> >
> > It may be that we just need to add more resources, but the
> > fact that this occurs on a semi-regular schedule is what
> > is troubling. We don't appear to be getting a sudden
> > increase in traffic during the problm. Could this be
> > symptom of an attack? It doesn't seem to be a slow leak-
> > type, since the graphs show a sudden spike, not a ramp up.
> >
> > What is unusual, is that the sp that shows up in profiler
> > as a the most predominant hog during the abnormal high cpu
> > utlization condition, doesn't normally show up under
> > normal conditions.
>|||Here's an update for anyone interested.
I believe the problem was just a combination of high
traffic and the need for some sp optimization. There were
no looping or blocking sps.
Here's how I troubleshot the problem:
I used sql profiler over a period of time to see which sps
were cpu hogs during the normal periods and the high cpu
periods. The profiler brought to my attention one sp
during the normal periods, and another sp during the peak
periods. Both of these sps were each doing both a select
and insert or update on tables that contained many rows.
I then used query analyzer's execution plan together with
profiler to monitor the performance of those sps on an
offline database copy.
I then measured the performance with and without indexes
on the tables (the tables originally did not have indexes
on columns being searched) I saw a tremendous select
performance improvment with the indexes, with negligible
impact to insertion performance.
I added the indexes to the live servers and got fantastic
results. Now, the cpus are probably underutilized as the
total and sql cpu % is well below 10%. It has been running
like this for many days now and the response time of the
website is excellent.
Thanks to all of those of provided feedback.
>--Original Message--
>My db is supporting a high traffic website. It seems that
>every 2-3 days, the total cpu utilization suddenly shoots
>up to 100% and stays there until I restart sql server.
>I've used perf monitor to log total cpu, sql cpu, sql
>threads, etc over a period of days and it is relatively
>stable with plenty of resources until this sudden spike
>occurs. This is not gradual, and I do not see any sudden
>spike in memory. Spike is only in cpu, and also # of sql
>threads (goes up to around 100). Average total cpu
>normally is around 50%.
>I've run the blocker script, but there do not seem to be
>any blocks going on. I've run profiler to try to catch
any
>never-ending sp calls or sp hogs, but haven't been able
to
>catch it either.
>It may be that we just need to add more resources, but
the
>fact that this occurs on a semi-regular schedule is what
>is troubling. We don't appear to be getting a sudden
>increase in traffic during the problm. Could this be
>symptom of an attack? It doesn't seem to be a slow leak-
>type, since the graphs show a sudden spike, not a ramp up.
>What is unusual, is that the sp that shows up in profiler
>as a the most predominant hog during the abnormal high
cpu
>utlization condition, doesn't normally show up under
>normal conditions.
>.
>
every 2-3 days, the total cpu utilization suddenly shoots
up to 100% and stays there until I restart sql server.
I've used perf monitor to log total cpu, sql cpu, sql
threads, etc over a period of days and it is relatively
stable with plenty of resources until this sudden spike
occurs. This is not gradual, and I do not see any sudden
spike in memory. Spike is only in cpu, and also # of sql
threads (goes up to around 100). Average total cpu
normally is around 50%.
I've run the blocker script, but there do not seem to be
any blocks going on. I've run profiler to try to catch any
never-ending sp calls or sp hogs, but haven't been able to
catch it either.
It may be that we just need to add more resources, but the
fact that this occurs on a semi-regular schedule is what
is troubling. We don't appear to be getting a sudden
increase in traffic during the problm. Could this be
symptom of an attack? It doesn't seem to be a slow leak-
type, since the graphs show a sudden spike, not a ramp up.
What is unusual, is that the sp that shows up in profiler
as a the most predominant hog during the abnormal high cpu
utlization condition, doesn't normally show up under
normal conditions.What is your system setup (Win Vers, SQL Vers, Service Packs)|||some thoughts...
* cpu spikes like this are very common. I do a lot of tuning and see this
regulalry...
* you would not expect to see blocking during a CPU spike you would expect
to see lower CPU if there are significant waits due to blocking...
* you point out that a particular proc seems to be run during the spike?
Have you looked at the cpu utilization for this proc?
* many times... when I tune things like this... it's not a single big,
expensive proc that causes the spike... but a piece of app code that is
causing a large number of relatively inexpensive procs to be run VERY
frequently. Don't rule that option out by looking just for procs that are
consuming a lot of CPU...
* all the symptoms you're outlined are consistent with a pretty run of the
mill application induced spike. Nothing that seems to strongly suggest an
attack of any kind. Don't rule that out of course... but I'd focus on
profiler to see what sql is using most of the CPU...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||Turn off autogrow for dbs, log files and especially temp db.....manage
growth manually.
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||I agree that you should manage growth by doing it manually (or pre arranged
scheduled task) but you should leave auto grow on just in case. Hopefully
you won't ever use it if you manage it correctly but it is a good fail safe.
--
Andrew J. Kelly
SQL Server MVP
"Tiffany" <tiffany.edwards@.vodafone.net> wrote in message
news:evJbGui9DHA.3404@.TK2MSFTNGP09.phx.gbl...
> Turn off autogrow for dbs, log files and especially temp db.....manage
> growth manually.
>
> "Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
> news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> > My db is supporting a high traffic website. It seems that
> > every 2-3 days, the total cpu utilization suddenly shoots
> > up to 100% and stays there until I restart sql server.
> >
> > I've used perf monitor to log total cpu, sql cpu, sql
> > threads, etc over a period of days and it is relatively
> > stable with plenty of resources until this sudden spike
> > occurs. This is not gradual, and I do not see any sudden
> > spike in memory. Spike is only in cpu, and also # of sql
> > threads (goes up to around 100). Average total cpu
> > normally is around 50%.
> >
> > I've run the blocker script, but there do not seem to be
> > any blocks going on. I've run profiler to try to catch any
> > never-ending sp calls or sp hogs, but haven't been able to
> > catch it either.
> >
> > It may be that we just need to add more resources, but the
> > fact that this occurs on a semi-regular schedule is what
> > is troubling. We don't appear to be getting a sudden
> > increase in traffic during the problm. Could this be
> > symptom of an attack? It doesn't seem to be a slow leak-
> > type, since the graphs show a sudden spike, not a ramp up.
> >
> > What is unusual, is that the sp that shows up in profiler
> > as a the most predominant hog during the abnormal high cpu
> > utlization condition, doesn't normally show up under
> > normal conditions.
> >
>|||the bad thing about profiler is that it won't catch infinite loop
problems.
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
try checking the current activity in enterprise manager (or check
sysprocesses) to find the spid(s) that are using the high cpu and go
from there.
i've had the exact same problem as you (although it was a random
event). i simply killed the problematic spid and everything returned to
normal.
Cynthia wrote:
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.|||<<
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
depends on how you define an infinite loop. Loops just mean you're doing the
same thing over and over. Of course there will be stmt ending events...
you will not see the end event if there is a bug in sql and the command
truly never ends, but that is quite rare. A command may run for a while...
but it will eventually end... and if something is running THAT long...
it's VERY easy to find the culprit in sysprocesses as you point out.
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"ch" <ch@.dontemailme.com> wrote in message
news:40337E84.50912EDB@.dontemailme.com...
> the bad thing about profiler is that it won't catch infinite loop
> problems.
> you can get the sqlstatement started event (which doesn't show you how
> much it cpu it is using), and you'll never get the sqlstatement ended
> event because it's in an infinite loop. the ended event is the one that
> will show you how much cpu the statement or sp used.
> try checking the current activity in enterprise manager (or check
> sysprocesses) to find the spid(s) that are using the high cpu and go
> from there.
> i've had the exact same problem as you (although it was a random
> event). i simply killed the problematic spid and everything returned to
> normal.
>
> Cynthia wrote:
> > My db is supporting a high traffic website. It seems that
> > every 2-3 days, the total cpu utilization suddenly shoots
> > up to 100% and stays there until I restart sql server.
> >
> > I've used perf monitor to log total cpu, sql cpu, sql
> > threads, etc over a period of days and it is relatively
> > stable with plenty of resources until this sudden spike
> > occurs. This is not gradual, and I do not see any sudden
> > spike in memory. Spike is only in cpu, and also # of sql
> > threads (goes up to around 100). Average total cpu
> > normally is around 50%.
> >
> > I've run the blocker script, but there do not seem to be
> > any blocks going on. I've run profiler to try to catch any
> > never-ending sp calls or sp hogs, but haven't been able to
> > catch it either.
> >
> > It may be that we just need to add more resources, but the
> > fact that this occurs on a semi-regular schedule is what
> > is troubling. We don't appear to be getting a sudden
> > increase in traffic during the problm. Could this be
> > symptom of an attack? It doesn't seem to be a slow leak-
> > type, since the graphs show a sudden spike, not a ramp up.
> >
> > What is unusual, is that the sp that shows up in profiler
> > as a the most predominant hog during the abnormal high cpu
> > utlization condition, doesn't normally show up under
> > normal conditions.
>|||Here's an update for anyone interested.
I believe the problem was just a combination of high
traffic and the need for some sp optimization. There were
no looping or blocking sps.
Here's how I troubleshot the problem:
I used sql profiler over a period of time to see which sps
were cpu hogs during the normal periods and the high cpu
periods. The profiler brought to my attention one sp
during the normal periods, and another sp during the peak
periods. Both of these sps were each doing both a select
and insert or update on tables that contained many rows.
I then used query analyzer's execution plan together with
profiler to monitor the performance of those sps on an
offline database copy.
I then measured the performance with and without indexes
on the tables (the tables originally did not have indexes
on columns being searched) I saw a tremendous select
performance improvment with the indexes, with negligible
impact to insertion performance.
I added the indexes to the live servers and got fantastic
results. Now, the cpus are probably underutilized as the
total and sql cpu % is well below 10%. It has been running
like this for many days now and the response time of the
website is excellent.
Thanks to all of those of provided feedback.
>--Original Message--
>My db is supporting a high traffic website. It seems that
>every 2-3 days, the total cpu utilization suddenly shoots
>up to 100% and stays there until I restart sql server.
>I've used perf monitor to log total cpu, sql cpu, sql
>threads, etc over a period of days and it is relatively
>stable with plenty of resources until this sudden spike
>occurs. This is not gradual, and I do not see any sudden
>spike in memory. Spike is only in cpu, and also # of sql
>threads (goes up to around 100). Average total cpu
>normally is around 50%.
>I've run the blocker script, but there do not seem to be
>any blocks going on. I've run profiler to try to catch
any
>never-ending sp calls or sp hogs, but haven't been able
to
>catch it either.
>It may be that we just need to add more resources, but
the
>fact that this occurs on a semi-regular schedule is what
>is troubling. We don't appear to be getting a sudden
>increase in traffic during the problm. Could this be
>symptom of an attack? It doesn't seem to be a slow leak-
>type, since the graphs show a sudden spike, not a ramp up.
>What is unusual, is that the sp that shows up in profiler
>as a the most predominant hog during the abnormal high
cpu
>utlization condition, doesn't normally show up under
>normal conditions.
>.
>
High CPU Utilization on Periodic basis
My db is supporting a high traffic website. It seems that
every 2-3 days, the total cpu utilization suddenly shoots
up to 100% and stays there until I restart sql server.
I've used perf monitor to log total cpu, sql cpu, sql
threads, etc over a period of days and it is relatively
stable with plenty of resources until this sudden spike
occurs. This is not gradual, and I do not see any sudden
spike in memory. Spike is only in cpu, and also # of sql
threads (goes up to around 100). Average total cpu
normally is around 50%.
I've run the blocker script, but there do not seem to be
any blocks going on. I've run profiler to try to catch any
never-ending sp calls or sp hogs, but haven't been able to
catch it either.
It may be that we just need to add more resources, but the
fact that this occurs on a semi-regular schedule is what
is troubling. We don't appear to be getting a sudden
increase in traffic during the problm. Could this be
symptom of an attack? It doesn't seem to be a slow leak-
type, since the graphs show a sudden spike, not a ramp up.
What is unusual, is that the sp that shows up in profiler
as a the most predominant hog during the abnormal high cpu
utlization condition, doesn't normally show up under
normal conditions.What is your system setup (Win Vers, SQL Vers, Service Packs)|||some thoughts...
* cpu spikes like this are very common. I do a lot of tuning and see this
regulalry...
* you would not expect to see blocking during a CPU spike you would expect
to see lower CPU if there are significant waits due to blocking...
* you point out that a particular proc seems to be run during the spike?
Have you looked at the cpu utilization for this proc?
* many times... when I tune things like this... it's not a single big,
expensive proc that causes the spike... but a piece of app code that is
causing a large number of relatively inexpensive procs to be run VERY
frequently. Don't rule that option out by looking just for procs that are
consuming a lot of CPU...
* all the symptoms you're outlined are consistent with a pretty run of the
mill application induced spike. Nothing that seems to strongly suggest an
attack of any kind. Don't rule that out of course... but I'd focus on
profiler to see what sql is using most of the CPU...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||Turn off autogrow for dbs, log files and especially temp db.....manage
growth manually.
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||I agree that you should manage growth by doing it manually (or pre arranged
scheduled task) but you should leave auto grow on just in case. Hopefully
you won't ever use it if you manage it correctly but it is a good fail safe.
Andrew J. Kelly
SQL Server MVP
"Tiffany" <tiffany.edwards@.vodafone.net> wrote in message
news:evJbGui9DHA.3404@.TK2MSFTNGP09.phx.gbl...
> Turn off autogrow for dbs, log files and especially temp db.....manage
> growth manually.
>
> "Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
> news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
>|||the bad thing about profiler is that it won't catch infinite loop
problems.
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
try checking the current activity in enterprise manager (or check
sysprocesses) to find the spid(s) that are using the high cpu and go
from there.
i've had the exact same problem as you (although it was a random
event). i simply killed the problematic spid and everything returned to
normal.
Cynthia wrote:
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.|||<<
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
depends on how you define an infinite loop. Loops just mean you're doing the
same thing over and over. Of course there will be stmt ending events...
you will not see the end event if there is a bug in sql and the command
truly never ends, but that is quite rare. A command may run for a while...
but it will eventually end... and if something is running THAT long...
it's VERY easy to find the culprit in sysprocesses as you point out.
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"ch" <ch@.dontemailme.com> wrote in message
news:40337E84.50912EDB@.dontemailme.com...
> the bad thing about profiler is that it won't catch infinite loop
> problems.
> you can get the sqlstatement started event (which doesn't show you how
> much it cpu it is using), and you'll never get the sqlstatement ended
> event because it's in an infinite loop. the ended event is the one that
> will show you how much cpu the statement or sp used.
> try checking the current activity in enterprise manager (or check
> sysprocesses) to find the spid(s) that are using the high cpu and go
> from there.
> i've had the exact same problem as you (although it was a random
> event). i simply killed the problematic spid and everything returned to
> normal.
>
> Cynthia wrote:
>
>
every 2-3 days, the total cpu utilization suddenly shoots
up to 100% and stays there until I restart sql server.
I've used perf monitor to log total cpu, sql cpu, sql
threads, etc over a period of days and it is relatively
stable with plenty of resources until this sudden spike
occurs. This is not gradual, and I do not see any sudden
spike in memory. Spike is only in cpu, and also # of sql
threads (goes up to around 100). Average total cpu
normally is around 50%.
I've run the blocker script, but there do not seem to be
any blocks going on. I've run profiler to try to catch any
never-ending sp calls or sp hogs, but haven't been able to
catch it either.
It may be that we just need to add more resources, but the
fact that this occurs on a semi-regular schedule is what
is troubling. We don't appear to be getting a sudden
increase in traffic during the problm. Could this be
symptom of an attack? It doesn't seem to be a slow leak-
type, since the graphs show a sudden spike, not a ramp up.
What is unusual, is that the sp that shows up in profiler
as a the most predominant hog during the abnormal high cpu
utlization condition, doesn't normally show up under
normal conditions.What is your system setup (Win Vers, SQL Vers, Service Packs)|||some thoughts...
* cpu spikes like this are very common. I do a lot of tuning and see this
regulalry...
* you would not expect to see blocking during a CPU spike you would expect
to see lower CPU if there are significant waits due to blocking...
* you point out that a particular proc seems to be run during the spike?
Have you looked at the cpu utilization for this proc?
* many times... when I tune things like this... it's not a single big,
expensive proc that causes the spike... but a piece of app code that is
causing a large number of relatively inexpensive procs to be run VERY
frequently. Don't rule that option out by looking just for procs that are
consuming a lot of CPU...
* all the symptoms you're outlined are consistent with a pretty run of the
mill application induced spike. Nothing that seems to strongly suggest an
attack of any kind. Don't rule that out of course... but I'd focus on
profiler to see what sql is using most of the CPU...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||Turn off autogrow for dbs, log files and especially temp db.....manage
growth manually.
"Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.
>|||I agree that you should manage growth by doing it manually (or pre arranged
scheduled task) but you should leave auto grow on just in case. Hopefully
you won't ever use it if you manage it correctly but it is a good fail safe.
Andrew J. Kelly
SQL Server MVP
"Tiffany" <tiffany.edwards@.vodafone.net> wrote in message
news:evJbGui9DHA.3404@.TK2MSFTNGP09.phx.gbl...
> Turn off autogrow for dbs, log files and especially temp db.....manage
> growth manually.
>
> "Cynthia" <anonymous@.discussions.microsoft.com> wrote in message
> news:0cae01c3f592$333ef460$3a01280a@.phx.gbl...
>|||the bad thing about profiler is that it won't catch infinite loop
problems.
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
try checking the current activity in enterprise manager (or check
sysprocesses) to find the spid(s) that are using the high cpu and go
from there.
i've had the exact same problem as you (although it was a random
event). i simply killed the problematic spid and everything returned to
normal.
Cynthia wrote:
> My db is supporting a high traffic website. It seems that
> every 2-3 days, the total cpu utilization suddenly shoots
> up to 100% and stays there until I restart sql server.
> I've used perf monitor to log total cpu, sql cpu, sql
> threads, etc over a period of days and it is relatively
> stable with plenty of resources until this sudden spike
> occurs. This is not gradual, and I do not see any sudden
> spike in memory. Spike is only in cpu, and also # of sql
> threads (goes up to around 100). Average total cpu
> normally is around 50%.
> I've run the blocker script, but there do not seem to be
> any blocks going on. I've run profiler to try to catch any
> never-ending sp calls or sp hogs, but haven't been able to
> catch it either.
> It may be that we just need to add more resources, but the
> fact that this occurs on a semi-regular schedule is what
> is troubling. We don't appear to be getting a sudden
> increase in traffic during the problm. Could this be
> symptom of an attack? It doesn't seem to be a slow leak-
> type, since the graphs show a sudden spike, not a ramp up.
> What is unusual, is that the sp that shows up in profiler
> as a the most predominant hog during the abnormal high cpu
> utlization condition, doesn't normally show up under
> normal conditions.|||<<
you can get the sqlstatement started event (which doesn't show you how
much it cpu it is using), and you'll never get the sqlstatement ended
event because it's in an infinite loop. the ended event is the one that
will show you how much cpu the statement or sp used.
depends on how you define an infinite loop. Loops just mean you're doing the
same thing over and over. Of course there will be stmt ending events...
you will not see the end event if there is a bug in sql and the command
truly never ends, but that is quite rare. A command may run for a while...
but it will eventually end... and if something is running THAT long...
it's VERY easy to find the culprit in sysprocesses as you point out.
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"ch" <ch@.dontemailme.com> wrote in message
news:40337E84.50912EDB@.dontemailme.com...
> the bad thing about profiler is that it won't catch infinite loop
> problems.
> you can get the sqlstatement started event (which doesn't show you how
> much it cpu it is using), and you'll never get the sqlstatement ended
> event because it's in an infinite loop. the ended event is the one that
> will show you how much cpu the statement or sp used.
> try checking the current activity in enterprise manager (or check
> sysprocesses) to find the spid(s) that are using the high cpu and go
> from there.
> i've had the exact same problem as you (although it was a random
> event). i simply killed the problematic spid and everything returned to
> normal.
>
> Cynthia wrote:
>
>
High CPU utilization on Merge Replication with SQL 2005 Mobile
I have a question for anyone who mas some tips/pointers for optimizing SQL merge replication publications.
The front end web server is running IIS 6.0 on Windows 2003 x86 Server Standard (Server A). The back end database server is running SQL 2000 Standard on Windows 2003 x86 Standard (Server B). The merge replication clients connect via HTTPS over the Internet from a custom C#.NET 2005 application using SQL 2005 Mobile running on Windows Mobile 5.0 (Client).
The publication itself has several filters on it. The entry point uses the user's Windows username to start the filter. Based on the user, it then filters the records in multiple tables. There are 68 articles and 44 filter statements. The filters extend multiple layers deep, in other words they are not all filtering off the HOST_NAME() variable, some tables filter from records in tables that filter from the HOST_NAME() variable. The publication is set to minimize data sent to the clients, and considers a subscription out of date if it has not synced in the last 4 days. All the rowguids are indexed as well.
There are approximately 35 clients actively using the application at any given time. On average, a client will initiate a merge replication 3-4 times per hour from 8am-5pm. Generally, a sync will take between 10 seconds and 2 minutes to complete, with most of them being around 30 seconds on average.
When a client starts a sync, there is a spike to about 50% on the server's CPU graph. If multiple clients attempt to sync at the same time the CPU utilization can be pushed to 100% for extended periods (more than 30 seconds).
I recently completed a project to increase the bandwidth available to the clients, and plan to reduce the number of filters significantly (although this will obviously increase the amount of data going to the clients and the storage needs on the individual devices). I also plan on changing the setting to not minimize the amount of data sent to the clients.
Having said all that, does anyone have any information about how to further optimize merge publications to mobile clients? The next publication will be on SQL 2005 x64 Standard if I can solve the issues in the text environment. I would like to enhance the publication as much as possible to make the end user experience better than it currently is.
Thanks!
You're talking about CPU usage at the publisher, correct?
Can you double check that all columns involved in the merge join filters are indexed as well? If the columns are not indexed, this leads to table scans during syncs which can result in high CPU usage.
Are you also getting conflicts? There's a performance issue (which will be fixed in SP1) that can slow things down due to missing indexes on some conflict tables, but this shouldn't be an issue unless you're getting hundreds and hundreds of conflicts.
ALso, how "deep" are your filters? Do the merge join filters have 1 to many relationships, or many to many (see the @.join_unique_key parameter). The more levels deep you are, or any level that contains a @.join_unique_key = 0, can negatively affect performance.
Regardless, you can always run profiler at the publisher and trace a single subscriber to see which procs are consuming the most time. You can start with RPC:completed or SP:completed, and just grab the duration. You'll quickly see which procs are the problematic one. From there, you can then enable SP:StatmentEnded and enable ExecutionPlan to see exactly what statement and why it's slow.
|||
Indexes were definetly a piece of the puzzle. The @.join_unique_key was also in play, so thanks for putting me on to that one. For anyone else who is using Merge Replication with SQL Mobile, there are 2 very useful articles:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_replmergepartitioned.asp
High CPU utilization on Merge Replication with SQL 2005 Mobile
I have a question for anyone who mas some tips/pointers for optimizing SQL merge replication publications.
The front end web server is running IIS 6.0 on Windows 2003 x86 Server Standard (Server A). The back end database server is running SQL 2000 Standard on Windows 2003 x86 Standard (Server B). The merge replication clients connect via HTTPS over the Internet from a custom C#.NET 2005 application using SQL 2005 Mobile running on Windows Mobile 5.0 (Client).
The publication itself has several filters on it. The entry point uses the user's Windows username to start the filter. Based on the user, it then filters the records in multiple tables. There are 68 articles and 44 filter statements. The filters extend multiple layers deep, in other words they are not all filtering off the HOST_NAME() variable, some tables filter from records in tables that filter from the HOST_NAME() variable. The publication is set to minimize data sent to the clients, and considers a subscription out of date if it has not synced in the last 4 days. All the rowguids are indexed as well.
There are approximately 35 clients actively using the application at any given time. On average, a client will initiate a merge replication 3-4 times per hour from 8am-5pm. Generally, a sync will take between 10 seconds and 2 minutes to complete, with most of them being around 30 seconds on average.
When a client starts a sync, there is a spike to about 50% on the server's CPU graph. If multiple clients attempt to sync at the same time the CPU utilization can be pushed to 100% for extended periods (more than 30 seconds).
I recently completed a project to increase the bandwidth available to the clients, and plan to reduce the number of filters significantly (although this will obviously increase the amount of data going to the clients and the storage needs on the individual devices). I also plan on changing the setting to not minimize the amount of data sent to the clients.
Having said all that, does anyone have any information about how to further optimize merge publications to mobile clients? The next publication will be on SQL 2005 x64 Standard if I can solve the issues in the text environment. I would like to enhance the publication as much as possible to make the end user experience better than it currently is.
Thanks!
You're talking about CPU usage at the publisher, correct?
Can you double check that all columns involved in the merge join filters are indexed as well? If the columns are not indexed, this leads to table scans during syncs which can result in high CPU usage.
Are you also getting conflicts? There's a performance issue (which will be fixed in SP1) that can slow things down due to missing indexes on some conflict tables, but this shouldn't be an issue unless you're getting hundreds and hundreds of conflicts.
ALso, how "deep" are your filters? Do the merge join filters have 1 to many relationships, or many to many (see the @.join_unique_key parameter). The more levels deep you are, or any level that contains a @.join_unique_key = 0, can negatively affect performance.
Regardless, you can always run profiler at the publisher and trace a single subscriber to see which procs are consuming the most time. You can start with RPC:completed or SP:completed, and just grab the duration. You'll quickly see which procs are the problematic one. From there, you can then enable SP:StatmentEnded and enable ExecutionPlan to see exactly what statement and why it's slow.
|||
Indexes were definetly a piece of the puzzle. The @.join_unique_key was also in play, so thanks for putting me on to that one. For anyone else who is using Merge Replication with SQL Mobile, there are 2 very useful articles:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_replmergepartitioned.asp
High CPU utilization on distributor and sp_MSget_repl_commands
Hi,
In SQL 2005 Replication Monitor i was not seeing details for any of the publications on the "Distributor to Subscriber Histroy Tab" so i decided to stop and start synchronisation on this one publication. At this time there were approximayely 20000 undistributed commands. After the stop/start of the distribution agent, i started seeing messages like "x trasactions with x commands were delivered". Then i went and restarted all the other distribution agents using the Replication Monitor.
Has anyone experienced this kind of a behaviour?
The second issue is that our trasnactional replication looked to have caught up but i was supprised find that the distribution server was running at 100%. A profiler trace of the distribution database revealed that sp_MSget_repl_commands procedure was being executed and costing approximately in excess of 400 000 reads, 7000 in CPU cost and 15sec in duration. To me it looked as if sp_MSget_repl_commands has chosen an inefficient execution plan but then realised i couldn't recompile system procedures. I think a stop and start of the SQL instance is the only option i have.
PK
You can't recompile the proc itself, but you can force a recompile by updating the stats on the table. This should in theory trigger a recompile for the proc, and I'm sure it applies to procs in the resource db as well, but don't quote me on it.
Do you know if it was the replication monitor or the distribution agent that was making the proc call you were profiling? In pre-RTM days, there was a performance bug for the call made by the replication monitor, making it very expensive. I assume you're on RTM version of SQL 2005?
Without knowing what the plan looks like for the queries inside the proc, it's hard to say what the problem is.
High CPU utilization in SQL Server 2005 SP2 (CTP)
Hi,SpinLockName Collisions Spins Spins/Collison Sleep Time (ms) Backoffs MUTEX 1395 82922 59.4423 0 0 DES_HASH 434 3288 7.576037 0 0 BUF_HASH 4 32 8 0 0 RESOURCE 27 630 23.33333 0 0 LOCK_HASH 177941 1816302 10.20733 0 6 BUF_FREE_LIST 323 30158 93.36842 0 2 DBTABLE 11 315 28.63636 0 0 BACKUP_CTX 869 1480 1.703107 0 0 XDESMGR 935 11842 12.66524 0 0 RESQUEUE 4344 11084 2.551565 0 0 LOGFLUSHQ 4 61 15.25 0 0 SQL_MGR 225 4116 18.29333 0 0 HOBT_HASH 963 9721 10.0945 0 0 XTS_MGR 3 6 2 0 0 XVB_LIST 36 91 2.527778 0 0 LOCK_RESOURCE_ID 217 20 0.0921659 0 0 SESSION_MANAGER 10 683 68.3 0 0 SOS_SCHEDULER 1798 197 0.1095662 0 0 SOS_TLIST 18 40 2.222222 0 0 SOS_CACHESTORE 387 23265 60.11628 0 0 SOS_RW 2 0 0 0 0 SOS_TASK 343 218 0.6355685 0 0 SOS_SYSTHREAD_DISPATCHER 66 5126 77.66666 0 0 SOS_OBJECT_STORE 1939 4304 2.219701 0 0 SOS_SUSPEND_QUEUE 9251 45717 4.941844 0 1 SOS_LARGEPAGE_ALLOCATOR 2 20 10 0 0 CONNECTION_MANAGER 1 0 0 0 0 BASE_XACT_HASH 1 0 0 0 0 XDES_HASH 7 0 0 0 0
We are having a big performance issue at our site. Here is the configuration of the box running SQL Server 2005:
64 bit Windows Enterprise Edition + SP1
Dual CPU, 16GB RAM
RAID 1 and RAID 5 - internal
SQL Server 2005 64-bit Enterprise Edition
With SP2 (CTP from December)
The "Lock Pages in Memory" is set and is being run under the same account that is being used to run SQL Server Services.
We are noticing that under load, the CPU utilization becomes nearly
100%. I have researched this and have come across a couple of
posts that indicate that this issue was fixed in SP2 - example: One
post talked about the hotfix #716 which is also a part of SP2 but even
after the application of that service pack, we are still having this
issue. I haven't tried setting the parameterization option to
forced for the database yet.
Is this a known issue with SP2? If not, what can we look for and
fix in our environment? Please let me know if I can provide more
information.Some more information:
This can be easily reproduced using the ostress utility by simulating
100 simultaneous concurrent connections...the SQL file that is being
used is a single procedure call. The wait event is "RESOURCE_SEMAPHORE_QUERY_COMPILE"
- we have removed the "SET" options from within the stored
procedure. We have also made sure that all queries are
parameterized queries and that there are no constants involved.
The procedure uses 3 table variables and depending upon the input
parameters, different set of queries are used to populate those table
variables. End result that is returned to the client application
is via a join of 2 out of these 3 table variables.
So, from the wait event it definitely looks like we are hitting a query
recompilation issue (part of it seems to have been fixed in SP2 but we
are not seeing those issues). We have also gone through the
whitepaper:
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx#ETD
and have followed the instructions and made sure we are doing the right things.
|||
More information:
We made the forced parameterization change and now in addition to the above wait event, the SOS_SCHEDULER_YIELD is the another prominent wait event that shows up. Nothing else is going on this machine other than that ostress execution which looks like this:
ostress -S xyz -E -d tzxyz -mstress -r1 -iC:\stress.sql -oC:\Stress_Out.txt -eC:\Stress_Err.txt -q -T30 -n100
And the Stress.sql just has a stored procedure call in it. Even if we take the call out and replace it with something as simple as :
declare @.i int
set @.i = 1
select * from table_x where col1 = @.i
we still see the same high CPU issues. The @.i value qualifies for less than 5% of the records in the table. Please advise how to resolve this issue or if this is a known issue in SP2 that will get fixed by release time-frame. This should be very easily reproducible in any environment - all our three environments (32-bit as well as 2 64-bit) exhibit the same behavior.
|||And here is the output from these commands (using DAC) when we ran into this issue:
dbcc memorystatus
select * from sys.dm_os_schedulers
select * from sys.dm_os_ring_buffers where ring_buffer_type like '%RING_BUFFER_SCHEDULER_MONITOR%'
Memory Manager KB
--
VM Reserved 16934872
VM Committed 140496
AWE Allocated 3505168
Reserved Memory 1024
Reserved Memory In Use 0
(5 row(s) affected)
Memory node Id = 0 KB
--
VM Reserved 16929112
VM Committed 134824
AWE Allocated 3505168
MultiPage Allocator 43728
SinglePage Allocator 508608
(5 row(s) affected)
MEMORYCLERK_SQLGENERAL (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 2920
MultiPage Allocator 3784
(7 row(s) affected)
MEMORYCLERK_SQLBUFFERPOOL (Total) KB
- --
VM Reserved 16809984
VM Committed 16384
AWE Allocated 3505168
SM Reserved 0
SM Commited 0
SinglePage Allocator 0
MultiPage Allocator 1160
(7 row(s) affected)
MEMORYCLERK_SQLQUERYEXEC (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 29896
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLOPTIMIZER (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 248
MultiPage Allocator 96
(7 row(s) affected)
MEMORYCLERK_SQLUTILITIES (Total) KB
- --
VM Reserved 600
VM Committed 600
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 128
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLSTORENG (Total) KB
- --
VM Reserved 1728
VM Committed 1728
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 5912
MultiPage Allocator 560
(7 row(s) affected)
MEMORYCLERK_SQLCONNECTIONPOOL (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8224
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLCLR (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLSERVICEBROKER (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 96
MultiPage Allocator 304
(7 row(s) affected)
MEMORYCLERK_SQLHTTP (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SNI (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 1080
MultiPage Allocator 16
(7 row(s) affected)
MEMORYCLERK_FULLTEXT (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLXP (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_QSRANGEPREFETCH (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 159528
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SQLQERESERVATIONS (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 583680
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_HOST (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
MEMORYCLERK_SOSNODE (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16856
MultiPage Allocator 11432
(7 row(s) affected)
MEMORYCLERK_SQLSERVICEBROKERTRANSPORT (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 48
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_OBJCP (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 189264
MultiPage Allocator 22128
(7 row(s) affected)
CACHESTORE_SQLCP (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 10992
MultiPage Allocator 136
(7 row(s) affected)
CACHESTORE_PHDR (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 4008
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_XPROC (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 72
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_TEMPTABLES (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 880
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_NOTIF (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_VIEWDEFINITIONS (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_XMLDBTYPE (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_XMLDBELEMENT (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_XMLDBATTRIBUTE (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_STACKFRAMES (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 0
MultiPage Allocator 8
(7 row(s) affected)
CACHESTORE_BROKERTBLACS (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 264
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERKEK (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERDSH (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERUSERCERTLOOKUP (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERRSB (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERREADONLY (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 72
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_BROKERTO (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_EVENTS (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 16
MultiPage Allocator 0
(7 row(s) affected)
CACHESTORE_SYSTEMROWSET (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 6560
MultiPage Allocator 0
(7 row(s) affected)
USERSTORE_SCHEMAMGR (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 8952
MultiPage Allocator 0
(7 row(s) affected)
USERSTORE_DBMETADATA (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 7656
MultiPage Allocator 0
(7 row(s) affected)
USERSTORE_TOKENPERM (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 784
MultiPage Allocator 0
(7 row(s) affected)
USERSTORE_OBJPERM (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 176
MultiPage Allocator 0
(7 row(s) affected)
USERSTORE_SXC (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 72
MultiPage Allocator 0
(7 row(s) affected)
OBJECTSTORE_LBSS (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 96
MultiPage Allocator 3872
(7 row(s) affected)
OBJECTSTORE_SNI_PACKET (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 18936
MultiPage Allocator 48
(7 row(s) affected)
OBJECTSTORE_SERVICE_BROKER (Total) KB
- --
VM Reserved 0
VM Committed 0
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 272
MultiPage Allocator 0
(7 row(s) affected)
OBJECTSTORE_LOCK_MANAGER (Total) KB
- --
VM Reserved 32768
VM Committed 32768
AWE Allocated 0
SM Reserved 0
SM Commited 0
SinglePage Allocator 67096
MultiPage Allocator 0
(7 row(s) affected)
Buffer Distribution Buffers
--
Stolen 32328
Free 5979
Cached 37052
Database (clean) 343055
Database (dirty) 12222
I/O 0
Latched 52
(7 row(s) affected)
Buffer Counts Buffers
--
Committed 430688
Target 1572864
Hashed 355329
Stolen Potential 1357684
External Reservation 67147
Min Free 64
Visible 1572864
Available Paging File 1600273
(8 row(s) affected)
Procedure Cache Value
--
TotalProcs 127
TotalPages 28325
InUsePages 9418
(3 row(s) affected)
Global Memory Objects Buffers
--
Resource 392
Locks 8390
XDES 424
SETLS 2
SE Dataset Allocators 4
SubpDesc Allocators 2
SE SchemaManager 1118
SQLCache 214
Replication 2
ServerGlobal 48
XP Global 2
SortTables 2
(12 row(s) affected)
Query Memory Objects Value
--
Grants 228
Waiting 0
Available (Buffers) 1096180
Maximum (Buffers) 1169140
Limit 1169140
Next Request 0
Waiting For 0
Cost 0
Timeout 0
Wait Time 0
Last Target 1181940
(11 row(s) affected)
Small Query Memory Objects Value
--
Grants 0
Waiting 0
Available (Buffers) 12800
Maximum (Buffers) 12800
Limit 12800
(5 row(s) affected)
Optimization Queue Value
--
Overall Memory 10327965696
Target Memory 9516032000
Last Notification 1
Timeout 6
Early Termination Factor 5
(5 row(s) affected)
Small Gateway Value
--
Configured Units 8
Available Units 8
Acquires 0
Waiters 0
Threshold Factor 380000
Threshold 380000
(6 row(s) affected)
Medium Gateway Value
--
Configured Units 2
Available Units 2
Acquires 0
Waiters 0
Threshold Factor 12
(5 row(s) affected)
Big Gateway Value
--
Configured Units 1
Available Units 1
Acquires 0
Waiters 0
Threshold Factor 8
(5 row(s) affected)
MEMORYBROKER_FOR_CACHE Value
-- --
Allocations 33612
Rate 6698
Target Allocations 1168790
Future Allocations 0
Last Notification 1
(5 row(s) affected)
MEMORYBROKER_FOR_STEAL Value
-- --
Allocations 20514
Rate 12631
Target Allocations 1161625
Future Allocations 0
Last Notification 1
(5 row(s) affected)
MEMORYBROKER_FOR_RESERVE Value
-- --
Allocations 55680
Rate 35900
Target Allocations 1260738
Future Allocations 292285
Last Notification 1
(5 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
scheduler_address parent_node_id scheduler_id cpu_id status is_online is_idle preemptive_switches_count context_switches_count idle_switches_count current_tasks_count runnable_tasks_count current_workers_count active_workers_count work_queue_count pending_disk_io_count load_factor yield_count last_timer_activity failed_to_create_worker active_worker_address memory_object_address task_memory_object_address
-- - - - - - -- -- -- -- -- -- -- --
0x0000000000C2A080 0 0 255 VISIBLE ONLINE 1 0 24264 680297 23197 258 120 127 127 131 0 509 733601 85174671 0 0x0000000003B901C0 0x0000000003806080 0x0000000003808050
0x0000000000EA6080 0 1 255 VISIBLE ONLINE 1 0 23938 639343 21522 260 118 128 125 132 0 508 665244 85174671 0 0x0000000003A461C0 0x0000000003810080 0x0000000003812050
0x0000000000FC0080 0 257 255 HIDDEN ONLINE 1 0 0 0 2 1 0 1 1 0 0 1 4 78393296 0 0x000000000382C1C0 0x0000000003824080 0x0000000003826050
0x0000000003720080 64 255 255 VISIBLE ONLINE (DAC) 1 1 12 25 27 2 0 3 1 0 0 1 51 85053937 0 0x00000000800001C0 0x0000000000FF6080 0x0000000000FF8050
(4 row(s) affected)
ring_buffer_address ring_buffer_type timestamp record
- -- --
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 85120120 <Record id = "143" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="85120120"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>93</ProcessUtilization><SystemIdle>4</SystemIdle><UserModeTime>17968750</UserModeTime><KernelModeTime>3531093750</KernelModeTime><PageFaults>268</PageFaults><WorkingSetDelta>315392</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 85110131 <Record id = "142" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="85110131"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>96</ProcessUtilization><SystemIdle>1</SystemIdle><UserModeTime>6875000</UserModeTime><KernelModeTime>1147656250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 85050114 <Record id = "141" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="85050114"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>93</ProcessUtilization><SystemIdle>3</SystemIdle><UserModeTime>5000000</UserModeTime><KernelModeTime>1122968750</KernelModeTime><PageFaults>66</PageFaults><WorkingSetDelta>24576</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84990106 <Record id = "140" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84990106"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>89</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>4843750</UserModeTime><KernelModeTime>1075937500</KernelModeTime><PageFaults>79</PageFaults><WorkingSetDelta>69632</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84930065 <Record id = "139" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84930065"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>28</ProcessUtilization><SystemIdle>68</SystemIdle><UserModeTime>5781250</UserModeTime><KernelModeTime>332812500</KernelModeTime><PageFaults>9514</PageFaults><WorkingSetDelta>31944704</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84925078 <Record id = "138" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84925078"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-9467</PageFaults><WorkingSetDelta>16384</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84870072 <Record id = "137" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84870072"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>95</ProcessUtilization><SystemIdle>1</SystemIdle><UserModeTime>5312500</UserModeTime><KernelModeTime>1143750000</KernelModeTime><PageFaults>66</PageFaults><WorkingSetDelta>-31739904</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84870072 <Record id = "136" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84870072"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>95</ProcessUtilization><SystemIdle>2</SystemIdle><UserModeTime>45312500</UserModeTime><KernelModeTime>8540781250</KernelModeTime><PageFaults>449</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84809942 <Record id = "135" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84809942"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>1163125000</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84749920 <Record id = "134" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84749920"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>6718750</UserModeTime><KernelModeTime>1163750000</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84689902 <Record id = "133" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84689902"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>96</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>6250000</UserModeTime><KernelModeTime>1155781250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84629878 <Record id = "132" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84629878"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>96</ProcessUtilization><SystemIdle>1</SystemIdle><UserModeTime>8281250</UserModeTime><KernelModeTime>1150312500</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84569766 <Record id = "131" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84569766"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>94</ProcessUtilization><SystemIdle>3</SystemIdle><UserModeTime>5156250</UserModeTime><KernelModeTime>1127968750</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84509738 <Record id = "130" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84509738"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>90</ProcessUtilization><SystemIdle>6</SystemIdle><UserModeTime>5625000</UserModeTime><KernelModeTime>1084687500</KernelModeTime><PageFaults>59</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84449704 <Record id = "129" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84449704"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>90</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>5937500</UserModeTime><KernelModeTime>1077812500</KernelModeTime><PageFaults>771</PageFaults><WorkingSetDelta>2912256</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84414707 <Record id = "128" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84414707"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-46</PageFaults><WorkingSetDelta>-147456</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84409696 <Record id = "127" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84409696"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>90</ProcessUtilization><SystemIdle>6</SystemIdle><UserModeTime>1093750</UserModeTime><KernelModeTime>271406250</KernelModeTime><PageFaults>690</PageFaults><WorkingSetDelta>2764800</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84389684 <Record id = "126" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84389684"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>16</ProcessUtilization><SystemIdle>79</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>194062500</KernelModeTime><PageFaults>8760</PageFaults><WorkingSetDelta>28860416</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84389684 <Record id = "125" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84389684"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-11040</PageFaults><WorkingSetDelta>-28852224</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84329685 <Record id = "124" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84329685"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84269692 <Record id = "123" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84269692"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84209700 <Record id = "122" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84209700"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84149708 <Record id = "121" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84149708"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84089715 <Record id = "120" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84089715"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>60</ProcessUtilization><SystemIdle>36</SystemIdle><UserModeTime>2656250</UserModeTime><KernelModeTime>722343750</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>-28672</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84029711 <Record id = "119" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84029711"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>51</ProcessUtilization><SystemIdle>43</SystemIdle><UserModeTime>7187500</UserModeTime><KernelModeTime>611718750</KernelModeTime><PageFaults>1739</PageFaults><WorkingSetDelta>20480</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84009711 <Record id = "118" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84009711"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-1955</PageFaults><WorkingSetDelta>-20480</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 84004713 <Record id = "117" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="84004713"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-1955</PageFaults><WorkingSetDelta>-20480</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83969698 <Record id = "116" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83969698"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83909706 <Record id = "115" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83909706"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83849713 <Record id = "114" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83849713"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83789720 <Record id = "113" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83789720"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>43</ProcessUtilization><SystemIdle>54</SystemIdle><UserModeTime>4062500</UserModeTime><KernelModeTime>514062500</KernelModeTime><PageFaults>61</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83744714 <Record id = "112" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83744714"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-11</PageFaults><WorkingSetDelta>-4096</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83739712 <Record id = "111" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83739712"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-11</PageFaults><WorkingSetDelta>-4096</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83734711 <Record id = "110" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83734711"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>87</ProcessUtilization><SystemIdle>8</SystemIdle><UserModeTime>468750</UserModeTime><KernelModeTime>87500000</KernelModeTime><PageFaults>5</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83729713 <Record id = "109" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83729713"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>17</ProcessUtilization><SystemIdle>79</SystemIdle><UserModeTime>3281250</UserModeTime><KernelModeTime>204375000</KernelModeTime><PageFaults>739</PageFaults><WorkingSetDelta>258048</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83724713 <Record id = "108" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83724713"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-1029</PageFaults><WorkingSetDelta>32493568</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83669719 <Record id = "107" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83669719"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83609726 <Record id = "106" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83609726"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>33</ProcessUtilization><SystemIdle>63</SystemIdle><UserModeTime>5156250</UserModeTime><KernelModeTime>392656250</KernelModeTime><PageFaults>262</PageFaults><WorkingSetDelta>-32751616</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83569737 <Record id = "105" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83569737"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>96</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>1093750</UserModeTime><KernelModeTime>95312500</KernelModeTime><PageFaults>17</PageFaults><WorkingSetDelta>49152</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83559744 <Record id = "104" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83559744"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-35</PageFaults><WorkingSetDelta>192512</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83549737 <Record id = "103" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83549737"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>6093750</UserModeTime><KernelModeTime>1169218750</KernelModeTime><PageFaults>178</PageFaults><WorkingSetDelta>-155648</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83544718 <Record id = "102" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83544718"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>781250</UserModeTime><KernelModeTime>195468750</KernelModeTime><PageFaults>10</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83529662 <Record id = "101" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83529662"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-138</PageFaults><WorkingSetDelta>12288</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83519615 <Record id = "100" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83519615"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-97</PageFaults><WorkingSetDelta>57344</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83514624 <Record id = "99" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83514624"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-97</PageFaults><WorkingSetDelta>57344</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83499628 <Record id = "98" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83499628"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>93</ProcessUtilization><SystemIdle>3</SystemIdle><UserModeTime>59687500</UserModeTime><KernelModeTime>12989687500</KernelModeTime><PageFaults>705</PageFaults><WorkingSetDelta>49152</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83489571 <Record id = "97" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83489571"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5156250</UserModeTime><KernelModeTime>1168906250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83429485 <Record id = "96" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83429485"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>1163750000</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83369459 <Record id = "95" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83369459"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>1164531250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83309426 <Record id = "94" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83309426"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>97</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5781250</UserModeTime><KernelModeTime>1163593750</KernelModeTime><PageFaults>59</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83249416 <Record id = "93" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83249416"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>96</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>5312500</UserModeTime><KernelModeTime>1154843750</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83189376 <Record id = "92" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83189376"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>95</ProcessUtilization><SystemIdle>2</SystemIdle><UserModeTime>5000000</UserModeTime><KernelModeTime>1146250000</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83129193 <Record id = "91" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83129193"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>94</ProcessUtilization><SystemIdle>3</SystemIdle><UserModeTime>4843750</UserModeTime><KernelModeTime>1132031250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83069126 <Record id = "90" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83069126"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>93</ProcessUtilization><SystemIdle>4</SystemIdle><UserModeTime>3906250</UserModeTime><KernelModeTime>1114062500</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 83009112 <Record id = "89" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="83009112"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>90</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>4062500</UserModeTime><KernelModeTime>1077812500</KernelModeTime><PageFaults>59</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82949130 <Record id = "88" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82949130"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>87</ProcessUtilization><SystemIdle>9</SystemIdle><UserModeTime>6093750</UserModeTime><KernelModeTime>1046718750</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82889131 <Record id = "87" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82889131"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>86</ProcessUtilization><SystemIdle>10</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>1035781250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82829140 <Record id = "86" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82829140"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>87</ProcessUtilization><SystemIdle>9</SystemIdle><UserModeTime>5781250</UserModeTime><KernelModeTime>1042812500</KernelModeTime><PageFaults>7333</PageFaults><WorkingSetDelta>27795456</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82799139 <Record id = "85" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82799139"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-34</PageFaults><WorkingSetDelta>-102400</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82794137 <Record id = "84" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82794137"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>88</ProcessUtilization><SystemIdle>8</SystemIdle><UserModeTime>1093750</UserModeTime><KernelModeTime>175312500</KernelModeTime><PageFaults>367</PageFaults><WorkingSetDelta>1462272</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82779139 <Record id = "83" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82779139"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-26240</PageFaults><WorkingSetDelta>-40124416</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82769022 <Record id = "82" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82769022"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>6</ProcessUtilization><SystemIdle>85</SystemIdle><UserModeTime>17968750</UserModeTime><KernelModeTime>55781250</KernelModeTime><PageFaults>8949</PageFaults><WorkingSetDelta>18870272</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82708960 <Record id = "81" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82708960"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>1</ProcessUtilization><SystemIdle>95</SystemIdle><UserModeTime>8281250</UserModeTime><KernelModeTime>6718750</KernelModeTime><PageFaults>5511</PageFaults><WorkingSetDelta>19394560</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82648968 <Record id = "80" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82648968"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82588975 <Record id = "79" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82588975"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82528982 <Record id = "78" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82528982"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82468990 <Record id = "77" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82468990"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>64</PageFaults><WorkingSetDelta>12288</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82408997 <Record id = "76" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82408997"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82349005 <Record id = "75" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82349005"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>64</PageFaults><WorkingSetDelta>-385024</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82289012 <Record id = "74" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82289012"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82229020 <Record id = "73" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82229020"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>63</PageFaults><WorkingSetDelta>-11390976</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82169027 <Record id = "72" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82169027"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>-16384</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82109035 <Record id = "71" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82109035"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 82049042 <Record id = "70" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="82049042"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81989050 <Record id = "69" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81989050"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81929057 <Record id = "68" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81929057"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81869065 <Record id = "67" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81869065"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81809072 <Record id = "66" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81809072"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81749079 <Record id = "65" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81749079"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>62</PageFaults><WorkingSetDelta>4096</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81689087 <Record id = "64" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81689087"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81629094 <Record id = "63" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81629094"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81569102 <Record id = "62" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81569102"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81509109 <Record id = "61" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81509109"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81449117 <Record id = "60" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81449117"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>156250</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>-10162176</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81389124 <Record id = "59" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81389124"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81329131 <Record id = "58" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81329131"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81269139 <Record id = "57" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81269139"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81209146 <Record id = "56" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81209146"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81149154 <Record id = "55" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81149154"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81089162 <Record id = "54" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81089162"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 81029169 <Record id = "53" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="81029169"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80969176 <Record id = "52" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80969176"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80909184 <Record id = "51" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80909184"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80849191 <Record id = "50" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80849191"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80789199 <Record id = "49" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80789199"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80729206 <Record id = "48" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80729206"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80669214 <Record id = "47" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80669214"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80609221 <Record id = "46" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80609221"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80549228 <Record id = "45" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80549228"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80489236 <Record id = "44" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80489236"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>61</PageFaults><WorkingSetDelta>4096</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80429243 <Record id = "43" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80429243"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80369251 <Record id = "42" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80369251"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80309258 <Record id = "41" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80309258"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80249266 <Record id = "40" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80249266"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>94</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>156250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80189273 <Record id = "39" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80189273"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80129280 <Record id = "38" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80129280"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80069288 <Record id = "37" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80069288"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 80009295 <Record id = "36" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="80009295"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79949303 <Record id = "35" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79949303"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79889310 <Record id = "34" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79889310"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>97</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79829318 <Record id = "33" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79829318"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>98</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79769325 <Record id = "32" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79769325"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>43</ProcessUtilization><SystemIdle>54</SystemIdle><UserModeTime>2187500</UserModeTime><KernelModeTime>520781250</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>-4730880</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79709332 <Record id = "31" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79709332"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>65</ProcessUtilization><SystemIdle>31</SystemIdle><UserModeTime>4687500</UserModeTime><KernelModeTime>798906250</KernelModeTime><PageFaults>71</PageFaults><WorkingSetDelta>-401408</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79648355 <Record id = "30" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79648355"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>88</ProcessUtilization><SystemIdle>9</SystemIdle><UserModeTime>4687500</UserModeTime><KernelModeTime>1058593750</KernelModeTime><PageFaults>116</PageFaults><WorkingSetDelta>-1662976</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79588359 <Record id = "29" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79588359"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>92</ProcessUtilization><SystemIdle>5</SystemIdle><UserModeTime>7500000</UserModeTime><KernelModeTime>1097343750</KernelModeTime><PageFaults>1889</PageFaults><WorkingSetDelta>4694016</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79543364 <Record id = "28" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79543364"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>90</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>28750000</UserModeTime><KernelModeTime>6288281250</KernelModeTime><PageFaults>3361</PageFaults><WorkingSetDelta>6144000</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79528340 <Record id = "27" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79528340"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>90</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>5468750</UserModeTime><KernelModeTime>1081250000</KernelModeTime><PageFaults>331</PageFaults><WorkingSetDelta>-937984</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79468346 <Record id = "26" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79468346"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>92</ProcessUtilization><SystemIdle>5</SystemIdle><UserModeTime>5156250</UserModeTime><KernelModeTime>1106875000</KernelModeTime><PageFaults>403</PageFaults><WorkingSetDelta>-835584</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79408339 <Record id = "25" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79408339"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>92</ProcessUtilization><SystemIdle>5</SystemIdle><UserModeTime>5000000</UserModeTime><KernelModeTime>1107343750</KernelModeTime><PageFaults>386</PageFaults><WorkingSetDelta>921600</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79348230 <Record id = "24" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79348230"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>92</ProcessUtilization><SystemIdle>5</SystemIdle><UserModeTime>4375000</UserModeTime><KernelModeTime>1105312500</KernelModeTime><PageFaults>703</PageFaults><WorkingSetDelta>2633728</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79288209 <Record id = "23" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79288209"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>89</ProcessUtilization><SystemIdle>8</SystemIdle><UserModeTime>5312500</UserModeTime><KernelModeTime>1070937500</KernelModeTime><PageFaults>890</PageFaults><WorkingSetDelta>2715648</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79228124 <Record id = "22" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79228124"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>66</ProcessUtilization><SystemIdle>29</SystemIdle><UserModeTime>7187500</UserModeTime><KernelModeTime>788906250</KernelModeTime><PageFaults>3422</PageFaults><WorkingSetDelta>9412608</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79188134 <Record id = "21" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79188134"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-5643</PageFaults><WorkingSetDelta>-11755520</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79168131 <Record id = "20" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79168131"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>32</ProcessUtilization><SystemIdle>64</SystemIdle><UserModeTime>7812500</UserModeTime><KernelModeTime>387343750</KernelModeTime><PageFaults>270</PageFaults><WorkingSetDelta>143360</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79108139 <Record id = "19" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79108139"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>18</ProcessUtilization><SystemIdle>78</SystemIdle><UserModeTime>19843750</UserModeTime><KernelModeTime>206406250</KernelModeTime><PageFaults>291</PageFaults><WorkingSetDelta>102400</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 79048146 <Record id = "18" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="79048146"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>29</ProcessUtilization><SystemIdle>67</SystemIdle><UserModeTime>14218750</UserModeTime><KernelModeTime>345312500</KernelModeTime><PageFaults>282</PageFaults><WorkingSetDelta>348160</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78988153 <Record id = "17" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78988153"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>33</ProcessUtilization><SystemIdle>63</SystemIdle><UserModeTime>5000000</UserModeTime><KernelModeTime>401250000</KernelModeTime><PageFaults>475</PageFaults><WorkingSetDelta>1691648</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78928161 <Record id = "16" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78928161"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>95</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>312500</KernelModeTime><PageFaults>167</PageFaults><WorkingSetDelta>405504</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78868168 <Record id = "15" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78868168"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>0</ProcessUtilization><SystemIdle>96</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>312500</KernelModeTime><PageFaults>105</PageFaults><WorkingSetDelta>176128</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78808175 <Record id = "14" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78808175"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>25</ProcessUtilization><SystemIdle>72</SystemIdle><UserModeTime>1562500</UserModeTime><KernelModeTime>303125000</KernelModeTime><PageFaults>60</PageFaults><WorkingSetDelta>-8192</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78753185 <Record id = "13" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78753185"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>90</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>4062500</UserModeTime><KernelModeTime>987968750</KernelModeTime><PageFaults>55</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78748193 <Record id = "12" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78748193"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>83</ProcessUtilization><SystemIdle>10</SystemIdle><UserModeTime>5156250</UserModeTime><KernelModeTime>1082187500</KernelModeTime><PageFaults>1140</PageFaults><WorkingSetDelta>831488</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78688081 <Record id = "11" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78688081"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-957</PageFaults><WorkingSetDelta>-61440</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78683090 <Record id = "10" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78683090"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>53</ProcessUtilization><SystemIdle>42</SystemIdle><UserModeTime>4218750</UserModeTime><KernelModeTime>637343750</KernelModeTime><PageFaults>961</PageFaults><WorkingSetDelta>73728</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78638099 <Record id = "9" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78638099"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>89</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>3437500</UserModeTime><KernelModeTime>894375000</KernelModeTime><PageFaults>50</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78623098 <Record id = "8" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78623098"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>79</ProcessUtilization><SystemIdle>16</SystemIdle><UserModeTime>6406250</UserModeTime><KernelModeTime>950937500</KernelModeTime><PageFaults>1018</PageFaults><WorkingSetDelta>397312</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78583072 <Record id = "7" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78583072"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-1168</PageFaults><WorkingSetDelta>-757760</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78563064 <Record id = "6" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78563064"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>39</ProcessUtilization><SystemIdle>58</SystemIdle><UserModeTime>1875000</UserModeTime><KernelModeTime>469375000</KernelModeTime><PageFaults>176</PageFaults><WorkingSetDelta>323584</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78513072 <Record id = "5" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78513072"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-19</PageFaults><WorkingSetDelta>-36864</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78508074 <Record id = "4" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78508074"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-19</PageFaults><WorkingSetDelta>-36864</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78503075 <Record id = "3" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78503075"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>87</ProcessUtilization><SystemIdle>7</SystemIdle><UserModeTime>8437500</UserModeTime><KernelModeTime>1045000000</KernelModeTime><PageFaults>5867</PageFaults><WorkingSetDelta>19615744</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78503075 <Record id = "2" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78503075"><SchedulerMonitorEvent><DeadlockedSchedulersEnd><Node>0</Node><ProcessUtilization>93</ProcessUtilization><SystemIdle>3</SystemIdle><UserModeTime>2343750</UserModeTime><KernelModeTime>838281250</KernelModeTime><PageFaults>45</PageFaults><WorkingSetDelta>0</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersEnd></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78453078 <Record id = "1" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78453078"><SchedulerMonitorEvent><DeadlockedSchedulersBegin><Node>0</Node><ProcessUtilization>100</ProcessUtilization><SystemIdle>0</SystemIdle><UserModeTime>0</UserModeTime><KernelModeTime>0</KernelModeTime><PageFaults>-28064</PageFaults><WorkingSetDelta>-107360256</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></DeadlockedSchedulersBegin></SchedulerMonitorEvent></Record>
0x0000000000C249A0 RING_BUFFER_SCHEDULER_MONITOR 78443079 <Record id = "0" type ="RING_BUFFER_SCHEDULER_MONITOR" time ="78443079"><SchedulerMonitorEvent><SystemHealth><ProcessUtilization>1</ProcessUtilization><SystemIdle>95</SystemIdle><UserModeTime>3437500</UserModeTime><KernelModeTime>8593750</KernelModeTime><PageFaults>6029</PageFaults><WorkingSetDelta>22028288</WorkingSetDelta><MemoryUtilization>100</MemoryUtilization></SystemHealth></SchedulerMonitorEvent></Record>
(144 row(s) affected)
|||There does not seem to be a memory problem -- less than 5GB of the said 16 is being used. Server is definitely hogging the CPU.
Can you also please attach the output of dbcc sqlperf (spinlockstats)?
Thanks ,Ron D.
|||Here is the information (only those records are shown that had any value in it):
Subscribe to:
Posts (Atom)