Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning

Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning
Earl Jew IBM STG Lab Services

ABSTRACT Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning
Decades ago at the beginning of IT on Unix, there was a universally expected shortfall of CPU cycles for enterprise workload processing -- because back then, compared with today, there was one dumb slow CPU. Today we have a vastly different landscape; today we are working with high-concurrency large-scale multi-threading multi-CPU shared-cache shared-memory architectures. Today's POWER systems are so powerful, they routinely deliver exceptional performance without tuning. This is good. But now with this great abundance of CPU processing performance and concurrent capacity, we must begin managing CPU resources from the other end. This other end is the emerging paradigm of CPU Efficiency Tuning. Come and hear a new perspective. Earl Jew cell Consulting IT Management Consultant - IBM Power Systems and IBM Systems Storage IBM STG Lab Services Power Systems Delivery Practice 400 North Brand Blvd., c/o IBM 7th floor, Glendale, California, USA 91203

Thank you for honoring me with your time, attention, attendance. As before, I will follow the format of: What to Know How to See It Then Do This Let me know if I can help – because I’m obliged to support what I tell you.

Power/AIX: Highlights from All Other Sessions

Strategies and Tactics for All-Out/Everything-In CPU Processing Performance

Buy&Build to eliminate/reduce the latencies of maneuverable inter-SRAD/inter-node: L2/L3 cache accesses, thread/vCPU migrations, DIMM accesses, PCIe traffic, etc. Power8 introduces Three Scopes of Cache Coherence, (Power7 has Two scopes of Cache Coherence). Power8 added SRAD-only Cache Coherence. The next wider scope is Group-only CC. And the widest scope is Everything CC.

The other way that having more CPUcores per SRAD distinguishes Enterprise-class from ScaleOut class system servers are the sibling cache accesses between active CPUcores within the same SRAD. Any CPUcore can access its own L2/L3 faster than any other L2/L3 cache. Any CPUcore can access the L2/L3 of other CPUcores of the same SRAD at a slightly slow speed. These are called sibling cache accesses. Having more active Power8 cores per SRAD grants more sibling cache accesses for multi-threaded workloads running concurrently across more cores within the same SRAD.

Power/AIX: The Traits and Tactics of CPU Processing Efficiency
Tier -1: Dedicated/Dedicated-Donating – fastest but wasteful, hard SMT-2/-4 Tier 0: SPLAR w/virtual CPU count <= active CPUcores per SRAD, hard SMT-2, CPU entitlement equal to virtual CPU, Folding disabled, perhaps still wasteful Tier 1: set virtual CPU count to the minimum needed, hard SMT-4, set CPU entitlement per virtual CPU, Folding remains enabled Tier 2: set virtual CPU count to the minimum needed, hard SMT-4, set CPU entitlement per virtual CPU, Folding remains enabled, set AIX:schedo:vpm_throughput_mode=2 (dynamic/no reboot needed) Tier 3: set virtual CPU count to the minimum needed, hard SMT-4/-8, set CPU entitlement per virtual CPU, Folding remains enabled, set AIX:schedo:vpm_throughput_mode=4 (dynamic/no reboot needed)

Efficiency is Value. Productively using ~all of what you have is good Efficiency is Avoidance: Not doing a thing is faster than doing it Efficiency is Minimizing Waste, i.e. “Eat your rice!!” Efficiency is Keep&Hold and not “99 bottles of beer on the wall” Efficiency is a Full Pantry and not Visiting Vons everyday Efficiency is Working at Home and not commuting everyday Efficiency is Minimizing Interruptions, i.e. no more phantom interrupts Efficiency is Knowing and Prioritizing Your Workloads, i.e. a DayTimer Efficiency is Evolving the Wetware to the capabilities of the technology

