Data volume increase and how to maintain DP and SNP runtimes

[Former Member]

Hello All:

Currently our CTM run takes about 22 hours. If we add more location products to the CTM run (which we plan on doing), this is going to interfere with other activities that are scheduled over the weekend (system maintenance for example). Our current plan is to add 25% more location products compared to our current volume.

What are some things that one could do to reduce the time taken by the CTM run or keep the time the same even when the volume increases? I want to see if anyone can share their experiences on this topic - CTM Performance improvement.

The same will be true with DP runtimes - currently, the DP forecast process takes close to 3 days - this includes utility jobs, realignment and the actual forecast process itself. It it takes more time, then it will encroach into the S&OP cycle which is a monthly cycle. We plan to add 25% more CVCs to the

DP process compared to our current volume.

In general, what are some things that one could do in order to take increased volumes into account? Any of your thoughts and experiences will be highly appreciated.

For example, one automatic suggestion is to use the HANA versions of SCM (SCM 7.0 EHP3 for example). Of course, this comes with a hefty price tag and I am not aware of solid data that will actually show reduction in runtimes.

Thanks in advance for your thoughts.

Satish

[Former Member · Accepted solution]

Hi,

In jobs use Parallel Processes, in addition to this create jobs which run in parallel (without having dependencies), say for one region one job and for another other jobs.

Also In DP, delete the CVC for which you have no forecast.

In CTM, even if the above suggestiond doesn't work , you can do some development wherein you can run CTM (master data selction) for only those products which have Demand/Supply.

Anil

[Former Member · Accepted solution]

Anil:

Thanks for your inputs on this. Hoping to see some more useful inputs from other members of this list.

Satish Vadlamani

[former_member225716]

Hi,

There are many ways to reduce run time.

1. Divide background processes into smaller subsets (new jobs) and run them in parallel to improve performance. Since the same objects / CVCs cannot be processed by the parallel processes due to locking problems, necessary steps to be taken while splitting the processes.

2. Extracting data from LiveCache as few times as possible improves performance. Hence for reporting, only extract data that changes real-time and all calculated data ( after night batch process) to be extracted only once a day.

3. While extracting data from Planning area, please see this post “Planning Area data source Parallel processing”

4.While loading data from BW to APO, analyze how much data in the past do you require for planning and accordingly maintain selections while extracting. This could save a lot of time from your process chain run time

5. While working with background jobs in DP, it is recommend that the “Generate log” indicator is used in the planning job. However, you should delete log files on a regular basis because performance deteriorates as the log file size grows.

6. You need to develop a procedure to delete obsolete CVC;s periodically, it will give very good results.

Best Regards,

Sachin

[Former Member]

In Such Cases,

Analyze the data & find out how many CVCs are obsolete, take the back up for future reference if required & delete them.

Optimize your process chains by applying parallel processes

if you are using Automatic forecasting models, then by analysis of the product behavior you can assign the specific group of products so that the processing time will reduce.

Regards,

Gajendra

[Former Member]

Hello Satish,

For CTM optimizer you must have a separate machine with a last 2 CPU.

Thanks, Marius

[Former Member]

Hi Marius,

I'm curious about the 2 CPU requirement. The optimizer is usually a separate machine that holds all of the optimization executables. If you look only at CTM, it is a single-threaded heuristic. There are three threads involved in a planning run. 1 to read data from the SCM system, 1 for planning and 1 to write back the data. The first thread is idle during planning so it could be considered a 2 thread system. Note 1379526 implies that you can use 1 CPU with 1 or 2 cores. The second core is for a different CTM run and can be used when parallelization is turned on. This may be when the problem is broken into sub-problems due to size. More important for CTM performance is the speed of the processor.

Note 855229 is the FAQ on CTM.

What am I missing?

Best Regards,

Mike

[Former Member]

Hi Maclean/ Satish,

At least 2 CPU if he want to run parallel jobs!

Note 1577112 - SCM Optimizer: Sizing Information (attachments - sizingsheetCTM.zip) confirm that the number of used CPU should be equal with the parallel CTM runs. The critical factor of CTM is the single-threaded performance of the CPUs. The recommendation is to use the fastest possible CPU for CTM (as you already mentioned).

In the global customizing settings the package size for creating orders, pegging or orders selections with asynchronous LiveCache update can improve a lot the performance. If you want to use parallel jobs, don't forget to check the box for Allow parallel CTM runs for a planning version in the CTM global customizing.

So, in my opinion I think that 2 CPU with more than 3 GHz and 3-4 GB RAM should be a good solution. From my experience I can tell you that 22 hours is not at all normal. We had the same issue few years ago and after resizing we have passed from 12-14 hours to 20 minutes. 

Thanks.

Regards, Marius

[marianoc]

Hi Satish,

There are lot of things you can do in order to improve the performance in CTM.

Take a look of this note:

Note 1070611 - CTM order reading performance problem

After  implementing this note the fast order reading functionality can be   activated if CTM planning parameter FAST_READ is used with value1= X.

Also, read these articles:

Sometime ago, we have maintained the following parameters to improve the performance:

EXCLUDE_LC                    X                                                      

FAST_READ                      X                                                      

FIX_PEG_LC                     X

Kind Regards,

Mariano