cancel
Showing results for 
Search instead for 
Did you mean: 

Strange disp+work phenomenon

Former Member
0 Kudos

Hi Everyone,

We are seeing a very strange behavior in our ECC environment. I tried to figure out reason but the system behavior defies performance rules. I had checked with other consultant if my understanding is wrong but I got similar analysis from them.

Setup

ECC 6 EHP 7

CI Solaris SPARC

3 App servers solaris x86

All interface/rfc calls to SAP goes to CI server only.

Background jobs distributed across the app and CI servers

Users logs in only to App server logon load balance, so no CI logging except for tech team.

Situation

There are calls from external system to SAP mostly for read and some times for update records. that call use "/sap/bc/soap/rfc" service.

Now, User complained that system is running slow between 6:00 and 10:00 am.

We checked the calls and found in STAD that the response time mostly consist of " Wait for work process", during this time.


My analysis says this may be due to lot of jobs running in background "on CI" and as per FIFA stack protocol, the RFC call get in queue and waits free wp and possible solution will be to increase BG wp and see if we can reschedule some of the jobs to other app server during this time.

But before I could implement any change, another consultant raised that this may be due to one long running job, which runs on app server.


Action taken

The functional team had changed the job schedule to run it on weekend and strangely, after rescheduling the job on app server, there is no wait time for wp in CI.


Question

How rescheduling a job on app server can affect availability of work process on CI? If it is accessing DB and the call goes into DB wait due to lock or take longer time for processing in same server or even wait for longer time to allocate wp if rfc call made and job is running on same server I would not be surprised but two different process and running on two different servers affecting allocation of WP is what going above my head.

This can be co-incidence and may be issue is stil there and just not happened for today but any ideas?


Sample from STAD

DateStartedServerTransactionProgramWpUserResponse
time (ms)
Wait time
(ms)
% wait timeTime in
WPs (ms)
CPU time
(ms)
DB req.
time (ms)
VMC elapsed
time (ms)
Memory
used (kB)
Transfered
kBytes
17/12/20157:37:07pkgdbs_Sxx_xx SAPMHTTP /sap/bc/soap/rfc36WEBUSER14,86614,70499162807702,01156.9


Details of response time

Analysis of time in work process

CPU time                      80 ms

RFC+CPIC time                  0 ms

Total time in workprocs      162 ms

   Response time           14,866 ms

Wait for work process     14,704 ms

Processing time               83 ms

Load time                      1 ms

Generating time                0 ms

Roll (in+wait) time            0 ms

Database request time         77 ms

Enqueue time                   0 ms


The job was running on app server


Any ideas?


Thanks and Regards

Amit


Accepted Solutions (0)

Answers (1)

Answers (1)

ACE-SAP
Active Contributor
0 Kudos

Hello Amit,

I hope your problem is solved, if not few clues:

1) RFC calls access to workprocess could be restricted by some quotas

74141 - Resource Management for tRFC and aRFC

2) The scheduled job might itself launch RFC call (lot of standard programs do RFC calls, for example to be able to perform parallel actions)

3) There is a way to prevent jobs from running on a specific instance (server group with the name 'SAP_DEFAULT_BTC').

786412 - Determining execution server of jobs w/o target server

Best regards

Former Member
0 Kudos

Hello Yves,

Thanks for your tips. The problem got resolved by shifting the batch program at different time schedule.

Though I am still trying to understand that how a job specifically running on an app server and making no rfc call can affect external rfc calls coming to CI and making no update in DB. I initially thought it may be a coincidence but 4 weeks straight and we got no issues after change of schedule.

Thanks and Regards

Amit