a017128 file io monitoring tactics jfs2 io options and ... · abstract file i/o monitoring tactics,...

0

IBM Systems Technical Events | ibm.com/training/events© Copyright IBM Corporation 2017. Technical University/Symposia materials may not be reproduced in whole or in part without the prior written permission of IBM.© Copyright IBM Corporation 2017. Technical University/Symposia materials may

not be reproduced in whole or in part without the prior written permission of IBM.

Power/AIX: File I/O Monitoring Tactics, JFS2 I/O Options and Other File I/O Alternatives

Earl Jew

IBM STG Lab Services

a017128

1



ABSTRACT

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.

Earl Jew ([email protected]) 310-251-2907 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

2



• 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.

2


3



• What to Know

• How to See It

• Then Do This

3


4



• 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

4


5



AIX:vmstat -IWwt 1

Fact: SSMinnow is an SPLPAR with 3.5eCPU for 6vCPU SMT-4 and 98gbRAM on a Power8 E850.

SSMinnow AIX:vmstat -IWw 1 Watch the numbers

kthr:b = queue-count of blocked threads underwaykthr:p = queue-count of raw IO threads underwaykthr:w = queue-count of JFS/JFS2 IO threads underway

Rules of Expectation:kthr:b|p|wWhen kthr:b|p|w sustains at 0-9 –> Optimal; this is perfectWhen kthr:b|p|w sustains at 10-50 –> Okay; grinding in the groove When kthr:b|p|w sustains at 51-99 –> Warning: start watching AIX:iostatWhen kthr:b|p|w sustains at 100+ –> Critical: IOPS are rejected&spinning

6



AIX:vmstat -IWwt 1

Fact: SSMinnow is an SPLPAR with 3.5eCPU for 6vCPU SMT-4 and 98gbRAM on a Power8 E850.

SSMinnow AIX:vmstat -IWw 1 Give it space

page:fi = count of default&rbr JFS/JFS2 4K page reads; no raw/CIO/mmfs/NFSpage:fo = count of default&rbw JFS/JFS2 4K page writes; no raw/CIO/mmfs/NFS

Rules of Expectation:page:fi+page:fopage:fi+page:fo at 0-2digits –> Virtually no fileIO; watching DVR

page:fi+page:fo at 3digits –> Gentle pace fileIO; roaming the house

page:fi+page:fo at 4digits –> Normal pace fileIO; walking the dog

page:fi+page:fo at 5digits –> Harsh pace fileIO; racing in marathon

page:fi+page:fo at 6digits –> Extreme pace of fileIO; Olympic sprinting

page:fi+page:fo at 7digits –> Impossible; it’s fake news, or a hoax

Give it space: memory:fre should be greater than page:fi+page:fo by 1-2 digits

7



SSMinnow AIX:vmstat -IWw 1 Know the options

page:fr = free rate of AIX:lrud adding to memory:fre

page:sr = scan rate of AIX:lrud scanning for page:frEvaluate the digit-count of only page:sr

SCALED versionRules of Expectation:page:sr1) Sustained fr:sr of persistently 0:0 –>

Late&Lucky, nil AIX:lrud, little use of memory:fre

2) Bursting page:sr at/between 3, 4 and 5 digits –>Normal AIX:lrud sr of JFS2 file-cache content

3) Sustained page:sr at 5 digits –>Overwhelming AIX:lrud activity, heavy memory:fre useDataIO restructuring is warranted/indicated

Exploit the use of JFS2 mount options4) Bursting/Sustained page:sr at 6/+ digits –>

Critical: Something is fundamentally wrong!!Critical: DataIO restructuring is required

8



SSMinnow AIX:mpstat -w 1 Don’t eat too much

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.

9



SSMinnow AIX:mpstat -w (cumulative stats over DaysUptime)

10



SSMinnow AIX:mpstat -w (cumulative stats over DaysUptime)

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.

If 5:4 or worse, reduce the scope of accessed data.When maj>min, accessed data is too vast and ~all new.

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.

Compare real-time AIX:mpstat -w 1 and the cumulative stats over DaysUptime AIX:mpstat -w shown here for a broader comparison of accessed data to LPAR gbRAM.

11



SSMinnow AIX:iostat –DlRT 60 10

12



SSMinnow AIX:iostat –DlRT 60 10 <zoom in left>

13



SSMinnow AIX:iostat –DlRT 60 10 Watch the numbers

AIX:iostat –DlRT 60 10 collects 10 sets of 60sec intervals. The data shown

here is a single 60sec interval. These standards assume OEM Enterprise-class SAN systems storage on a SAN fabric, and not internal SAS 2.0 disks.

