290 likes | 457 Views
Concurrent Managers 101 & 202. Gary Piper UKOUG 2004 Birmingham 1 - 3 November 2004. Case 1: The Case of Too Many Managers…. Standard and Custom Managers As a general rule: No more than 1.8 to 2 * the number of CPU’s Common misconceptions: More managers are better
E N D
Concurrent Managers 101 & 202 Gary Piper UKOUG 2004 Birmingham 1 - 3 November 2004
Case 1: The Case of Too Many Managers… • Standard and Custom Managers • As a general rule: No more than 1.8 to 2 * the number of CPU’s • Common misconceptions: • More managers are better • 35 on 2 CPU’s ( 17.5 ) • 70 on 8 CPU’s ( 8.8 ) • 48 on 12 CPU’s ( 4 ) • Double the number of managers overnight Resist the urge to add managers
Financial Statement Generator… • Assume 1 FSG will consume 1 CPU • Limit the number of FSGs that can run to less than the number of CPUs • Create a custom FSG manager and setting the number of manager processes to less than the number of CPUs • This reasoning should hold true for any resource intensive process
Case 1: Example… Configuration: 8 CPU & High FSG usage • Advantages • Disadvantages • Application Impact • Business Impact • Corrective Action
Beware the Silver Bullet… • Site was heavily customised • Several custom programs have an average run time of over 10 hours. • Account hierarchy reports take over 14 hours to run • The site has a seven segment chart of accounts with over 200,000 code combinations and no indexes. • Other Sessions: • 103 Discoverer sessions • 30 Forms sessions • 1 ADI session • 5 Toad sessions In Production • 1 SQL*PLUS In Production
Case 2: Sleep and Cache… • Configuration • 4 CPUs • Max 8 standard managers • No custom managers • Site experienced exceptional growth • In this example: • The concurrent program runs in less than 6 seconds. • Items are scanned at a rate of 10 per minute
Single Manager… Managers: 1 Sleep: 60 seconds Cache: 2 Execution rate: 2 per min 48 80% Scan rate: 10 per min Input rate: 600 per hour Run rate: 120 per hour Deficit: 480 runs per hour Approximately 4 hours backlog per hour
Multiple Managers… Managers: 3 Sleep: 60 seconds Cache: 2 Execution rate: 6 per min 48 48 144/180 80% 48 Scan rate: 10 per min Input rate: 600 per hour Run rate: 360 per hour Deficit: 240 runs per hour Approximately 40 min backlog per hour
Single Manager… Managers: 1 Sleep: 60 seconds Cache: 10 Execution rate: 10 per min Scan rate: 10 per min Input rate: 600 per hour Run rate: 600 per hour Deficit: 0 runs per hour ( theoretical )
A More Practical Solution… Managers: 2 Sleep: 60 Seconds Cache: 10 Execution rate: 20 per min Scan rate: 10 per min Input rate: 600 per hour Run rate: Up to 1200 per hour Head room: 600 per hour
Case 2: Sleep and Cache Example… Configuration: 12 CPU & 3,500 request per day 23 additional managers ( INV,OE, PO, RCV) @ 5 second sleep 567 • Advantages • Disadvantages • Application Impact • Business Impact • Corrective Action
Hidden Resource Usage… Slow Q Slow Q
Lookup Frequency… Manager Configuration Manager Impact
Additional I/O… • Per Request (5,000) • Insert row (7) Indexes = (35,000) • Update to running (2) indexes = (10,000) • Update to complete (3) Indexes = (15,000) • 5,000 requests generate 60,000 index activities • Manager reads @100 per Min 144,000 per day plus 144,000 index lookups • User accesses ( has it finished yet? ) • Conflict Resolution Manager • Higher overhead • fnd_crm_history
Review Request Activity… 14 Standard Managers Graphs reproduced with permission of PIPER-Rx
Review Running Requests… 14 Standard Managers Graphs reproduced with permission of PIPER-Rx
Case 3: Specialisation Rules Gone Wrong… • Specialisation rules can be defined at the following levels: • By Program • By user • By Oracle User • Complex • Request Type • Once created are hard to find • Creating a specialization rule will: • Rebuild the fnd_concurrent_worker_requests view • Restart the concurrent managers • Not a good idea during month end • KIS principle
Spcialisation rules… • Systems Administrator • Concurrent • Manager • Define • Select the Manager • Select specialization
Preparation… • Step 1 – Create a concurrent manager “slow” • Step 2 – Activate the manager ( multiple steps ) • Step 3 – Reduce the number of STD managers • Step 4 – Ensure the new manager is active • Step 5 – Set the specialisation rules • “Include” the selected program in the Slow Manager • “Exclude” the selected program from the Standard manager • All custom developed programs should be initially assigned to the “slow” queue and earn the right to be moved to the “normal” queues
Request Types… Request Types
Request Types… • Change the queue a program will run in • Cannot change the queue once the request has been submitted • Can prevent a program from running • Assign a program to run in a queue that has been deactivated - “Pending Error” • Once activated, pending request will run • Assign a program to a request type “Don’t Run” that has not been assigned a manager
Request Types (cont)… • Create a Request Type • Concurrent > Program > Types • No impact • Create Specialisation Rules • Concurrent > Manager > Define – Specialisation Rules • Disallow & Allow • FND_CONCURRENT_WORKER_REQUESTS view • Assign a program a request type • Concurrent > Program > Define
Example: Overnight / Don’t Run… • Create a manager that runs only overnight • (work shifts * 2) • Create a request type ”overnight” • Disallow ”overnight” from standard / allow in the overnight manager • Assign the program the request type ”overnight” • Request type “don’t run” • Create a request type “don’t run” • Do not assign to a manager • Assign the program the request type “don’t run”
Questions… Questions or Visit us at the Quest stand Disclaimer: All material contained in this document is provided by the author "as is" and any express or implied warranties, including, but not limited to, any implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of any content or information, even if advised of the possibility of such damage. It is always recommended that you seek independent, professional advice before implementing any ideas or changes to ensure that they are appropriate
Concurrent Manager 101 & 202 Gary Piper OUUG 2004 Birmingham 1 - 3 November 2004