Layer 0: Power8 Server Hardware and PowerVM/PHYP Layer 1: the PHYP firmly assigns/allocates DIMMs and CPU entitlement to the SRADs of an LPAR and then maps the logical CPUs of virtual CPUs to each SRAD, i.e. AIX:lssrad -av Layer 2: folded-up/active virtual CPUs are scheduled on&off CPUcores or folded-down when not busy enough -- on a larger/longer scale of one second intervals, i.e. AIX:vmstat Layer 3: when folded-up/active virtual CPUs have shorter stalled periods of nil work, the PHYP cedes the virtual CPU off the CPUcore -- but keeps the virtual CPU folded-up/queued for work Layer 4: when a virtual CPU is served by a CPUcore, it manifests as 1|2|4|8 logical CPUs with the dynamic SMT-mode shifts; logical CPUs can 1) execute workload threads or 2) run AIX:wait while waiting or 3) logical CPU context switch, i.e. AIX:mpstat -w:lcs Layer 5: allocation of decrementer intervals of the most granular apparent units of CPU attention to 1|2|4|8 logical CPUs:virtual CPU:CPUcore:second, i.e. AIX:mpstat -a:dec Derived by deconstruction of apparent AIX output, i.e. this is my Best Guess of the Hidden Truth No references offer a structured breakdown of the CPU nomenclature, so I conjured the above

The Gap between Performance Tuning and Capacity Management
earlj Premise#1: When long interval data collection averages spikes-and-brief-bursts as minor peaks, we don’t see them -- yet they can cumulatively comprise the nature of performance issues. It is not the workload running below the ceilings of exhaustion that should concern us. It is the repeated micro-exhaustion within the same that should concern us. Illustration Credit: IBM Power Systems:Tools and Strategies for Capacity Planning – Michael Quaranta/IBM Lab Services; June 2017

Other perspectives concern spike/burst intensities of the runqueue|device interrupts|system calls|context switches, cs:ics ratio, dynamic SMT-mode shifts, inter-SRAD traffic, thread and virtual CPU migrations, ilcs vs. vlcs, etc. Long ago when systems were smaller/simpler/slower, the above factors hardly mattered. And our monitoring practices were founded on the simpler principles of that time. Today though, the above factors are essential to understanding performance yet no one seems to know nor care about the above factors...hence, The Gap. earlj Premise#2 If you can’t see the root symptoms of a performance/efficiency problem, … then there is no performance/efficiency problem – right?

Other perspectives concern spike/burst intensities of the runqueue|device interrupts|system calls|context switches, cs:ics ratio, dynamic SMT-mode shifts, inter-SRAD traffic, thread and virtual CPU migrations, ilcs vs. vlcs, etc. Long ago when systems were smaller/simpler/slower, the above factors hardly mattered. And our monitoring practices were founded on the simpler principles of that time. Today though, the above factors are essential to understanding performance yet no one seems to know nor care about the above factors...hence, The Gap. earlj Premise#2 If you can’t see the root symptoms of a performance/efficiency problem, … then there is no performance/efficiency problem – right? Wrong, we just have to look closer.

Rules of Expectation for the numbers of AIX:vmstat/mpstat/iostat
kthr:r = the runqueue of running+runnable threads; it is compared to the configured count of logical CPUs, i.e. lcpu=128, and must consider the max SMT-mode, i.e. AIX:smtctl -t 4 for SMT-4, and OLTP versus Batch workloads. Rules of Expectation:kthr:r – tune the count of virtual CPUs to: SMT-4 OLTP: keep kthr:r at 30-66% of your lcpu logical CPU count SMT-4 Batch: keep kthr:r at 55-80% of your lcpu logical CPU count SMT-2 OLTP: keep kthr:r at 55-74% of your lcpu logical CPU count SMT-2 Batch: keep kthr:r at 55-74% of your lcpu logical CPU count Critical when kthr:r is sustained at >100% of logical CPUs, i.e. overthreading

kthr:b = queue-count of blocked threads underway kthr:p = queue-count of raw IO threads underway kthr:w = queue-count of JFS/JFS2 IO threads underway Rules of Expectation:kthr:b|p|w When kthr:b|p|w sustained at –> Optimal; this is perfect When kthr:b|p|w sustained at –> Okay; grinding in the groove When kthr:b|p|w sustained at –> Warning: see AIX:iostat RofE’s below When kthr:b|p|w sustained at –> Critical: focus on AIX:iostat RofE’s

