What does sysprocesses.cpu mean?
Q Vincent Yin
--
Q Vincent Yin | Repeat
um...@mctrf.mb.ca | delete(next->bug);
| Until 0 = 1;
Michael Peppler
Q Vincent Yin <um...@cancer2.mctrf.mb.ca> wrote:
>Anyone knows what the 'cpu' column in master..sysprocesses mean?
According to the docs it's the cumulative cpu time used by a process in
'ticks'. I suppose that the size of a 'tick' is defined somewhere,
too.
Michael
--
Michael Peppler, ITF Management SA, Fontaine 13, CH-1204 Geneva
mpep...@itf.ch - Tel (4122) 818 3021 - Fax (4122) 312 1325
GCS d+(-) s++: a C++ US++++$ P+++$ E++ W? N++ !w tv- b+++ G e+++ h---
r+++ y?
Q Vincent Yin
>In article <425aph$2...@canopus.cc.umanitoba.ca>,
>Q Vincent Yin <um...@cancer2.mctrf.mb.ca> wrote:
>>Anyone knows what the 'cpu' column in master..sysprocesses mean?
>
>According to the docs it's the cumulative cpu time used by a process in
>'ticks'. I suppose that the size of a 'tick' is defined somewhere,
>too.
Thanks for the explanation. Now my next question:
The server will kill a process if it uses too many cpu ticks. The default
is 500 ticks. And there's an undocumented method to change that default
in `buildmaster'. But I couldn't get a clear explanation of
"cumulative cpu time used by a process"
from some people I talked to. I wrote an infinite loop that basically
calculates some math functions. According to some people's interpretation
of 'cumulative cpu time', that infinite loop should run out of `ticks'
and die eventually. But it never did. In fact, when I print out
sysprocesses.cpu in the loop, the value fluctuates instead of always
going up.
So could you or anyone explain exactly what is the "cumulative cpu time used
by a process"? And give some sample code that indeed could run out of
`ticks'?
Greg Thain
Q> The server will kill a process if it uses too many cpu ticks.
Q> The default is 500 ticks. And there's an undocumented method
Q> to change that default in `buildmaster'. But I couldn't get a
Are you sure? I've never seen this documented anywhere, and I have
processes with hundreds of thousands of ticks which don't get killed
by the server. (Running Sybase 10 on an RS/6000).
Q> So could you or anyone explain exactly what is the "cumulative
Q> cpu time used by a process"?
As a (Sybase) process runs, it accumulates CPU time into
sysprocesses.cpu. Each tick represents @@timeticks microseconds,
which is 1/10 of a second on my machine. When sysprocesses.cpu hits
the "cpu flush" limit, which defaults to 100, the current value of
sysprocesses.cpu is added to syslogins.totcpu, and sysprocesses.cpu
is set back to 0.
The usefulness of this process is dubious, so we just sp_configure
cpu_flush to MAX_INT, so we can see useful numbers in
sysprocesses.cpu
Q> --
Q> Q Vincent Yin | Repeat um...@mctrf.mb.ca | delete(next->bug); |
Q> Until 0 = 1;
--
--
Greg Thain
Sunquest Information System th...@sunquest.sunquest.com
4801 E Broadway (520) 733-6396 voice
Tucson, AZ 85711 (520) 733-6602 FAX
Terry Miesse
correctly, it was mentioned there that sysprocesses.cpu gets reset when
a transaction is committed. Does that explain your fluctuation?
|> Q Vincent Yin | Repeat
|> um...@mctrf.mb.ca | delete(next->bug);
|> | Until 0 = 1;
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I do not speak for Lexis-Nexis, I/S, Shared Services 2, or any
projects within I/S, except occasionally for C*STAR. If I have
mis-stated anything in the note above, please correct me.
_________________________________________________________________
Terry Miesse | "Because only natural products are
LEXIS/NEXIS | used, taste, color, and body
C*STAR Project | may vary"
(513) 865-6800 x6711 | -- Snapple Kiwi Strawberry Cocktail
terry....@lexis-nexis.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Q Vincent Yin
> Q> The server will kill a process if it uses too many cpu ticks.
> Q> The default is 500 ticks. And there's an undocumented method
> Q> to change that default in `buildmaster'. But I couldn't get a
>
>Are you sure? I've never seen this documented anywhere, and I have
>processes with hundreds of thousands of ticks which don't get killed
>by the server. (Running Sybase 10 on an RS/6000).
Actually I don't believe it, either. But a Sybase tech support
told me so last week. He is "pretty sure" about that. I asked him
what would happen if I ran an infinite loop. He said it'll die.
I still wouldn't quite believe it. So I ran an infinite loop for
about 20 hours, it didn't die. Basically now I don't know what to believe.
>As a (Sybase) process runs, it accumulates CPU time into
>sysprocesses.cpu. Each tick represents @@timeticks microseconds,
>which is 1/10 of a second on my machine. When sysprocesses.cpu hits
>the "cpu flush" limit, which defaults to 100, the current value of
>sysprocesses.cpu is added to syslogins.totcpu, and sysprocesses.cpu
Your comment is a lot more insightful than those I get from Sybase.
Thanks, Greg.
Steven Pringle
The SQL Server kernel is non-preemptive, meaning each task is responsible
for putting itself to sleep when it's alloted time (ticks) have expired.
Normally all tasks do a pretty good job of swapping themselves out. This
is why the infinite loop didn't die. The task politely swapped itself out
to let other tasks run. The kernel then woke up the infinite task and let
it run. There are occasions when a task fails to put itself to sleep.
This is when the server will kill a task. It's a timeslice error. The task
has used up more than it's alloted number of ticks, so the kernel jumps
in and kills it. Why a task uses up more than it's alloted number of ticks
is another story, but a timeslice can generally be considered a bug.
You can configure the number of ticks a task is alloted, i don't recall
which one it is. Tasks with hundreds of thousands of cpu ticks indicate
accumulated ticks.
Steve Pringle
Context Integration
415 873-0103
Q Vincent Yin
>
>There are occasions when a task fails to put itself to sleep.
>This is when the server will kill a task. It's a timeslice error. The task
>has used up more than it's alloted number of ticks, so the kernel jumps
>in and kills it. Why a task uses up more than it's alloted number of ticks
>is another story, but a timeslice can generally be considered a bug.
>You can configure the number of ticks a task is alloted, i don't recall
>which one it is. Tasks with hundreds of thousands of cpu ticks indicate
>accumulated ticks.
>
>Steve Pringle
Thanks, Steve! In our case, we get the timeslice error when we run
a PC front-end with Trumpet Winsock. The PC dials in to the UNIX machine.
The application would get started fine, but die sometime later in the
middle of a retrieve, with the timeslice error in errorlog. However, the
same application would run fine if we use PC-NFS connection (instead of a
modem) to UNIX. Nothing in the application takes a significant amount
of time to complete. It's a rather fast on-line application. So it's
not a problem with an unefficient SQL statement.
Would there be a senario that could explain this?
Ashutosh Joglekar
: Steven Pringle <pri...@lindy.stanford.edu> wrote:
: >
: >There are occasions when a task fails to put itself to sleep.
: >This is when the server will kill a task. It's a timeslice error. The task
: Thanks, Steve! In our case, we get the timeslice error when we run
: a PC front-end with Trumpet Winsock. The PC dials in to the UNIX machine.
(10.0.2.2/Solaris2.3)
I get lots of timeslice errors on a *really* busy SQL server if I
run dbcc memusage. The kernel seems to kill all the processes that were
keeping the CPU busy in order to let the memusage run ?
Cheers, Ashu
--
Ashutosh Joglekar ( ashu...@panix.com OR ajog...@ltcm.com )
Steven Pringle
Ashutosh Joglekar <ashu...@panix.com> wrote:
>
>(10.0.2.2/Solaris2.3)
>I get lots of timeslice errors on a *really* busy SQL server if I
>run dbcc memusage. The kernel seems to kill all the processes that were
>keeping the CPU busy in order to let the memusage run ?
>
The SQL Server kernel does not have the capability to kill (without some
operator intervention) other tasks so that another task (i.e. memusage) may
run. It's remotely possible that dbcc memusage modifies some internal
structures which then causes the other tasks to timeslice. I'd call it
a bug. Does the dbcc memusage task complete successfully?
Steve Pringle pri...@lindy.stanford.edu
Sr. Consultant
Context Integration
415 873-0103
Ashutosh Joglekar
: >In article <42mtg7$h...@panix.com>,
: >Ashutosh Joglekar <ashu...@panix.com> wrote:
: >>
: >>(10.0.2.2/Solaris2.3)
: >>I get lots of timeslice errors on a *really* busy SQL server if I
: >>run dbcc memusage. The kernel seems to kill all the processes that were
: >>keeping the CPU busy in order to let the memusage run ?
: Are you running on a multi-processor machine, with more than one online
: engine configured? In the Server Administration class that I took a few
Yes, 2 engines on a dual Ross Sparc20. In response to the earlier
post, yes, the memusage does complete succesfully. It has never killed
other processes if the Server is not really busy. Also, even though
the kernel cannot kill client threads, it *can* "infect" them with 11
or some such status code - I beleive the threads check this status bit
ocassionally and then commit suicide.
Chaarrs,
Simon Walker
> : >This is when the server will kill a task. It's a timeslice error.
The task
> : >Steve Pringle
>
> : Thanks, Steve! In our case, we get the timeslice error when we run
> : a PC front-end with Trumpet Winsock. The PC dials in to the UNIX
machine.
>
> I get lots of timeslice errors on a *really* busy SQL server if I
> run dbcc memusage. The kernel seems to kill all the processes that were
> keeping the CPU busy in order to let the memusage run ?
>
Our HP Sybase 10 server doesn't even have to be particularly busy - DBCC
MEMUSAGE will trash any and all processes. I ran this one day and bought
down a production server :-(
Sybase said 'it says you shouldn't run it in the manual'. Sure enough,
under DBCC MEMUSAGE it says not to run it on an SMP machine. Useful
that. Now, despite knowing 99% of Sybase commands by heart, I have to
consult the manual before running so much as a SELECT @@VERSION, just in
case you can't run it on an SMP machine... This is progress.
simon walker
The SQL Workshop
Milton Keynes, UK