| Title: | DECtrace V2.0 and All-in-1 Perf Rpts conf. |
| Notice: | Kits+Doc, 2 | Patches, 3 |
| Moderator: | OMYGOD::LAVASH |
| Created: | Mon Apr 26 1993 |
| Last Modified: | Mon Jun 02 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 467 |
| Total number of notes: | 2058 |
I have used TRACE (fairly successfully, I think!) to tune multiple
databases. I use the BLR_TO_SQL converter and then create some views
and run a SQL statement and I get the top N users of CPU time or lapsed
time or direct i/o or whatever! (I didn't figure this out on my own -
one of the mission-critical-engineering guys did all the real work!)
So I have a lot of confidence in both the technique and the code.
However last week I saw one data point that came out very strange. I
was sorting by lapsed time and this wasn't the biggest user but maybe
#5 or 6 on the list. The lapsed time was 1 min 2.46 seconds but the
CPU time was 113 seconds, which is more than the lapsed time. I don't
recall ever seeing this before and it was only this one datapoint out
of hundreds that I looked at.
I looked and looked at this trying to see something that I was missing
and I can't; it really looks like an error of some sort. The base
collection was only 30 minutes and the display can show up to 99 hours
of lapsed time so I don't think the lapsed time field "overflowed" or
anything like that.
I know there's not much concrete here to go on, but I wondered if
anyone else has seen any discrepancies in the data using whatever
reporting methods they use.
Trace version is 2.2; Rdb version is 6.1-02 for the database running on
Alpha VMS 6.2.
Thanks,
Mary Ann
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 441.1 | CPU time and Lapsed time not calculated equally | OOTOOL::CRAIG | Wed Feb 12 1997 12:15 | 29 | |
Hi Mary Ann, Nice to hear from you. I remember having a discussion with George about this issue before. I don't remember all of the details, so if I'm way off base George will fill us in when he gets back to the office next week. One time is larger because it includes time periods which aren't included in the other calculated time. Some examples that I can think of include: time waiting for connections to databases, time waiting for record retrieval when there is contention, system overhead, etc. that The time difference can be exaggerated if the priority of the process trying to connect is lower than some other process running at the same time. Let me know if you need more specifics. That's the best I can remember right now. Hope it sheds some light on the differences. Take care, Sheri | |||||
| 441.2 | CPU is BIGGER than LAPSED! | ORAREP::JRFVAX::HODGES | Thu Feb 13 1997 12:15 | 12 | |
Hi Sherri (and Richard and George and others!) B-)
Yep, I'm still here!
I don't think that explanation applies here. What I saw in this one
instance was that the lapsed time, which I've always believed includes
CPU & lock stalls and all that other 'stuff' being done on my behalf,
was actually smaller than the CPU time! Lapsed time was 1 minute & 2
seconds while CPU time was 113 seconds which works out to 1 minute and
53 seconds!!!
Mary Ann
| |||||
| 441.3 | base what? | OOTOOL::LAVASH | Same as it ever was... | Tue Feb 18 1997 08:46 | 6 |
CPU time is stored in ticks which are I beleive are tens of milliseconds
does your reporting program translate that into seconds???
If not your comparing apples to truckloads of apples.
George
| |||||
| 441.4 | did anybody get the license number of that truck? | ORAREP::ODIXIE::HODGES | Wed Mar 05 1997 22:31 | 7 | |
Well, this week I feel like I've been hit by a truckload of apples!
I'll try to find time to check the code.
Thanks for the pointer!
Mary Ann
| |||||