SUM : INITSUBST : Processes Distribution

[Former Member]

Dear Gurus,

We are performing Support package upgrade using SUM tool, we have performed using SAINT on DEV and it took 8 hours of downtime on QAS we performed using SUM and downtime was around 3 hours.

Resources

OS - Linux suse 10

QAS - CPU 2 , RAM - 16 GB

PRD - CPU 16 , RAM - 160 GB

Process numbers provided during QAS upgrade via SUM-

Enter the maximum number of background processes during the update:

BATCH PROCESSES (UPTIME): 10

BATCH PROCESSES (DOWNTIME): 12

Enter the maximum number of parallel DDL processes:

DDL PROCESSES (UPTIME): 6

DDL PROCESSES (DOWNTIME): 8

Enter the maximum number of parallel import processes:

R3TRANS PROCESSES (UPTIME): 6

R3TRANS PROCESSES (DOWNTIME): 8

Enter the maximum number of parallel phases to run:

PARALLEL PHASES (UPTIME): 4

PARALLEL PHASES (DOWNTIME): 4

We will like to achieve reduce downtime for PRD instance considering client requirement for less downtime, can anyone guide how much processes shall we set to achieve less downtime?

Total processes available on CI - 60 (Dia/Back)

Kindly guide to achieve better result.

Thanks,

Warm Regards

[Former Member · Accepted solution]

Dear All,

Thanks for your support.

We provided below parameters and downtimecompleted in around 2 hours.

BATCH PROCESSES (UP/DOWNTIME): 16/20

DDL PROCESSES (UP/DOWNTIME): 10/20

R3TRANS PROCESSES (UP/DOWNTIME): 12/24

PARALLEL PHASES (UP/DOWNTIME): 10/12

System had good resources.

Please note system may have negative impact if resources are not adequate.

Regards,

[Former Member]

I would try below

BATCH PROCESSES (DOWNTIME): 16

DDL PROCESSES (DOWNTIME): 10

R3TRANS PROCESSES (DOWNTIME): 16

PARALLEL PHASES (DOWNTIME): 12

Ensure you have at least 16 background processes on the primary application server

[Former Member]

Former Member,

Thanks we can increase Background processes, no issue in that.

Is there any limit to increase it to 16 , We are thinking about setting as 24.

Also , can you tell me what is this PARALLEL PHASES (DOWNTIME) option ?

Thanks

Regards,

[ACE-SAP]

Hi James

You could also try to get a license to kill your old SLES 10 () and upgrade it to 11 sp3...

You could get information on the SUM phases in the update guide.

https://service.sap.com/~sapidb/011000358700000783082011E/SUM10_Guides.htm

... But it does not tell which phases can be run in parallel.

When your saying :

    Total processes available on CI - 60 (Dia/Back)

Does that means you've got 60 DIA and 60 BTC or just a total number of 60 WP, if so how many DIA & BTC do you have ?

Best regards

[Former Member]

Dear ,

Plan for suse upgrade is pending for customer approval since long.not sure when will it get approved

We have 60 = 30 + 30 DIA/BTC process on CI. We will change that at the time of operation mode.

System is on HA environment along with 8 Applications Instances and 3 background servers.

System have good resources.

These are the phases that make use of tp/R3trans parallelism.

PHASES	DOWNTIME-MINIMIZED	RESOURCE-MINIMIZED
SHADOW_IMPORT_UPG1	uptime	downtime
DDIC_UPG	uptime	downtime
SHADOW_IMPORT_UPG2	uptime	downtime
SHADOW_IMPORT_INC	uptime	downtime
TABIM_UPG	downtime	downtime

I am looking into any criteria which we can use to set these processes number during configuration phase.

Like for example 1.3 * CPU = R3trans count something like that etc.

Thanks for your udpate.

Regards,

Bond

[ACE-SAP]

I've never found any official rule for the number of R3trans process per CPU...

I guess raising it too high could have negative impact, each R3trans process writes his own log file that are merged when the whole order is imported... these logs are huge and at the same time R3trans is inserting data in the DB... So by the end I think the limit will be more on disk than on CPU

Regards

1127194 - R3trans import with parallel processes

Therefore SAP is not able to suggest the ideal value for 'n'. Instead, SAP recommend to start importing with "parallel=2", and to increase this number by and by until the performance gains stagnate.

1309506 - SPAM/SAINT with parallel R3trans

Within section 'Parallel R3trans' specify the 'Number of parallel processes per R3trans'. We recommend an initial value of 4. For HANA databases we recommend an initial value of 10.

[Former Member]

If it were QA, you can try it with 24 before doing PRD.

I have run into deadlock issues when using 18. But the SUM retry worked and because of deadlock it took extra 1-2hour for me.

So I wouldn't try such a large number in PRD directly.

16 is still a lot and it can make use of all your CPU during the parallel phases of the upgrade.

[Former Member]

Hi Former Member thanks for sharing your experience. Apologies , I wrongly  update CPU count , its 16 CPU each with 4 core , so I guess CPU count is 64.  Respective activity on QA is alreaddy completed and due to project go live date ,we cant built another server to test so we will directly perform this activity in PRD system.

Can you update, what was the configuration of your system when you faced deadlock issue with parameter as 18? what were other paramters ?

BATCH PROCESSES (DOWNTIME): ?

DDL PROCESSES (DOWNTIME): ?

R3TRANS PROCESSES (DOWNTIME): 18

PARALLEL PHASES (DOWNTIME): ?

Regards,

[Former Member]

BATCH PROCESSES (DOWNTIME): 18

DDL PROCESSES (DOWNTIME): 10

R3TRANS PROCESSES (DOWNTIME): 18

PARALLEL PHASES (DOWNTIME): 10