I have 7 production rpcs (Rpcs are servers being called from WEB via Entire X, natural modules that are called, write to a DB2 database) running at the moment but the usage on CPU is very high, I would like to know the following please :-
- Will adding more RPCs reduce the CPU time?
- Is there a way to monitor or get statistics for a single RPC, i. e. the subprograms called and how many times they were called,
- Is there any mechanism or module to get statistics on RPCs
I don’t think adding RPC servers would reduce your CPU consumption. This would increase your throughput if your throughput is actually constrained. But is there a reason you believe your throughput is constrained or that your RPC servers are consuming the CPU?
If you have DB2… God only knows what is chewing your CPU.
Convert to Adabas… that will help!
Where exactly is the high CPU noted? EntireX Broker? DB2? Natural RPC Servers?
You can get counts of number of calls to the servers from SMH/CIS services.
If the modules being called are only called from the Natural RPC Servers, and the servers are using the Global Buffer Pool, you can use SYSBPM to get counts of usage.
If they are called from elsewhere, can you set up a GBP just for the Natural RPC Servers to use? That would enable you to track module usage.
You could start the RPC server with TRACE=1 and count the CALLNATs it reports. Other options include using user exit NATRPC02/03 to log statistical information, or use SYSRDC (more work to set up, but more control over what gets tracked).
many thanks for the responses,
the cpu usage can be observed on the txt file attached.
Please advise if anything else is required.
rpc usage.txt (498 Bytes)
The inverse proportionality EXCP-Cnt / CPU-Time is interesting …
There is no easy way of monitoring a single RPC server “from outside”.
You don’t have Review Natural Monitor (RNM), I assume ?
What you could do is
1.) use the Data Collector (SYSRDC) to get some insight
2.) Establish a local bufferpool for every RPC server instance and dump its contents from time to time
good day, many thanks for all your valuable input, will look at the SYSRDC option.