AutoSys Workload Automation

This past w/e we migrated 14+K jobs from r11 to 11.3.6. Users are stating that autorep sometimes takes >15 seconds to respond on the 11.3.6 instance. I have 3 x 11.3.6 instances in our eng lab and I can see this on 1 of the instances. Just curious if anyone else has seen this.

15 seconds really? This can be caused by how they are doing autorep and

how eem is setup.

Steve C.

Stirling Systems Group

If you have used the migration utility and are running off an Oracle database, a re-index will help

- Chris

another good reason to treat a new instance like a new instance

just my 3 cents

Steve C.

Stirling Systems Group

The 11.3.6 instance is new...new DB, new EEM and new hardware...we'll look into EEM (policies imported from r11 EEM) and the DB. Thanks.

How many jobs/machine does autorep return?

Do you get same problem with autorep of one job?

If yes do a permission check in EEM and see the response time, you may print debug information to see how many policies it is traversing.

Ops team had DBA's re-index DEV and UAT databases. The improvement was immediate. Thank you all for the input.

Just want to add one more comment. The DB re-index helped in PROD but didn't completely eliminate the autorep response lag. Investigation showed the lag was cyclical occurring approximately every 30 seconds. This corresponded to an EEM setting where EEM updates its cache every 30 seconds. The app server variable  AS_IAM_CACHE_UPDATE is defaulted to "-2". From the Admin Guide:

(Section 2: Environment Variables)

AS_IAM_CACHE_UPDATE

Specifies the time (in seconds) that the application server polls the external security server for modified security policies.

Default: -2

Limits: -2, -1, or higher

Note: If you set this variable to -1, the application server does not poll the external security server for policies. If you set this variable to -2, the application server obtains the poll interval from the external security server configuration.

We set...

AS_IAM_CACHE_UPDATE=300 ; export AS_IAM_CACHE_UPDATE

...in $AUTOUSER/autosys.<shell>.<host> on the App Server machine and the autorep lag issue was resolved.

I know this is an old post, but I wanted to post a better way - for posterity.   Instead of setting the environment variable, you can set the cache update from EEM (central).   This will save you some time and effort.   Incidentally, the same can be done for WCC.   Just login to the appropriate application within eem - got to the config tab - select the application link - then make your change there.    A final note, more is not always better...  300 may be as high as you would want to go.

Login to EEM with the application you wish to increase the cache timeout for:

Set the timeout and cycle the respective servers - note that the application server and WCC are the actual consumers of eem, and the ones which should be cycled.   You'll not need to cycle schedulers for cache timeout settings to update.

Hi Eliot

We had this same issue with base r11.6 WAAE install. Always on the first autorep the response time was very slow, after the first autorep is was faster. There is a missing index in r11.3.6.0 which is fixed in incremental 1 -

Refer RO73603.txt, this issue was item 57 in the fix list for incr1.

57. AUTOREP -D RESPONSE TIME BAD

In a heavily loaded instance, when you issued the autorep command              

with the -d option, it stopped responding and timed out. In r11.0,             

there is an index on the ujo_proc_event table that begins with the             

joid column , was missing in Relase 11.3.6

We also have a slow autorep response time in our non-prod environment primarily due to EEM configuration and volume of users. This is separate issue, the r11.3.6 incr1 fixed the slow response on autorep which occurred before we loaded up the EEM database.

Hope this helps

Greg Bradley

HP Enterprise Australia