SGEN hangs sequential read TRDIR

[nicola_blasi]

After a  kernel upgrade from 7.01 to 7.21_ext in a SAP SCM 7.0 i have problems during execution of sgen.

I want to generate all objects of selected components....but when i arrive to choose the applications server where i want sgen has to run, and

pressing continue it remains in hang like the picture in attachment.

I see that it hangs in a sequential read in table trdir....that is a select * from REPOSRC.

This selection runs for hours until in next step i finally start the sgen.

I did statistics on table reposrc but the problem remains. Could it be a db problem? In other systems this phase is faster...only few minutes in worst of cases.

How can i solve this problem?

Thanks

Nickk

[cris_hansen · Accepted solution]

Hi Nicola,

It seems that SGEN is slow because of lack of available work processes (DIA? BGD?). Please check this in SM50/66 and rearrange your WPs in RZ03 (for example).

Do you have any error message which you can see from your DB alert log during such execution, etc? Sometimes defragmented state of the database may cause the difference too.

Transaction SGEN determines the so-called generation set through the options given in the first screen and the content of the file REPLIST. The resulting set is saved in table GENSETC.

After that step the SGEN starts a maximum of 8 generation jobs in batch which then do the dirty work and process the content of GENSETC.

So there are in actually two parts which are citical:

First part is SGEN related and means the calculation of the generation set.

Second part is the performance of the gen. jobs and this is out of control of SGEN. This is SAP system related and depends on resources of the system itself like main memory, number of CPU and last but not least, the database performance.

I would say that the runtime of the gen jobs is heavily depending on the database performance of the system. All the eight jobs access the tables REPOSRC and REPOLOAD and some other administrative tables thus creating heavy database load.

Hence the performance of the gen jobs is not SGEN related, SGEN cannot do anything after having started the batch.

So there are two option to be looked at:

1. If there are enough system resources like main memory, number of CPU AND enough SAP system resources like number of batch jobs and the database load is not near 100% THEN you could think about increasing the maximum number of batches to perform the generation. This is meant for all instances. That means a modification to change the max from 8 to say some higher value like 16.

2. If the runtime of the batch is the issue then a general look into DB performance is helpful. I cannot tell the details of the DB02 transaction which could give some performance hints as well as native DB tools.

The runtime of the batch is out of control of SGEN, but are the performance factor in generation.

In case that the DB performance or the general SAP system batch performance is the issue than I would not expect big differences in runtime of the generation jobs between SGEN and SAMT. The basic work is the same.

Especially when the database is the limiting factor both the SGEN batch jobs and SAMT should take a similar amount of time.

Relevant SAP notes:

589124 -  Performance improvements when Support Package imported

1002815 - SGEN: Performance Issue

1132507 - SGEN: Using maximum number of free work processes

1989778 - FAQ: SGEN

Kind regards,

Cris

[nicola_blasi · Accepted solution]

Hi Cris

thanks for your useful info about sgen.

In my problem we figured out a general problem of slowness in the storage ...above all in reading and writing on disks:

Top 5 Timed Events                                         Avg %Total

~~~~~~~~~~~~~~~~~~                                        wait   Call

Event                                 Waits    Time (s)   (ms)   Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

log file sync                        14,901       1,423     95   41.6     Commit

log buffer space                        848         811    956   23.7 Configurat

log file parallel write                 649         589    907   17.2 System I/O

gcs log flush sync                   18,406         531     29   15.5      Other

gc cr block busy                        435         507   1165   14.8    Cluster

thanks

Nick