Dynamic wp after upgrading to ECC 6.07 with kernel 745

[benoit-schmid]

Hello,

We have upgraded a system to ECC 6.07 with kernel 7.45.

After starting sap, wp are kill by the dispatcher:

DpWpDynCreate: created new work process W27-8353

Mon May 30 14:49:12 2016

***LOG Q1O=> DpWpConf, WP Conf () [dpxxwp.c     2915]

DpWpConf: change wps: DIA 20->10, VB 3->3, ENQ 1->1, BTC 10->3, SPO 1->1 VB2 2->

2 STANDBY 0->0 DYN 5->22

DpWpConf: wp reconfiguration, stop W27, pid 8353

rdisp/dynamic_wp_check is set to FALSE.

Could you please tell me why it is killing these processes?

Could you please also describe how it decides to kill 7 BTC, 10 DIA?

Thanks in advance for your answer.

[Former Member · Accepted solution]

Hello Benoit,

Do you have OP Modes in place (tx RZ04) ?

It looks to me as though your OP mode is overwriting your rdisp/wp_no* settings.

Additionally, please have a look at OSS #2212789.

KR,

Amerjit

[benoit-schmid · Accepted solution]

Hello,

Amerjit CHAHAL wrote:

Hello Benoit,

Do you have OP Modes in place (tx RZ04) ?

It looks to me as though your OP mode is overwriting your rdisp/wp_no* settings.

Additionally, please have a look at OSS #2212789.

KR,

Amerjit

In rz04, I only have the dummy op mode with the following warning:

xxx xxx_XXX_00 10 - 3 - 1 3 2 1 20 -

/usr/sap/BAS/SYS/profile/XXX_DVEBMGS00_xxx                                

Total no. work processes has changed, check WP allocation

Regards.

[Former Member · Accepted solution]

Benoit,

Does the WP allocation in the dummy op mode correspond to what you are seeing in SM50 ?

Either way, as a starting point correct or delete the dummy OP mode.

KR,

A.

[benoit-schmid · Accepted solution]

Hello,

Amerjit CHAHAL wrote:

Benoit,

Does the WP allocation in the dummy op mode correspond to what you are seeing in SM50 ?

Either way, as a starting point correct or delete the dummy OP mode.

KR,

A.

No they correspond to the ones defined in the instance parameter.

Regards,

[benoit-schmid · Accepted solution]

Hello,

The dummy mode is correct because it has the numbers defined in the instance parameter.

I do not wnat to correct it. I want to know why SAP is behaving like that.

Amerjit CHAHAL wrote:

Either way, as a starting point correct or delete the dummy OP mode.     

[Former Member · Accepted solution]

Hello,

Please have a look at the following parameters:

rdisp/wp_max_no

rdisp/configurable_wp_no

Failing a response from anyone else, open a message at SAP.

KR,

A.

[raquel_gomez · Accepted solution]

Hi Benoit,

The dispatcher trace file itself shows why the work processes are being stopped:

Mon May 30 14:49:12 2016

***LOG Q1O=> DpWpConf, WP Conf () [dpxxwp.c     2915]

DpWpConf: change wps: DIA 20->10, VB 3->3, ENQ 1->1, BTC 10->3, SPO 1->1 VB2 2->2 STANDBY 0->0 DYN 5->22

DpWpConf: wp reconfiguration, stop W27, pid 8353

Due to Operation Mode definition, the amount of each work process type is redefined. Check on RZ04 transaction how many work processes per each type are defined on Operation Modes.

Note that parameter 'rdisp/dynamic_wp_check' si no longer used for your kernel release (7.45). See Note:  #2001276 - Changed configuration as of 7.40 SP2

"...Profile parameter "rdisp/dynamic_wp_check" is no longer supported because blockade handling contributes to the stability of the ABAP server and should therefore not be deactivated..."

For dynamic work processes, parameter 'rdisp/wp_max_no' should be taken into account. More information can be read on:

http://help.sap.com/saphelp_nw74/helpdata/en/46/c24a5fb8db0e5be10000000a1553f7/content.htm

