HP3000-L Archives

August 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Carl McNamee <[log in to unmask]>
Reply To:
Carl McNamee <[log in to unmask]>
Date:
Thu, 10 Aug 2000 10:50:48 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
Bill is correct about this being an XM check point.  One possible way to
ease the pain, if you are on 6.0 or higher, is to go into VOLUTIL and enable
ALTERCHKPTSTAT.  This is done per volume set and a reboot is required to
activate it.  This option changes the way MPE handles a check point so that
doesn't impact the system quite as bad.  See the Communicator for 6.0 for
more detailed information.

We had the same problem when loading out databases.  About every 10 minutes
XM would start posting and everything on the system would grind to a halt
for 30-90 seconds.  I've been using the ALTERCHKPSTAT option for over a year
now on several systems with out any problems.  If I recall someone on the
list ran into a corner case that can cause a problem but I can't remember
what the scenario was.

Carl McNamee
Systems Administrator
Billing Concepts
(210) 949-7282



-----Original Message-----
From: Bill Cadier [mailto:[log in to unmask]]
Sent: Thursday, August 10, 2000 10:23 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] PIN 11?


Michael wrote:

>From time to time, or randomly throughout the day I have seen (In GLANCE)
P11 MANAGER.SYS >take up all our DISC I/O. The event will
last for a minute or two, and in that period of time all other >process seem
to hang. After P11 finishes doing whatever it was
doing, everything continues to run >fine. My question is; Can anyone tell me
what P11 is doing. The machine in question is run
MPE/iX >5.5 pp7.

This is probably the xm check point server. The way to tell is to have
Glance produce
a stack trace or, in DEBUG you can do this:

$1 ($7f) nmdebug > pin #11;tr,d,i
                                   ------------------

And you could see something like this if Pin 11 is waited at the time you do
it:

       PC=a.0018170c enable_int+$2c
NM* 0) SP=41636770 RP=a.00f68908
notify_dispatcher.block_current_process+$324
NM  1) SP=41636770 RP=a.00f6ad90 notify_dispatcher+$264
NM  2) SP=416366f0 RP=a.001b1c20 wait_for_active_port+$ec
NM  3) SP=416365f0 RP=a.001b28a0 receive_from_port+$534
NM  4) SP=41636570 RP=a.00355efc extend_receive+$494
NM  5) SP=41636370 RP=a.00606c70 xm_static_checkpoint_server+$80
NM  6) SP=416361f0 RP=a.0052fbf0 outer_block+$14c
NM  7) SP=41636130 RP=a.00000000
     (end of NM stack)

If this process is actively running at the time you attempt the trace you
may see other
procedures listed above 'xm_static_checkpoint_server' (naturally!).

If you have a lot of activity (changes) in files covered by XM such as Image
data
bases or KSAM/XL files the XM checkpoint server will need to run often.
This is a
typical reason for XM overhead but certainly not the only reason.

I hope this helps!

Bill
HP/CSY


Billing Concepts Corp., a NASDAQ listed Company, Symbol:BILL

ATOM RSS1 RSS2