ilcs = stealing CPUcore w/workload; Tier -1:near-nil-->Tier 3:near-infinite vlcs = releasing CPUcore w/o workload; available unused CPU capacity eCPU = CPU Entitlement granted in the HMC LPAR profile, i.e. ent=46.0 vCPU = count of configured virtual CPUs (aka CPU Capacity) Incidentally ec% = ALL:pc divided by ent, i.e /46.0 Key Point: CPU Entitlement (eCPU) controls ilcs Rules of Expectation:ilcs Increase eCPU to reduce ilcs or re-implement Tier to/towards Tier -1 Decrease eCPU to increase ilcs or re-implement Tier to/towards Tier 3

CPU Threading Models for Performance, Efficiency or a Balance of Both
Process:Thread organization is fundamental to monitoring. All Power/AIX workloads are comprised of processes w/one-or-more threads; understanding this structure is essential. ps -klmo THREAD ; ps –elmo THREAD Volatility pertains to the general pattern of spike/burst/burn/elasticity of concurrently executing threads. Does the runqueue vary radically over several seconds (high volatility), or does the runqueue stay within a steady range between each second (low volatility)? vmstat –IWwt 1 Intensity regards individual processes and their density of on-CPU threads within 1sec ps –ef | sort –nk4 Granularity is about the scale-composition of concurrently executing processes, i.e. the size of processes in memory (RSS in Kb), the count of active threads in these processes, the creation rate and longevity of processes, the size-scale of data to/from processes, etc. uptime;ps guw and ps gvww

cs = total count of thread context switches ics = count of cs that are involuntary context switches vcs = count of cs that are voluntary context switches vcs = cs - ics Rules of Expectation:cs::ics ratio – tune the count of virtual CPUs to: SMT-4 OLTP: maintain ALL:cs::ics ratio at ~5:1 for performance SMT-4 Batch: maintain ALL:cs::ics ratio at ~3:1 for throughput efficiency SMT-2 OLTP: maintain ALL:cs::ics ratio at ~4:1 for performance SMT-2 Batch: maintain ALL:cs::ics ratio at ~4:1 for throughput efficiency CPU Threading Models (the theme of this session) are based on the AIX:mpstat perspective of threading. There is a Threading Model for OLTP performance. There is a Threading Model for Batch efficiency. There is a Threading Model for a Balance of Both.

cs = total count of thread context switches ics = count of cs that are involuntary context switches vcs = count of cs that are voluntary context switches vcs = cs - ics Rules of Expectation:cs::ics ratio – tune the count of virtual CPUs to: SMT-4 OLTP: maintain ALL:cs::ics ratio at ~5:1 for performance SMT-4 Batch: maintain ALL:cs::ics ratio at ~3:1 for throughput efficiency SMT-2 OLTP: maintain ALL:cs::ics ratio at ~4:1 for performance SMT-2 Batch: maintain ALL:cs::ics ratio at ~4:1 for throughput efficiency CPU Threading Models (the theme of this session) are based on the AIX:mpstat perspective of threading. There is a Threading Model for OLTP performance. There is a Threading Model for Batch efficiency. There is a Threading Model for a Balance of Both. For new/volatile/unknown workloads, starting here and monitoring is a good initial practice. And this is indeed how we all begin.

Assumed Scale of Design in Workload Processing, Memory Size and Data I/O
Assumed Scale of Design is my designation for something we already know: Your workload-systems are a mix of Small | Medium | Large | Huge Small-minded workloads on small-memories on small-servers is Our Origins – these don’t have performance issues, i.e. grant the proper CPU/gbRAM and they’re happy Medium:Large-minded workloads on E850-E880s comprise our Enterprise-class focus – these generally don’t have performance issues, though some have special needs Huge-minded workloads are the Dark Energy pushing the Expansion of the IT Cosmos – you know it already if you have one-of-these… These define the words SPECIAL NEEDS What assortment of the above Makes-up Your IT Universe?