Regards,

Raquel

[benoit-schmid · Accepted solution]

Amerjit CHAHAL wrote:

Hello,

Please have a look at the following parameters:

rdisp/wp_max_no
rdisp/configurable_wp_no

Failing a response from anyone else, open a message at SAP.

KR,

A.

They are set to the correct values:

rdisp/wp_max_no=42

rdisp/configurable_wp_no=37

Regards,

[benoit-schmid · Accepted solution]

Hello,

Raquel Gomez wrote:

Due to Operation Mode definition, the amount of each work process type is redefined. Check on RZ04 transaction how many work processes per each type are defined on Operation Modes.

You are right.

I have cleared the operation mode.
It was a little tricky because of the following:
In rz04 when I added the instance profile filename the numbers were correct.
Then when you click on save it changes them with the "wrong reduced values".

Now that the operation mode is changed, I still have instant stop/start
although there is no change in the number of processes.
Why do I have this useless behaviour?
###
Tue May 31 10:30:26 2016
***LOG Q1O=> DpWpConf, WP Conf () [dpxxwp.c 2915]
DpWpConf: change wps: DIA 20->20, VB 3->3, ENQ 1->1, BTC 10->10, SPO 1->1 VB2 2->2 STANDBY 0->0 DYN 5->5

Tue May 31 10:33:26 2016
DpHdlDeadWp: W31 (pid=25465) terminated automatically
DpWpDynCreate: created new work process W31-27127

Tue May 31 11:33:26 2016
DpHdlDeadWp: W26 (pid=25459) terminated automatically
DpWpDynCreate: created new work process W26-329
###

Thanks in advance for your answer.

[Former Member · Accepted solution]

Hi Benoit,

Check the below mentioned KBA, if you haven't yet.

1962145 - Dynamic work process starts and stop frequently

Regards

Prithviraj

[raquel_gomez · Accepted solution]

Hi Benoit,

That entries from the dispatcher trace file, point to dynamic work processes being created, and stopped.

Based on the trace, server has defined 20 DIA wps, 10 BTC wps, 1 SPO wp, 1 ENQ wp, 3 UPD wps and 2 UP2 wps. As rdisp/wp_max_no is set to 42 , still 5 dynamic work processes

can be created based on application server load.

See following on-line help:

https://wiki.scn.sap.com/wiki/display/SI/Dynamic+work+processes+configuration#content

Extracting from the page: "Dynamic work processes can be used to modify (increase) the amount of defined work processes, based on application server load requirements. This includes

restarting new work processes and closing them when no longer needed."

This is actually the normal and expected behavior when the dynamic work processes feature is used. All the work processes were created by the dispatcher (e.g., all work

processes were occupied, and more requests were received). When those dynamic work processes are not needed anymore, the dispatcher terminates them, writing that entries.

Regards,

Raquel

[benoit-schmid · Accepted solution]

Hello Raquel,

Raquel Gomez wrote:


This is actually the normal and expected behavior when the dynamic work processes feature is used. All the work processes were created by the dispatcher (e.g., all work 
processes were occupied, and more requests were received). When those dynamic work processes are not needed anymore, the dispatcher terminates them, writing that entries.

I am not sure this is due to the fact that it can create a new wp.

If you look in the log, it first stops a process.

Then it starts a new one.

As far as I understand, lowering the rdisp/wp_max_no to 37 should not change the behaviour,

because the dispatcher could still stop one.

Don't you agree?

Regards,

[raquel_gomez · Accepted solution]

Hi Beonit,

If you check work process ID (PID), you can see that they do not correspond to same process.

Taking as example:

  Tue May 31 10:33:26 2016

DpHdlDeadWp: W31 (pid=25465) terminated automatically

DpWpDynCreate: created new work process W31-27127

Process with pid=25465 is terminated, and a new one is created pid=27127. Checking on the dispatcher trace file, before that timestamp, you should see the line where the dynamic work process with pid=25465 was created.

Regards,

Raquel

[benoit-schmid · Accepted solution]

Hello,