%tm act = percent time active over the interval, i.e. 60secs

Rules of Expectation:%tm act<30% of a 60sec interval --> Perfect range of busy%30-50% of a 60sec interval --> Sweating when sustained51-70% of a 60sec interval --> Warning: Arrange lessening of intensity

70-90% of a 60sec interval --> Trauma: Hotspot restructuring; call OEM 91190%+ of a 60sec interval --> ICU Critical: Restructure DataIO; call OEM 911

For confidence: Don’t use RofE:%tm act alone; use it w/all other RofE:iostat below

14




AIX:iostat –DlRT 60 10 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 service1-5ms --> Expected as normal for OEM systems storage11-19ms --> Warning: Poor I/O performance; investigate20ms+ --> ICU Critical: Something is wrong; call OEM 911

15




AIX:iostat –DlRT 60 10 collects 10 sets of 60secs.

read:max serv = interval max read service in msecs->Secs

Rules of Expectation:read:max serv<=40ms --> Accepted as normal for OEM systems storage100-900ms --> Warning: Poor I/O performance; investigate1.0Sec+ --> Critical: Something is wrong; call OEM 911

16




AIX:iostat –DlRT 60 10 collects 10 sets of

60sec intervals.

queue:serv_qfull = count of hdisk queue_depthexhaustion per interval

Rules of Expectation:queue:serv_qfull1 digit (x.y) --> Acceptable tolerance2 digits (xx.y) --> Investigate/resolve3 digits (xxx.y) --> Critical; call OEM 911

17



Rule for File I/O: Exploit OEM storage products & features

• Learn&Exploit OEM storage products and features, i.e. EasyTier, FlashCopy, gpfs, SVC

• OEM storage services are routinely overlooked for lack of awareness and coordination

• SAN Copy Services are substantially more efficient/effective versus AIX file copy operations

• Map all DataIO paths from RAIDset->SANfabric->HBA->LVM:vg:lv->JFS2fs:data groups

• Request more&smaller SAN volumes to discretely map each 1:1 per LVM:vg:lv:JFS2fs

• Using the 1:1 map, monitor iostat -FT 2 and iostat -T 2 to discern JFS2fs access patterns

• Distribute JFS2fs:data groups across DataIO paths; work with SANadmins to study&re-map

• Upside-down LPARs, i.e. Wilbur, (See a017127:Assumed Scale of Design) must consider

adopting IBM Spectrum Scale (formerly gpfs) to negate Data:re-read performance issues

18



MrHowell AIX:iostat –F 2 40 Watch the numbers

Shown here, AIX:iostat -F 2 40 reports both JFS2-cache hits and “hard” SAN IO accesses per LVM:lv.

Next below, AIX:iostat -DRTl 60

reports only “hard” SAN IO accesses per hdisk.

The difference between both reports provides a definitive map of the JFS2-cache “hit” efficiencies.

AIX:iostat –F 2 40

Fact: MrHowell is a very large SPLPAR with 81.0eCPU for 128vCPU SMT-4 and 7864gbRAM on a Power8 E880.

19



MrHowell AIX:iostat –DRTl 60 Watch the numbers

AIX:iostat –F 2 40

Fact: MrHowell is a very large SPLPAR with 81.0eCPU for 128vCPU SMT-4 and 7864gbRAM on a Power8 E880.

On the slide above, AIX:iostat -F 2 40 reports both JFS2-cache hits and “hard” SAN IO accesses per LVM:lv.

Shown here, AIX:iostat -DRTl 60 reports only “hard” SAN IO accesses per hdisk.

The difference between both reports provides a definitive map of the JFS2-cache “hit” efficiencies.

20



MrHowell AIX:iostat Watch the numbers

21



Sample AIX:iostat –FT 2 Watch the numbers

22



Sample AIX:iostat –T 2 Watch the numbers

23



Sample AIX:iostat Watch the numbers

AIX:iostat -F 2

AIX:iostat -T 2

24



• 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

24


25



• What to Know

• How to See It

• Then Do This

25


26



• 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?

26

Assumed Scale of Design -- Small | Medium | Large | Huge

27



• What assortment of the above Makes-up Your IT Universe? If only it was this easy…

• Can Small-minded workloads run in large-memories on large-servers?

Yes, these are Upside-down LPARs, i.e. Wilbur, (See a017127:Assumed Scale of Design)

• Can a Medium-to-Large-minded workload squeeze into a small-server?

Yes -- but I would be obliged to discuss Matters of Scale with the customer.

• Can a Huge-minded workload run on a small-server?