Process(PID): Instructions|text|stack|heap|private data Shared Memory Default JFS2 file-cached IO CIO|ASM|rawIO direct to/from SAN Exploiting Shared Memory is substantially more efficient for sharing data between processes – when not also including the JFS2 file cache to share the same twice, i.e. implementing CIO/ASM/rawIO by-passes the JFS2 file cache.

Fact: Wilbur is a Dedicated CPU LPAR w/28 CPUcores SMT-4 and 264gbRAM on a Power8 E870. Fact: MrEd is an SPLPAR with 46.0eCPU for 64vCPU SMT-4 and 786gbRAM on a Power8 E880.

File I/O Monitoring Tactics, JFS2 I/O Options and Other File I/O Alternatives
Rule for File I/O: Do as little I/O as possible Rule for File I/O: Give it space Rule for File I/O: Watch the numbers Rule for File I/O: Know the options Rule for File I/O: Don’t eat too much Rule for File I/O: Exploit OEM storage products & features, i.e. Copy Services

mpstat:min = minor page faults; JFS2 cache “hits” mpstat:maj = major page faults; new data from storage Rules of Expectation:ALL:min-to-maj digit-count ratio: The digit-count ratio should be 3:1, 4:1, 5:1 or 5:2. Warning is a sustained digit-count ratio of 5:3. When 5:4 or worse, reduce the scope of accessed data. When maj>min, accessed data is too vast and ~all new. Analogy: If you have a Gallon of data and a Quart of memory, processing data is more feasible than when there is 100 Gallons of data and a Teaspoon of memory. The ratio of accessed data to LPAR gbRAM must be properly proportional. This is my Fourth Principle of Assumed Scale of Design, i.e. Don’t eat too much.

AIX:iostat –DlRT collects 10 sets of 60secs. read:avg serv = interval average read service in milliseconds Rules of Expectation:read:avg serv <=1.0ms --> Excellent; par for SSDs; best in class service 1-5ms > Expected as normal for OEM systems storage 11-19ms --> Warning: Poor I/O performance; investigate 20ms > ICU Critical: Something is wrong; call OEM 911

AIX:iostat -F 2 AIX:iostat -T 2

What to Know How to See It Then Do This

May 2017 Orlando, FL

Efficiency is Value. Productively using ~all of what you have is good
The productive capacity of Power8 is phenomenal; unfortunately this capacity is routinely wasted/unexploited. The productive capacity of Power9 may yet be wasted/unexploited too. Why? Our perspectives are not noting the greater capabilities of late technology. Wasted/unexploited CPU capacity does not compromise performance. There are no standards for identifying wasted/unexploited CPU capacity. Efficiency is Value – We must more thoroughly exploit the resources we have.

Efficiency is Value. Productively using ~all of what you have is good
ABSTRACT: “… with this great abundance of CPU processing performance and concurrent capacity, we must begin managing CPU resources from the other end This other end is the emerging paradigm of CPU Efficiency Tuning.” A CPUcore will only execute what it is tasked to do; it cannot execute what it is not tasked to do. So push and press the CPUcore to execute more, then back off if/as/when needed. This is the strategy of the other end that is the emerging paradigm of CPU Efficiency Tuning.

Efficiency is Keep&Hold and not “99 bottles of beer on the wall”
For identical workloads, configuring 2 virtual CPUs in each of 4 LPARs is more efficient than configuring 8 virtual CPUs in each of 4 LPARs 2 virtual CPUs will more often invoke dynamic SMT-2/4 mode virtual CPUs will more often invoke dynamic SMT-1 mode 2 virtual CPUs in SMT-2/4 mode can keep&hold CPUcores busier with work and thus less often cede its CPUcores back to the CPU pool 8 virtual CPUs in SMT-1 mode cannot keep&hold CPUcores busy with work and thus more often cede its CPUcores back to the CPU pool

Efficiency is a Full Pantry and not Visiting Vons everyday
2 virtual CPUs each for 4 LPARs focuses L2/L3/TLB content for its LPAR virtual CPUs each for 4 LPARs dilutes L2/L3/TLB content of all 4 LPARs Any L2/L3/TLB cache miss means accessing other-cache/main-memory/HPT When multiple threads of the same process are executing concurrently, threads of a process on the same CPUcore share L2/L3/TLB content When multiple threads of the same process are across more CPUcores, they cannot conveniently/efficiently/closely share L2/L3/TLB as often