Raquel Gomez wrote:

Hi Beonit,

If you check work process ID (PID), you can see that they do not correspond to same process.
Taking as example:


  Tue May 31 10:33:26 2016
DpHdlDeadWp: W31 (pid=25465) terminated automatically
DpWpDynCreate: created new work process W31-27127



Process with pid=25465 is terminated, and a new one is created pid=27127. Checking on the dispatcher trace file, before that timestamp, you should see the line where the dynamic work process with pid=25465 was created.

It is not the same PID at unix level but it is the same wp for SAP: the 31th.

As the PID is chosen by the Linux Kernel, it is created with a new PID.

By the way, setting rdisp/wp_max_no=37 still causes a process stop. But then no new process is started.

It is still not clear for me why the dispatcher behaves like that.

Regards,

[raquel_gomez · Accepted solution]

Hi,

Please attach into this thread complete dispatcher trace file (dev_disp) and WP31 trace file (dev_w31). Both should be located under work folder on the instance.

Regards,
Raquel

[benoit-schmid · Accepted solution]

Hello,

I have attached the files.

Regards,

Raquel Gomez wrote:

Please attach into this thread complete dispatcher trace file (dev_disp) and WP31 trace file (dev_w31). Both should be located under work folder on the instance.

dev_disp.txt.zip

dev_w24_old.txt.zip

[raquel_gomez · Accepted solution]

Hello,

Dispatcher trace file shows, for instance, WP24 being created and stoped afterwards:

  Tue May 31 16:19:01 2016

DpWpDynCreate: created new work process W24-10406

...............

  Tue May 31 16:33:22 2016

DpHdlDeadWp: W24 (pid=10406) terminated automatically

On the work process trace file, we can't see corresponding info, as dev_w24.old trace file has been attached (and information ends at Tue May 31 16:04:21 2016).

Please attach latest WP24 trace.

Thanks,

Raquel

[benoit-schmid · Accepted solution]

Hello,

Raquel Gomez wrote:

On the work process trace file, we can't see corresponding info, as dev_w24.old trace file has been attached (and information ends at Tue May 31 16:04:21 2016).
Please attach latest WP24 trace.

I reattach the files for the following:

Stop Workp. 33, PID 11718

But honestly the important part is the dispatcher log because

it decides to shutdown on of its managed wp.

The point is: why does it shutdown these wps?

Thanks in advance for your answers-

dev_disp.txt.zip

dev_w33.txt.zip

[raquel_gomez · Accepted solution]

Hi,

Thank you for the new attached trace files.
Checking WP24 trace file, before the work process is restarted, we can see:

A Tue May 31 20:30:51 2016

A  WP has reached abap/heaplimit = 20000000 bytes

M Tue May 31 20:31:08 2016

M  ThWpNeedsRestart: abap strategy == kill, restart

....

M  ***LOG Q02=> wp_halt, WPStop (Workp. 33 9406) [dpuxtool.c   317]

This message 'WP has reached abap/heaplimit' is not an error; just means that the work process was restarted after reaching its heaplimit. Further details given on Note

1571845 - Error: "WP has reached abap/heaplimit" - What does it mean?

Is it parameter abap/heaplimit set to 20MB? Default value for this parameter is 40MB, and it can be increased up to 80MB in case you can find too many work processes restart caused due to this 'WP has reached abap/heaplimit' entry.

When a user context releases its local process memory, this memory remains  occupied with respect to the operating system on account of the process. It only becomes available for other processes when the process itself is ended. Therefore, it's normal that WPs restart after reaching its abap/heaplimit.

Regards,

Raquel

[benoit-schmid · Accepted solution]

Hello raquel.

Raquel Gomez wrote:

A Tue May 31 20:30:51 2016
A  WP has reached abap/heaplimit = 20000000 bytes

Shame on me. I should have read the log 😞

With kernel 720, I had these standard restarts.

But they were not logged in sm21 neither in /var/log/messages.

This is why I was convinced that it was related to a new bug in kernel 750.

Thanks a lot for your diagnostic.