Miserably w/fragments trading in&out over an eon (thus it is not practical) -- but yes.

• Anything can “run” on anything. The difference is our effort, complexity of implementation

and manageability, responsiveness and throughput, risk/reliability, other internal “frictions”

27


28



• Anything can “run” on anything. The difference is our effort, complexity of implementation

and manageability, responsiveness and throughput, risk/reliability, other internal “frictions”

• Assumed Scale of Design is my designation for something we already know…

But what’s this noise about Sm|Med|Lrg|Huge-mindedness? Politicians and Scientists?

• Sm|Med|Lrg|Huge-mindedness is about accessed data scale|granularity|concurrency

• multi-gb accessed data in 4kb granularity with minor concurrent-need – Small-minded

~5tb accessed data in 64kb granularity with more concurrent-need – Medium-minded

multi-tb accessed data in 16mb granularity with assumed concurrent-need – Large-minded

multi-pb accessed data in 16gb granularity with massive concurrent-need – Huge-minded

You must be thinking: “I’ve never seen ANYTHING like this before. Is this earlj character making this stuff up?”Answer: Almost.

28


29



• multi-gb accessed data maps to an Entry/Dept class of SAN storage

~5tb accessed data maps to a MidRange class of SAN storage

multi-tb accessed data maps to an Enterprise class of SAN storage

multi-pb accessed data maps to an HPC class of clustered storage technologies

• accessed data in 4kb|64kb|16mb|16gb granularity maps to AIX MPSS, i.e.

(Multiple Page Size Support): 4kb | 64kb |16mb |16gb memory page sizes

• The scale of concurrent-need maps to the total size of data in processes/shared memory

• Small | Medium | Large | Huge-mindedness is about

accessed data and its relative traits of scale | granularity | concurrency

29


30



30

Rule for File I/O: Do as little I/O as possible

31



Process(PID): Non-contiguous memory pages (RSS in kb units)

31

AIX:ps guww

Fact: Wilbur is a Dedicated CPU LPAR w/28 CPUcoresSMT-4 and 264gbRAM on a Power8 E870.


32



Process(PID): Non-contiguous memory pages (RSS in kb units)

Process(PID): Instructions|text|stack|heap|private data

Thread0(TID)

Thread1(TID)

Thread2(TID)

ThreadN(TID)

32

All Processes are

comprised of at least

one thread identified

with a TID. Some

processes may have

thousands of threads.

Threads by TID are

scheduled for execution

on the logical CPUs of

virtual CPUs while

served by a CPUcore,

i.e. TID:cpu:vCPU:Core.


33



33

AIX:ps –elmo THREAD

Fact: Wilbur is a Dedicated CPU LPAR w/28 CPUcoresSMT-4 and 264gbRAM on a Power8 E870.


34




Thread0(TID)

Thread1(TID)

Thread2(TID)

ThreadN(TID)

34


Process:threads only process data in its private memory. Data:reads are page-ins that originate here; Data:writes are

page-outs that are staged here. As such, the most intimate place

for data is in the private memory of Process:threads – and not in

the AIX:JFS2 file cache.

All threads of a given

process share the same

private process data;

this private process

data region is the

ultimate endpoint of all

DataIO to/from SAN

storage

35




Thread0(TID)

Thread1(TID)

Thread2(TID)

ThreadN(TID)

35

Larger Processes in memory hold more private data; holding more private data

reduces Data:re-reads. Small-memory processes can repeatedly flush&re-read

the same data in&out of private memory; this is an issue that no one notices…

The above illustrates my First Principle of Assumed Scale of Design.


36







36

Shared Memory houses application/RDBMS data to be shared among multiple

processes, i.e. the Oracle SGA and DB2 memory pools. As such, Shared Memory

is the de facto Primary Data Cache of the application/RDBMS – or should be…

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/etc by-passes the JFS2 file cache.

Shared Memory


37







37

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.

Shared Memory

Default JFS2 file-cached IO CIO|ASM|rawIO direct to/from SAN


38



38

AIX:ipcs -bm

Fact: MrEd is an SPLPAR with 46.0eCPU for 64vCPU SMT-4 and 786gbRAM on a Power8 E880.


39



39

Rule for File I/O: Know the Options – Concurrent IO

• JFS2:cio (aka ConcurrentIO or CIO) is an IO method that bypasses the traditional use of free memory, the AIX:JFS2 file-cache and file:inodes for locking, i.e. a far shorter path

• CIO concurrently reads-from and writes-to the same file at the same time, thus the term

concurrent in CIO; it does not concurrently read/write nor write/read exactly the same data