Please see this as: 8 CPUcores on the same SRAD -- over a one second interval of time.

Two LPARs are sharing 8 CPUcores on the same SRAD -- over a one second interval of time.

Four LPARs are sharing 8 CPUcores on the same SRAD -- over a one second interval of time.

Next: This is 8 CPUcores on the same SRAD – shifting between dynamic ST/SMT-1 mode and dynamic SMT-2 mode over a one second interval of time.

8 CPUcores on the same SRAD – are shifting between dynamic ST/SMT-1 mode, dynamic SMT-2 mode and dynamic SMT-4 mode over a one second interval of time.

Four LPARs are sharing CPUcores on the same SRAD – while each is shifting between dynamic ST/SMT-1 mode, dynamic SMT-2 mode and dynamic SMT-4 mode over a one second interval of time.

But this must be told: Any CPUcore in dynamic ST/SMT-1 mode will execute its single thread with all of the fury of the CPUcore for the fastest execution of the thread. What?! But how? CPUcores in dynamic ST/SMT-1 mode will generally double the amount of PreFetch to their L2/L3 caches.

Sadly, this is what I often find across today’s PowerVerse… If you bought 8 software CPU licenses and shared them across 4 LPARs – I salute you (Good Job!!). But, if you bought 32 software CPU licenses, well… Can you see that these four LPARs only touched the capacity of ~4 CPUcores? This kind of waste is due to cede’ing.

And bluntly, this is the reality of today’s PowerVerse… Then again, no one comes to me with AIX performance issues when they are configured to waste this much CPU capacity. This kind of waste is due to folding.

Allow me to rejoice that everyone here is running like this
Allow me to rejoice that everyone here is running like this.  This is productively efficient. Every drop of CPU is used. But, can we go one better towards greater efficiency? Yes.

This illustrates what I mean by The Other End of CPU Efficiency Tuning.
If LPARs begin in a same-similar fashion, and later need more performance or capacity – just add it upon demonstrated demand, i.e.: A CPUcore will only execute what it is tasked to do; it cannot execute what it is not tasked to do. So push and press the CPUcore to execute more, then back off if/as/when needed.

This illustrates a reserve of CPU capacity to attend thread respon-siveness with waiting CPU capacity, i.e. there’s an AIX:wait process per logical CPU. Some AIX:wait process reservation is needed per runqueue volatility – but otherwise reserving too much is gravely wasteful/inefficient.

The Basis of AIX:vmstat:CPU idle%
Assuming the default value of AIX:schedo:vpm_throughput_mode=0, the AIX:vmstat -IWwt 1:cpu:id percentage represents the average dynamic SMT mode of all active virtual CPUs in a one-second interval. While a virtual CPU is being served by a CPUcore, the CPUcore can dynamically change its SMT mode between ST/SMT-1 through to the LPAR’s maximum SMT mode setting. I call this varying trait the dynamic SMT mode – not to be confused with an LPAR’s maximum SMT mode setting, i.e. AIX:smtctl -t 4 for max SMT-4. The dynamic SMT mode is what underlies the calculation of CPU idle%.

The Basis of AIX:vmstat:CPU idle%
2 LPARs with 4 virtual CPUs each are executing one thread per virtual CPU in SMT-1 across 8 CPUcores; assume Power8 max SMT-4 mode

Executing one thread:SMT-1 is 60%busy:40%idle
A virtual CPU executing one thread:SMT-1 reports as 60%busy and 40%idle in AIX:vmstat -IWwt 1

Executing 2 threads:SMT-2 is 71%busy:29%idle
A virtual CPU executing threads:SMT-2 reports as 71%busy and 29%idle in AIX:vmstat -IWwt 1

A virtual CPU executing 3 threads:SMT-4 reports as 98%busy and 2%idle in AIX:vmstat -IWwt 1 The 4th logical CPU per virtual CPU is executing its wait kernel process in readiness for any workload thread to come

