SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?

[Ian Miller.]

You may want to use PRF or PCS to see where that processing is spending it's excessive kernel mode time.

[Michael Moroney]

Yes this is a performance issue. A process wakes up once a second and checks for things to do from a network socket, something that should take milliseconds but has crept up to almost 1/2 second. I initially used show process/cont to try to see where in the code it was spending its time, and most of its time was shown at the bogus address. PCS from SDA has told me it spends most of its time in the XQP at IPL 8.

I noticed the code has a C fsynch() call on each pass. If the disk the file being fsynched is on is fragmented, but the file itself isn't very fragmented, would there be excessive XQP time? There would be 0 or 1 fprintf() calls between the fsynch() calls. The file currently has 5 extents.

[Volker Halle]

Michael,

I described the operation of DEL_EXTFCB in a previous reply. The code walks FCB chains to the VCB. Are there many files open on that disk ?

Why not write a simple example program doing fsync calls in a tight loop and watch the performance of that test program ?

Volker.

[Michael Moroney]

That was a good idea, I ran a program that was a loop with a single fprintf(), an fsync() and sleep(1) with the file on the fragmented disk. This is a simplification of the main loop of the program. It ran using very little CPU time, so the problem isn't the fsync to the fragmented disk.

[Hoff]

Entirely for giggles, try this on the file involved:

SET FILE /CACHING_ATTRIBUTE=NO_CACHING file

[Michael Moroney]

We can't apply the cache attribute to an open file. Customer pretty much doesn't want to shut down the application unless there's essentially a near-guarantee of a fix. They're open to get the disk defragmented although I can't explain while another process that's a much heavier user of the drive doesn't seem to have any issues.

I just noticed that SDA also has the "2BADCODE" (as well as "1BADCODE") problem with SHOW PROCESS/FULL but SDA PCS module doesn't.

Those who are into XQP may be amused by the attached pcs sh trace/stat output.

[Hein van den Heuvel]

fflush just gives records from the Crtl to RMS
fsync maps to an RMS $FLUSH which will tell the xqp to update the file header.

You did not mention revision (-H1?) or patch level. The makes the PCS trace (nice! ) data ambiguous.
Maybe you can use ANAL/SYS.. EXA/INST for one or two of the popular instructions to make sure we are looking at the same sources.
Like that 624 DEL_EXTFCB_C+00360
Is that a "ld4 r18 = [r27]" per chance?
I'm thinking it may be in...
UNTIL .P[VCB$B_TYPE] EQL DYN$C_VCB DO P = .P[FCB$L_FCBFL];

Also, is the system burning significant MPsync?
How about a spinlock trace, perhaps using @ SYS$EXAMPLES:SPL
Is there a lot of FILSYS time?

- Is this a cluster or standalone
- Any TRUNCATE calls happening?

fwiw,
Hein.

[Volker Halle]

Michael,

this process is clearly spending a lot of CPU cycles in DEL_EXTFCB. One question would be, why does it get there ? The other question is, why does it spend so much time in there once it gets there ?

There are a couple of loops in this routine, which walk the FCB chains.

$ ANAL/SYS
SDA> SHOW DEV disk-device-name
SDA> READ SYSDEF
SDA> VALI QUE vcb+vcb$l_fcbfl

How many FCBs are in that queue ?

Volker.

[Jur van der Burg]

>I just noticed that SDA also has the "2BADCODE" (as well as "1BADCODE") problem with SHOW PROCESS/FULL but SDA PCS module doesn't.<

Of course pcs does not display that. The pc is fabricated and never actually sess that address.

Jur (PCS author).

[Volker Halle]

Michael,

when RMS is flushing the buffers, it looks like it only updates the file header (via a call to the XQP), if the end-of-file block number (IFB$L_EBK) has changed. So a simple fsync test without actually writing to the file may not trigger the behaviour seen in the application.

Volker.