• CIO moves file-data directly to/from the private memory/shared memory of processes; as

such, the counterpart of AIX free memory to receive-reads/stage-writes is managed within

the application/rdbms memory

• The application/rdbms must create free memory within its memory footprint.

• CIO is common and popular today for Late&Lucky workloads using Shared Memory

and/or larger processes.

40



40

• CIO is superb for fast direct efficiency of random read/write’s to few larger files

• All CIO is random, direct and atomic – even when accessed sequentially

• CIO does not use AIX free memory nor the JFS2 file-cache. As such, it cannot read-ahead

nor write-behind to coalesce sequential IOs -- as done by the JFS2/default mount

• CIO is also relatively inefficient for Sequential IOs; SAN systems storage must not enable

internal ReadAhead/WriteBehind sequential IO acceleration algorithms/mechanisms

• For best performance, CIO workloads favor Flash/SSD SAN storage technologies

Rule for File I/O: Know the Options – Concurrent IO

41



41

By their nature, Upside-Down LPARs cannot use CIO

42



42

AIX:mount -o options Specifies options. Options entered on the command line should be separated only by a comma. The following file system-specific options do not apply to all virtual file system types:

…

rbr Mount file system with the release-behind-when-reading capability. When sequential reading of a file in this file system is detected, the real memory pages used by the file will be released once the pages are copied to internal buffers. If none of the release-behind options are specified, norbrw is the default. Note: When rbr is specified, the D_RB_READ flag is ultimately set in the _devflags field in the pdtentry structure.

rbw Mount file system with the release-behind-when-writing capability. When sequential writing of a file in this file system is detected, the real memory pages used by the file will be released once the pages written to disk. If none of the release-behind options are specified, norbrw is the default. Note: When rbw is specified, the D_RB_WRITE flag is set.

rbrw Mount file system with both release-behind-when-reading and release-behind-when-writing capabilities. If none of the release-behind options are specified, norbrw is the default. Note: If rbrw is specified, both the D_RB_READ and the D_RB_WRITE flags are set.

Source: https://www.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.cmds3/mount.htm

Rule for File I/O: Know the Options – rbr | rbw | rbrw

43



43

…

rbrw Mount file system with both release-behind-when-reading and release-behind-when-writing capabilities. If none of the release-behind options are specified, norbrw is the default. Note: If rbrw is specified, both the D_RB_READ and

the D_RB_WRITE flags are set.

• Upside-down LPARs (not unlike Wilbur) should co-reside one-time read/one-time write

data files under JFS2 AIX:mount -o rbrw filesystems – because file-caching its data offers

no benefit and uselessly adds AIX:lrud overhead

• By study/discussion, regroup one-time read/one-time write data files separately per above

• Use the above Watch the numbers tactics to confirm one-time read/one-time write data

file group selection

• AIX:mount -o rbrw filesystems have no AIX:lrud overhead

Rule for File I/O: Know the Options – rbrw (first search)

44



44

…

rbw Mount file system with the release-behind-when-writing capability. When sequential writing of a file in this file system is detected, the real memory pages used by the file will be released once the pages written to disk. If none of the release-behind options are specified, norbrw is the default. Note: When rbw is specified, the D_RB_WRITE flag is set.

• Upside-down LPARs (not unlike Wilbur) should co-reside one-time write data files under

JFS2 AIX:mount -o rbw filesystems – because file-caching its data offers no benefit and

uselessly adds AIX:lrud overhead

• By study/discussion, regroup one-time write data files separately per above

• Use the above Watch the numbers tactics to confirm one-time write data file group

selection

• AIX:mount -o rbw filesystems have no AIX:lrud overhead for one-time write data

Rule for File I/O: Know the Options – rbw (second search)

45



45

…

rbr Mount file system with the release-behind-when-reading capability. When sequential reading of a file in this file system is detected, the real memory pages used by the file will be released once the pages are copied to internal buffers. If none of the release-behind options are specified, norbrw is the default. Note: When rbr is specified, the D_RB_READ flag is ultimately set in the _devflags field in the pdtentry structure.

• Upside-down LPARs (not unlike Wilbur) should co-reside one-time read data files under

JFS2 AIX:mount -o rbr filesystems – because file-caching its data offers no benefit and

uselessly adds AIX:lrud overhead

• By study/discussion, regroup one-time read data files separately per above

• Use the above Watch the numbers tactics to confirm one-time read data file group

selection

• AIX:mount -o rbr filesystems have no AIX:lrud overhead for one-time read data

Rule for File I/O: Know the Options – rbr (third search)

46