A virtual CPU executing threads:SMT-4 reports as 100%busy and 0%idle in AIX:vmstat -IWwt 1

The Basis of AIX:vmstat:CPU idle% (continued)
While a virtual CPU is being served by a CPUcore, the CPUcore can dynamically change its SMT mode between ST/SMT-1 through to the LPAR’s maximum SMT mode setting. The dynamic SMT mode is what underlies the calculation of CPU idle%. The intent of CPU idle% is not to report CPU time that is idle. The intent of CPU idle% is to report idle CPU capacity – that can execute additional threads by dynamically changing to a higher SMT mode. This is perhaps a new and profound realization for many of you.

AIX:vmstat:cpu:id is not idle CPUcore time
A virtual CPU executing one thread:SMT-1 reports as 60%busy and 40%idle in AIX:vmstat -IWwt 1 All virtual CPUs here are mainly executing one thread in SMT-1 when the Idle% is reported as shown

AIX:vmstat:cpu:pc is the total of CPUcore time fragments
The cpu:pc value is the total of fragments of CPUcore time held by one-to-many CPUcores. By held, I mean that while concurrent fragments of CPUcore time are working or waiting, they're unavailable to serve any other virtual CPU (of this or any other LPAR)

The cpu:ec value is cpu:pc divided by the CPU entitlement
The cpu:ec value is the cpu:pc value divided by the CPU entitlement, i.e. ent=46.00 as shown here The workload executing within cpu:ec<=100.0 is optimal; the workload beyond cpu:ec>100.0 is subject to less consistent and more fragmented performance

Does cpu:id>30 and cpu:ec>100.0 make sense to you now?
How can we exhaust CPU entitlement (cpu:ec>100.0) and yet so much CPU is idle (cpu:id>30)? Answer: cpu:id is not reporting idle CPU time; rather, it is reporting the ability to execute additional threads by dynamically changing to a higher SMT mode

Executing 3 threads:SMT-4 and a wait kernel process?
A virtual CPU executing 3 threads:SMT-4 reports as 98%busy and 2%idle in AIX:vmstat -IWwt 1 The 4th logical CPU per virtual CPU is executing its wait kernel process in readiness for any workload thread to come

The Role of AIX:wait kernel processes
The AIX:wait kernel processes are likely unnoticed by most AIX administrators. Without doubt, all monitoring utilities have also ignored these processes As such, they have historically been ignored as unimportant. But what if you find the AIX:wait kernel processes account for percent of all CPU processing in your LPARs? Would they then be worthy of attention?

What are all of these AIX:wait kernel processes?
Each AIX:wait process is bound and dedicated to one and only one logical CPU upon boot. The AIX:ps guww output here shows substantial amounts of on-CPU time of multiple AIX:wait kernel processes and multiple db2sysc (DB2 database) processes under the TIME column (second from the far right). The TIME column reports the total on-CPU time of the process in minutes:seconds since the process’s STIME time stamp (third from the far right). STIME is the clock time or calendar date the process was created. All of the listed processes here were started on Dec 06. Compare the accumulated on-CPU minutes:seconds of the TIME column values for the wait and db2sysc processes.

What are all of these AIX:wait kernel processes?
Compare the accumulated on-CPU minutes:seconds of the TIME column values for the wait and db2sysc processes. Are you surprised by the total on-CPU time of all AIX:wait kernel processes shown here? If not, you should be. Each listed AIX:wait process has accum-ulated hundreds to more than a thousand minutes of on-CPU time since Dec 06 (only 11 days of UpTime). When comparing the AIX:wait and db2sysc on-CPU TIME (minutes:seconds), one cannot deny the profound amount of CPU executing the AIX:wait kernel processes. Prepare yourself for a shocking realization when checking your own LPARs for the same.

Have I established my point that AIX:wait kernel processes are worthy of attention? I hope so. The AIX:wait kernel processes do nothing but hold and wait that is, the dynamic SMT mode is merely holding a logical CPU in place while waiting for a workload thread to execute. Maintaining some measure of running AIX:wait processes ensures a workload thread has an available logical CPU for immediate attention (an aspect of thread responsiveness) This is a valid and vital function. Unfortunately, when CPUcores are wastefully executing too much/too many AIX:wait processes, no other virtual CPU (of this or any other LPAR) can use these same CPUcores for more productive processing.

