Using (Alpha) DECset PCA with a subprocess created with creprc

[How to use DECset PCA w]

Hi there,
I'm investigating a performance problem with a system (running on an Alpha) that creates various sub process. These processes are created using $creprc command from the code. The program basically loops through a list of processes to create. I want to run PCA with some or all of these processes. Can you tell me how I'd go about that?

Each process is currently called as follows:

status := $creprc(pidadr := pid,
image := 'name_obj:' + image,
prcnam := name ,
mbxunt := mbx_unit_num::integer,
baspri := priority);

The image and name variables above would be 'AUTOSTAT' for instance? Would it be as easy as changing the name variable to 'PCA$AUTOSTAT'?

Do I need to specify a log file to the creprc command?

Does the processes that I'm monitoring need to be closed down in a particular manner for the collection process?

Any info a big help?

[John Gillings]

Sorry, I don't know much about PCA, but
your $CREPRC is missing the PQL (quota) parameter, which means it will be running with default/minimal quotas. See PQL_D* and PQL_M* SYSGEN parameters, which could easily result in performance issues. This is especially true if the same image(s) execute with adequate performance when run interactively.

Whenever you start a process directly with $CREPRC, you need to make sure it's given adequate quotas. Quotas are NOT inherited from then parent process (see documentation for $CREPRC for the convoluted and confusing way in which quotas are determined). Make sure you specify ALL quotas which are relevant to the process. I strongly advise against adjusting system wide PQL parameters to compensate.

Be very careful creating a PQL structure as it's an unaligned array of 5 byte entries (byte, long). Most languages will helpfully try to align it. Start with a test $CREPRC, running a process that just calls $HIBER and confirm that all the quotas you specify have been correctly propagated using F$GETJPI.

[Pramod Kumar M]

Hi,

PCA helps to find the hotspots in user mode applications. You need debug versions of your application so that after running your application with PCA collector, PCA analyzer can show the hotspots in your application.

If you are suspecting that the performance of your subprocesses are not as expected you may need to run PCA for those subprocesses.

I think using PCS SDA extension is a good idea here to start with. PCS allows you to collect PCS samples for selected processes.

$ anal/syst

OpenVMS system analyzer

SDA> pcs

This should give you the various option with which you can collect PCS samples.

As far as answering your questions

>>The image and name variables above would >>be 'AUTOSTAT' for instance? Would it be as >>easy as changing the name variable >>to 'PCA$AUTOSTAT'?

>>Do I need to specify a log file to the >>creprc command?

>>Does the processes that I'm monitoring >>need to be closed down in a particular >>manner for the collection process?

I don't think these are necessary to analyze the performance of your appication.

-Pramod.

[Ian Miller.]

It would probably be best to create a process with DCL running a DCL procedure which ran the program with PCA.

However using PCS$SDA may well be easier.
It works in a similar way to SPL$SDA
see http://h71000.www7.hp.com/doc/84final/6549/6549pro_spl.html#spin_lock_tracing