46

AIX:mount -o default

• Upside-down LPARs (not unlike Wilbur) should co-reside re-read/re-write data files under

JFS2 AIX:mount -o default filesystems – because file-caching its data is beneficial despite

the associated AIX:lrud overhead

• By study/discussion, regroup re-read/re-write data files separately per above

• Use the above Watch the numbers tactics to confirm re-read/re-write data file group

selection

• AIX:mount -o default filesystems have AIX:lrud overhead for all data I/O

Rule for File I/O: Know the Options – default (all else not above)

47



• What to Know

• How to See It

• Then Do This

47


48



• 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

• multi-gb accessed data maps to an Entry/Dept class of SAN storage

• accessed data in 4kb granularity maps to AIX MPSS 4kb memory page sizes

• Application/rdbms admins allocate Shared Memory on 4kb memory page sizes


• These are long-lived, well-known and multi-generational workloads that are rock-solid.

Treat them per tradition; these are otherwise too small to cause performance problems…


Yes, these are Upside-down LPARs, i.e. Wilbur and MrHowell (See a017127:Assumed)

48

Assumed Scale of Design -- Small

49




Yes, these are Upside-down LPARs, i.e. Wilbur, (See a017127:Assumed Scale of Design)

• multi-tb accessed data maps to an Enterprise class of SAN storage


• The scale of concurrent-need of data is limited by small-processes that generally do not

use Shared Memory, and thus compensate with a disproportionally large JFS2 file-cache,

i.e. the LPAR is Upside-Down, cannot use JFS2-CIO and suffers Data:re-reads

• Exploit the JFS2 mount options: rbr|rbw|rbrw|default per above

• Otherwise Upside-down LPARs must consider adopting IBM Spectrum Scale (formerly gpfs)

to negate Data:re-read issues and to preclude overwhelming AIX:lrud overhead

49

Assumed Scale of Design – Small-minded on large servers

50



• Medium-minded workloads on E850-E880s comprise our Enterprise-class focus

– these generally don’t have performance issues, though some have special needs

• ~5tb accessed data maps to a MidRange class of SAN storage


• Application/rdbms admins allocate Shared Memory on 64kb memory page sizes

• The scale of concurrent-need maps to the total size of data in large processes that are

extended with shared memory

• By definition, Medium-minded workloads are Rightside-Up and virtually always exploit

CIO|ASM|mmfs (aka gpfs)|rawIO

50

Assumed Scale of Design -- Medium

51



• Large-minded workloads on E850-E880s comprise our Enterprise-class focus

– these generally don’t have performance issues, though some have special needs

• multi-tb accessed data maps to an Enterprise class of SAN storage

• accessed data in 16mb granularity maps to AIX MPSS 16mb memory page sizes

• Application/rdbms admins allocate Shared Memory on 16mb memory page sizes

• The scale of concurrent-need maps to the total size of data in large processes that are

extended with shared memory

• By definition, Large-minded workloads are Rightside-Up and virtually always exploit

CIO|ASM|mmfs (aka gpfs)|rawIO

51

Assumed Scale of Design -- Large

52



• 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

• multi-pb accessed data maps to an HPC class of clustered storage technologies

• accessed data in 16gb granularity maps to AIX MPSS 16gb memory page sizes

• Application/rdbms admins allocate Shared Memory on 16gb memory page sizes


and will adopt emerging technologies, i.e. CAPI 2.0, NVLink, FPGAs, GPUs, POWERx, etc.

• The special needs of Huge-minded workloads inspire my Fifth Principle of Assumed Scale of

Design -- that acknowledges the emerging technologies that will again shift computing

beyond-the-horizon, i.e. CAPI 2.0, NVLink, FPGAs, GPUs, POWERx, etc.

52

Assumed Scale of Design -- Huge

53



It’s been too much fun. Thank You.

Please return home safely to yours.

And Best Wishes until we meet again.

53


54



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 1100+ consultants engaging worldwide for:

� Power Systems

� Storage and Software Defined Infrastructure

� IBM Z and LinuxONE

� Systems Consulting

� Migration Factory

� Technical Training and Events

Company

[email protected]

www.ibm.com/it-infrastructure/services/lab-services

55



a017115

Power/AIX: The Emerging Paradigm for 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.

55

56



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.

56

57



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.

57

58



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.

58

59



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.

59

60



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.

60

61



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.

61

62



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.

62

63



63

• 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

64



64

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: www.ibm.com/legal/copytrade.shtml.

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.

a017128 file io monitoring tactics jfs2 io options and ... · abstract file i/o monitoring tactics,...

Documents