AutoSys Workload Automation

JIl load with SP6 Cumulative 1 ..

It appears many checks were added to insert/update which has slowed down jil 30 fold at least.

i could update 1100 jobs in 2 mins with Sp1-Sp4. Now it takes real 63m31.663s

Is this my design?

Steve C.

autorep has also slowed down. :-| is this all part of memory consumption fixes? 

Hello Steve

If your database is Oracle, can you change cursor_sharing to force and rerun the test.

Performance improvement should increase a lot

Click also this link: Slow Autorep about DB_CONNECTIONS settings in Autosys and cursor_sharing in Oracle

In a HA environment, point your list of application servers in your $AUTOUSER/config.$AUTOSERV file to the shadow machine first. This is to narrow down the problem .

If there is still a performance problem, please open a case at CA support

Regards

Jean Paul

Let me check the cursor sharing/./. Thank you 

as for SB_Connections and sched_scale. i have that at a very healthy and adequate setting.. Thank you ..

change_cursor to force did it. 

Merci beaucoup Jean Paul 

Jean Paul, do you know if this impacts the API performance as well?

KB TEC1012093 documents a few potential causes including the Oracle CURSOR_SHARING=FORCE option. CA is committed to improve our KB standards and striving to help customers find answers for known issues, online and save time. Please consider searching our knowledge base and let us know if it lacks anything, we'll do our best to improve.

FYI -

May i suggest adding this to the SP6 and CUM1 upgrade 

per

CAUAJM_E_10656 The database has encountered a critical error. 

perl reindexDB.pl

for good measure.. 

and if later on you receive similar event table collissions try it again.

Obviously .. the upgrade and influx of jobs .. skews data. 

or so my findings have revealed, thus far 

--Update - well over an hour and it occurred again. so obviously we are having data collisions :-(

back to the drawing board.. 

Steve C.

Hi Steve

About the last problem reported, if it happens on a regular basis, please open a call with Oracle support.

The Oracle client is sending wrong data to Autosys.

Thanks and Regards

Jean Paul

So here's my analysis:

1. A CA needs to fix the event query binding. :-)
2. change_cursor=SIMILAR is probably the better choice.
3. 11g is fine with the setting 
4. 12C has a bug and make sure you have it patched.

For anyone on Oracle now ... change_cursor amps up the queries 100% it would behoove you to NOT set it 

I stressed tested 1100+ per minute. most lag is at the box level which is expected, tolerable and tuneable 

I found that performance takes a hit during QUEWAIT/RESWAIT .. but all in all ..SP6CUMUALTIVE 1 seems ok.

Hope this helps and thank you! 

Steve C.

I am having this issue with  11.3.6 sp 6. Jil and autorep are both all slow. I am using MS SQL db. Is there a similar setting need for MS SQL. Not having this slowness issue with 11.3. sp1 

When we set it to EXACT we clear up contention and autosys itself runs faster, but autoreps slow to a crawl and WCC is affected... Suddenly the collector can't get all the data fast enough and reports wrong in wcc. 

When we set it to FORCE it runs fine for awhile until contention builds up and we start to see autosys latency up to 12 seconds. 

Our current workaround is to set it to EXACT  when we see latency start to build, then put it back to FORCE. 

Is it 12c db?

Nexttime you see contention. Try a reindex.

Steve C.

Yes 12c... did the reindex, didn't help.  Only a cursor_sharing parameter swap clears it up. 

There’s a few patches from CA and from oracle you will need for 12c

Steve C.

Hello

About this topic with cursor_sharing=force to get better performances:

We're in the process of improving SQL performance at a code level using input bindings which will be included in 11.3.6 SP7.

When the CA WAAE 11.3.6 SP7 code improvements are GA, the DBA will need to set cursor_sharing to default(i.e. EXACT)

Regards

Jean Paul

UM. i am testing that fix now and i was told leave it at FORCE.

JeanPaul, have Al contact me offline. so we make sure what is going on. 

Thank you 

Steve C.

Hi Steve

I consulted Al, and you got a  partial fix for a specific query. That's why you still have to run with CS=force

We plan on addressing ALL our hardcoded static queries in SP7

Regards

Jean Paul

Thank you

Steve C.

Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.