2015 Apr 10 2:52 AM
Hi all,
my previous question, was & was focused on improving performance of classification of IFLOT & EQUI objects.
Testing EMIGALL for migration object OBJCLASS I am seeing no performance gains between a single thread update & parallel update threads. IE the single thread throughput is reported as ~the same as the parallel threads throughput combined.
I note in the job logs of my various tests;
I don't see any unexpected migration errors in ether case.
Are there any insights on how I might improve over all throughput using this method? I cant see any control parameters for this object, nor does the Guideline have much information on OBJCLASS.
First world problems 😕
2015 Apr 14 2:37 AM
Hello Daniel,
Without having much insight into your system and infrastructure details or the volume that you are working with, I suggest for you to try below for performance improvement.
1. Run DB Statistics on functional location and Equipment related tables such as EQUI, IFLOT, ILOA, etc. (these are HLO objects that you are updating by way of classification). Also update classification table such as AUSP. These tables mentioned here as a starting point.
2. Also strongly suggest that a performance trace be done on this job to analyze and identify another table or steps that may be a performance bottleneck and maybe a candidate for DB statistics refresh Or some other corrective action.
3. The locks maybe occurring due to a mass update which is as expected. Perhaps to get by that you may want to use "commit buffering allowed" option for this migration object and set to say a number "10" or "20" to start with and see if it helps better the performance. As you would have noticed, locks will also impact performance.
4. Please also refer to Cookbook for ISUMIG Performance and refer to sections for DEVICE, CONNOBJ and DEVLOC. These are HLO objects for classification and there may be some useful insight in that document too.
Hope this helps.
Ash
2015 Apr 14 2:37 AM
Hello Daniel,
Without having much insight into your system and infrastructure details or the volume that you are working with, I suggest for you to try below for performance improvement.
1. Run DB Statistics on functional location and Equipment related tables such as EQUI, IFLOT, ILOA, etc. (these are HLO objects that you are updating by way of classification). Also update classification table such as AUSP. These tables mentioned here as a starting point.
2. Also strongly suggest that a performance trace be done on this job to analyze and identify another table or steps that may be a performance bottleneck and maybe a candidate for DB statistics refresh Or some other corrective action.
3. The locks maybe occurring due to a mass update which is as expected. Perhaps to get by that you may want to use "commit buffering allowed" option for this migration object and set to say a number "10" or "20" to start with and see if it helps better the performance. As you would have noticed, locks will also impact performance.
4. Please also refer to Cookbook for ISUMIG Performance and refer to sections for DEVICE, CONNOBJ and DEVLOC. These are HLO objects for classification and there may be some useful insight in that document too.
Hope this helps.
Ash
2015 Apr 14 3:07 AM
Thanks for the feedback Ashvinder,
I have been pursuing all the above, so great to see Im not missing anything obvious at this point.
I have improved throughput 30% overall so far after the review. Go me.
Regards
Daniel
2015 Apr 14 3:20 AM
Hi Daniel
The main problem running in parallel are SAP enqueues on table KSSK, which is a bit surprising because the call includes an object ID which should be unique.
So when running in parallel could you please check the lock arguments via transaction SM12?
BTW according to the object OBJCLASS documentation commit buffering is not allowed, so be careful in case you do buffer and verify the data after loading.
Yep
Jürgen
2015 Apr 14 3:31 AM
Yes, I had thought the same.
Also I have discounted the concept of commit buffering already after reviewing documentation. Thanks for the heads up anyway.