Did you check your own LPARs for the same? Did you buy software CPU licenses to execute so much/so many AIX:wait processes? Ouch!! But do you see, from the amount of CPU that you've devoted to executing AIX:wait processes, that you could get by with fewer software licenses and likewise fewer virtual CPUs? Don’t start denying what the numbers are screaming; listen to what the numbers are telling you. This is my point: It's grossly inefficient to persistently run with too much AIX:wait time. Whether cumulatively or in real-time, this is inefficient. The trick is to configure enough AIX:wait processes to address thread responsiveness, and not too much/too many.

In other words, some measure of AIX:wait time is needed for thread responsiveness, but too much CPU can also be configured and wasted for the sake of too much unused thread responsiveness. Also: Because the AIX:wait processes accumulate (and thus account) the time that available logical CPUs have nothing to do, the on-CPU time of the AIX:wait processes is really also an account of idle CPU time. “Yeah, idle isn’t idle because wait is idle.”  Correcto Mundo !!

Power/AIX: The Emerging Paradigm of CPU Efficiency

Evolve the Wetware to the Capabilities of the Technology
The Power4 CPUcore is a comparative sliver of today’s Power8 CPUcore, and even more so of the Power9 CPUcore. With each Power release, the core is more than what it was, yet we still treat a core like a core because it is a core when it isn’t the same core. So the Wetware continues to ignore what cannot be denied… Do not continue Old Habits. Learn new appropriate habits.

Evolve the Wetware: Learn new appropriate habits
Learn the capabilities/capacities of the technology, and configure accordingly to derive greater performance/efficiency/value Learn to monitor the numbers of AIX. Then tune by-the-numbers of AIX, not by whim/wish/fancy/fear/Old Habits. Will you entertain the emerging paradigm of CPU Efficiency Tuning?

IBM Systems Lab Services
Proven expertise to help leaders design, build and deliver IT infrastructure expertise for the cognitive era Call on our team of consultants engaging worldwide for: Power Systems Storage and Software Defined Infrastructure IBM Z and LinuxONE Systems Consulting Migration Factory Technical Training and Events Company

a017115 Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning Decades ago at the beginning of IT on UNIX, there was a universally expected shortfall of CPU cycles for enterprise workload processing -- because back then, compared with today, there was one dumb slow CPU. Today we have a vastly different landscape. Today we are working with high-concurrency large-scale multi-threading multi-CPU shared-cache shared-memory architectures. Today's POWER systems are so powerful, they routinely deliver exceptional performance without tuning. This is good. But now with this great abundance of CPU processing performance and concurrent capacity, we must begin managing CPU resources from the other end. This other end is the emerging paradigm of CPU efficiency tuning. Come and hear a new perspective.

a017116 Power/AIX: Strategies and Tactics for All-Out/Everything-In CPU Processing Performance There are some enterprise workloads that must run as quickly as possible. No matter the waste, no matter the cost, these workloads must run fast, i.e. Black Friday on-line retail systems. I call these All-Out/Everything-In workloads because of their fastest-possible performance priority. This session outlines the Power/AIX strategies, LPAR implementations and AIX tactics for the All-Out/Everything-In workload. Come and hear what to do when waste and cost are secondary to All-Out workload performance.

a017117 Power/AIX: The Traits and Tactics of CPU Processing Efficiency Today's POWER systems routinely deliver exceptional performance without tuning. More often than not though, we are configuring more CPU capacity than is needed to achieve virtually the same performance. This is wasteful for the lack of AIX tactical techniques for confident decisions to adjust CPU entitlement, the count of virtual CPUs, etc. As well, there are other aspects of efficiency most are unaware; these will also be discussed. Come learn how to derive maximum productivity from your Power investment with tactics for reducing waste, increasing efficiency, focusing the content of CPU core cache, eliminating avoidable workload, etc. Come and learn how to be more CPU processing efficient.

