Expert Oracle Exadata - Parent Directory

CHAPTER 7 RESOURCE MANAGEMENT> burn_cpu.sh kosborne x 20top - 18:48:11 up 2 days, 6:53, 4 users, load average: 15.91, 5.51, 2.09Tasks: 903 total, 25 running, 878 sleeping, 0 stopped, 0 zombieCpu(s): 82.9%us, 1.8%sy, 0.0%ni, 15.1%id, 0.0%wa, 0.1%hi, 0.2%si, 0.0%stAs you can see, running the burn_cpu.sh script drove the CPU usage up from a relatively idle 0.3%,to 82.9%, with 25 running processes. Now, let’s see what happens when we reset the cpu_count to 8,which is 50% of the total CPU on the server. Notice that the number of running processes has droppedfrom 25 to 10. The CPU time in user space has dropped to 46.1%, just over half of what it was.SYS:SCRATCH> alter system set cpu_count=8;top - 19:15:10 up 2 days, 7:20, 4 users, load average: 4.82, 5.52, 8.80Tasks: 887 total, 10 running, 877 sleeping, 0 stopped, 0 zombieCpu(s): 46.1%us, 0.7%sy, 0.0%ni, 52.3%id, 0.8%wa, 0.0%hi, 0.1%si, 0.0%stNow, we’ll set the CPU_COUNT parameter to 4. That is half of the previous setting, so we should see theCPU utilization drop by about 50%. After that, we’ll drop the CPU_COUNT to 1 to illustrate the dramaticeffect instance caging has on database CPU utilization. Notice that when we set the number of CPUs to4, our utilization dropped from 46% to 25%. Finally, setting CPU_COUNT to 1 further reduces CPUutilization to 4.8%.SYS:SCRATCH> alter system set cpu_count=4;top - 19:14:03 up 2 days, 7:18, 4 users, load average: 2.60, 5.56, 9.08Tasks: 886 total, 5 running, 881 sleeping, 0 stopped, 0 zombieCpu(s): 25.1%us, 0.8%sy, 0.0%ni, 74.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stSYS:SCRATCH> alter system set cpu_count=1;top - 19:19:32 up 2 days, 7:24, 4 users, load average: 4.97, 5.09, 7.81Tasks: 884 total, 2 running, 882 sleeping, 0 stopped, 0 zombieCpu(s): 4.8%us, 0.8%sy, 0.0%ni, 94.0%id, 0.2%wa, 0.0%hi, 0.1%si, 0.0%stThis test illustrated the effect of instance caging on a single database. Now let’s configure twodatabases and see how instance caging controls CPU resources when multiple databases are involved.In the next two tests we’ll add another database to the mix. The SNIFF database is identical to theSCRATCH database we used in the previous test. In the first of the next two tests, we’ll run a baseline withinstance caging turned off by setting CPU_COUNT set to 16 in both databases. The baseline will run 16concurrent copies of the test query on each database. We’ll let it run for a few minutes and then take alook at the CPU utilization of these databases as well as the readings from the top command. The activeresource plan for both databases is set to DEFAULT_PLAN, and CPU_COUNT is set to 16.[enkdb02:SCRATCH] > burn_cpu.sh kosborne x 16[enkdb02:SNIFF] > burn_cpu.sh kosborne x 16Figure 7-5 shows a summary of our second test. Each line, representing a session foreground process,shows the percentage of one CPU core. This is summed and divided by 16 (CPU cores) to get thepercentage of total CPU consumed. As expected, the distribution of CPU between our two databases isapproximately equal at 44.6% and 45.3%. Looking at the Total Connection CPU, we can see that thedatabases accounted for about 90% of total CPU time for the server.201