a017118 Power/AIX: The Gap between Performance Tuning and Capacity Management Most of us collect data with nmon/lpar2rrd/etc. This data is great for capacity management, but many also use only this data to monitor performance. Long ago this worked well enough for both, but today using this same data alone is insufficient or misleading for understanding performance. In other words, several performance factors are not considered because data is either not collected or it is misunderstood. These other factors are essential to understanding performance -- yet no one seems to know nor care...hence, The Gap. Come and learn about the gap between performance tuning and capacity management.

a017119 Power/AIX: Rules of Expectation for the numbers of AIX:vmstat/mpstat/iostat The numbers of AIX:vmstat/mpstat/iostat are only meaningful when we know what they represent, and understand what values are normal/expected; otherwise these numbers are nonsensical. In other words, the AIX:vmstat/mpstat/iostat numbers are only meaningful with guidance. This session discusses what the AIX:vmstat/mpstat/iostat numbers mean, and offers formulaic rules of expectation for their values.

a017120 Power/AIX: CPU Threading Models for Performance, Efficiency or a Balance of Both There are CPU threading models for optimum performance (at the expense of efficiency). There are also CPU threading models for optimum efficiency (at the expense of performance). And of course, there are CPU threading models for a balance of both performance and efficiency. This session discusses how the different CPU threading models promote performance, efficiency, or a balance of both, and details how the traits and tactics of each model compels its priority emphasis.

a017127 Power/AIX: Assumed Scale of Design in Workload Processing, Memory Size and Data I/O IBM Power Systems technology is supporting a broader range of scale and granularity of data with each generation. This widening dimension opens a new consideration of alignment that I call Assumed Scale of Design. For instance, if your application/database/server/ storage infrastructure assumes an optimum scale of megabyte sized processes moving smaller IOPS of SAN-based GBs of data to/from slim gigabytes of memory, it cannot feasibly process larger IOPS of SAN-based TBs of data in a timely manner; this illustrates a mismatch of Assumed Scale of Design. This session explores this emerging concept with two real-world examples.

a017128 Power/AIX: File I/O Monitoring Tactics, JFS2 I/O Options and Other File I/O Alternatives This session demonstrates a system of file I/O monitoring tactics, reviews how to choose among JFS2 mount options, and discusses other file I/O alternatives to JFS2.

Notice and disclaimers
Copyright © 2017 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights — use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. This document is distributed “as is” without any warranty, either express or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. IBM products are manufactured from new parts or new and used parts. In some cases, a product may not be new and may have been previously installed. Regardless, our warranty terms apply.” Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.

Notice and disclaimers continued
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third- party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular, purpose. The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, AIX, BigInsights, Bluemix, CICS, Easy Tier, FlashCopy, FlashSystem, GDPS, GPFS, Guardium, HyperSwap, IBM Cloud Managed Services, IBM Elastic Storage, IBM FlashCore, IBM FlashSystem, IBM MobileFirst, IBM Power Systems, IBM PureSystems, IBM Spectrum, IBM Spectrum Accelerate, IBM Spectrum Archive, IBM Spectrum Control, IBM Spectrum Protect, IBM Spectrum Scale, IBM Spectrum Storage, IBM Spectrum Virtualize, IBM Watson, IBM z Systems, IBM z13, IMS, InfoSphere, Linear Tape File System, OMEGAMON, OpenPower, Parallel Sysplex, Power, POWER, POWER4, POWER7, POWER8, Power Series, Power Systems, Power Systems Software, PowerHA, PowerLinux, PowerVM, PureApplica- tion, RACF, Real-time Compression, Redbooks, RMF, SPSS, Storwize, Symphony, SystemMirror, System Storage, Tivoli, WebSphere, XIV, z Systems, z/OS, z/VM, z/VSE, zEnterprise and zSecure are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning

Similar presentations

Presentation on theme: "Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning

Similar presentations

Presentation on theme: "Power/AIX: The Emerging Paradigm of CPU Efficiency Tuning"— Presentation transcript:

Similar presentations

About project

Feedback