Technical Education October 2011 IBM Systems Group

Disk IO Tuning in AIX 6.1

Author: Dan Braden [email protected] Presenter: Steve Nasypany IBM Advanced Technical Skills http://w3.ibm.com/support/americas/pseries

© 2010 IBM Corporation © 2010 IBM Corporation Agenda

 The importance of IO tuning  Disk basics and performance overview  AIX IO stack  Data layout  Characterizing application IO  Disk performance monitoring tools  Testing disk subsystem performance  Tuning

2  2011 IBM Corporation Why is disk IO tuning important?  Moore's law  Processors double in price performance every 18 months  Disk growth  Disk densities are doubling every 12 months  Customers are doubling storage capacities every 12-18 months  Actuator and rotational speed increasing relatively slowly  Network bandwidth - doubling every 6 months Approximate CPU cycle time 0.0000000005 seconds Approximate memory access time 0.000000270 seconds Approximate disk access time 0.010000000 seconds

 Memory access takes 540 CPU cycles  Disk access takes 20 million CPU cycles, or 37,037 memory accesses

 System bottlenecks are being pushed to the disk  Disk subsystems are using cache to improve IO service times  Customers now spend more on storage than on servers 3  2011 IBM Corporation Why is disk IO tuning important?

Seagate 15k RPM/3.5" Drive Specifications

+35% 450

Capacity (GB)

Max Sustained 180 DR (MB/s) +15% Read Seek (ms) 73 75

3.6 -1% 3.4 2002 2010

 Disk IO service time not improving compared to processors

4  2011 IBM Corporation Performance metrics

 Disk metrics  MB/s  IOPS  With a reasonable service time  Application metrics  Response time  Batch job run time  System metrics  CPU, memory and IO  Size for your peak workloads  Size based on maximum sustainable thruputs  Bandwidth and thruput sometimes mean the same thing, sometimes not  For tuning - it's good to have a short running job that's representative of your workload

5  2011 IBM Corporation Performance metrics

 Use a relevant metric for testing  Should be tied to business costs, benefits or requirements  Batch job run time  Maximum or sufficient application transactions/second  Query run time  Metrics that typically are not so relevant  Application transaction time if < a few seconds  Metrics indicating bottlenecks  CPU, memory, network, disk  Important if the application metric goal isn’t met  Be aware of IO from other systems affecting disk performance to shared disk  If benchmarking two systems, be sure the disk performance is apples to apples and you’re not really comparing disk subsystem performance

6  2011 IBM Corporation Disk performance “ZBR” Geometry

 Interface type  ATA  SATA  SCSI

 IO service times are predominately  FC seek + rotational latency + queueing time  SAS 7  2011 IBM Corporation Disk performance

 When do you have a disk bottleneck?  Random workloads  Reads average > 15 ms  With write cache, writes average > 2.5 ms  Sequential workloads  Two sequential IO streams on one disk  You need more thruput

IOPS vs IO service time - 15,000 RPM disk

500

400

300 200

100

IO serviceIO time (ms) 0 25 50 75 100 125 150 175 200 225 250 275 300 325 IOPS 8  2011 IBM Corporation How to improve disk performance  Reduce the number of IOs  Bigger caches  Application, file system, disk subsystem  Use caches more efficiently  No file system logging  No access time updates  Improve average IO service times  Better data layout  Reduce locking for IOs  Buffer/queue tuning  Use SSDs or RAM disk  Faster disks/interfaces, more disks  Short stroke the disks and use the outer edge  Smooth the IOs out over time  Reduce the overhead to handle IOs

9  2011 IBM Corporation What is %iowait?

 A misleading indicator of disk performance  A type of CPU idle  Percent of time the CPU is idle and waiting on an IO so it can do some more work  High %iowait does not necessarily indicate a disk bottleneck  Your application could be IO intensive, e.g. a backup  You can make %iowait go to 0 by adding CPU intensive jobs  Low %iowait does not necessarily mean you don't have a disk bottleneck  The CPUs can be busy while IOs are taking unreasonably long times  If disk IO service times are good, you aren’t getting the performance you need, and you have significant %iowait – consider using SSDs or RAM disk  Improve performance by potentially reducing %iowait to 0

10  2011 IBM Corporation Solid State Disk (SSD)

 High performance electronic disk  From 14,000 – 27,000 IOPS possible for a single SSD  SSD IO bandwidth varies across Power and disk subsystems  Typically small (69-177 GB) and expensive compared to HDDs  Read or write IOs typically < 1 ms  About the same IO service time as compared to writes to disk subsystem cache  About 5-15X faster than reads from disk  Positioned for high access density (IOPS/GB) random read data  Implementation involves finding the best data to place on the SSDs  SSDs can save disk costs by reducing the number of spindles needed  When high access density data exists  A mix of SSDs and HDDs is often best

11  2011 IBM Corporation SSD vs. HDD performance

SSD offers up to 33x – 125x more IOPS HDD IO service time typically 5X to 40X slower* 125X

40X

33X 5X 1X 1X HDD SSD HDD SSD

Access time is drive-to-drive, ignoring any caching by SAS controller 12  2011 IBM Corporation RAM disk

 Use system RAM to create a virtual disk  Data is lost in the event of a reboot or system crash  IOs complete with RAM latencies  For file systems, it takes away from file system cache  Taking from one pocket and putting it into another  A raw disk or file system only – no LVM support

# mkramdisk 16M /dev/rramdisk0 # mkfs -V jfs2 /dev/ramdisk0 mkfs: destroy /dev/ramdisk0 (yes)? y File system created successfully. 16176 kilobytes total disk space. Device /dev/ramdisk0: Standard empty filesystem Size: 32352 512-byte (DEVBLKSIZE) blocks # mkdir /ramdiskfs # mount -V jfs2 -o log=NULL /dev/ramdisk0 /ramdiskfs # df -m /ramdiskfs Filesystem MB blocks Free %Used Iused %Iused Mounted on /dev/ramdisk0 16.00 15.67 3% 4 1% /ramdiskfs

13  2011 IBM Corporation The AIX IO stack

Application Application memory area caches data to avoid IO Logical file system Rawdisks RawLVs NFS caches file attributes JFS JFS2 NFS Other NFS has a cached filesystem for NFS clients

JFS and JFS2 cache use extra system RAM VMM JFS uses persistent pages for cache JFS2 uses client pages for cache LVM (LVM device drivers) Multi-path IO driver (optional) Disk Device Drivers Queues exist for both adapters and disks Adapter Device Drivers Adapter device drivers use DMA for IO Disk subsystem (optional) Disk subsystems have read and write cache Disk Disks have memory to store commands/data Write cache Read cache or memory area used for IO IOs can be coalesced (good) or split up (bad) as they go thru the IO stack IOs adjacent in a file/LV/disk can be coalesced IOs greater than the maximum IO size supported will be split up 14  2011 IBM Corporation Synchronous vs Asynchronous IOs

 Definition depends on the frame of reference  Programmers/application  When an application issues a synchronous IO, it waits until the IO is complete  Asynchronous IOs are handed off to the kernel, and the application continues, and uses the AIO facilities in AIX  When a group of asynchronous IOs complete, a signal is sent to the application  Allows IO and processing to run simultaneously  Filesystem IO  Synchronous write IOs to a file system must get to disk  Asynchronous IOs only need to get to file system cache  GLVM or disk subsystem mirroring  Synchronous mirroring requires that writes to both mirrors complete before returing an acknowledgement to the application  Asynchronous mirroring returns an acknowledgement when the write completes at the local storage  Writes to remote storage are done in the same order as locally 15  2011 IBM Corporation Data layout  Data layout affects IO performance more than any tunable IO parameter  Good data layout avoids dealing with disk hot spots  An ongoing management issue and cost  Data layout must be planned in advance  Changes are often painful  and filemon can show unbalanced IO  Best practice: evenly balance IOs across all physical disks

Random IO best practice:  Spread IOs evenly across all physical disks  For disk subsystems  Create RAID arrays of equal size and RAID level  Create VGs with one LUN from every array  Spread all LVs across all PVs in the VG  The SVC can, and XIV does do this automatically

16  2011 IBM Corporation Random IO data layout

Disk subsystem 1

2 1 2 3 4 5

3 datavg 4 # mklv lv1 –e x hdisk1 hdisk2 … hdisk5 5 # mklv lv2 –e x hdisk3 hdisk1 …. hdisk4 ….. Use a random order for the hdisks for each LV RAID array

LUN or logical disk

PV

17  2011 IBM Corporation Data layout for sequential IO  Many factors affect sequential thruput  RAID setup, number of threads, IO size, reads vs. writes  Create RAID arrays with data stripes a power of 2  RAID 5 arrays of 5 or 9 disks  RAID 10 arrays of 2, 4, 8, or 16 disks  Do application IOs equal to, or a multiple of, a full stripe on the RAID array  Or use multiple threads to submit many IOs  N disk RAID 5 arrays can handle no more than N-1 sequential IO streams before the IO becomes randomized  N disk RAID 10 arrays can do N sequential read IO streams and N/2 sequential write IO streams before the IO becomes randomized  Sometimes smaller strip sizes (around 64 KB) perform better  Test your setup if the bandwidth needed is high

18  2011 IBM Corporation Data layout Best practice for VGs and LVs

 Use Big or Scalable VGs  Both support no LVCB header on LVs (only important for raw LVs)  These can lead to issues with IOs split across physical disks  Big VGs require using mklv –T O option to eliminate LVCB  Scalable VGs have no LVCB  Only Scalable VGs support mirror pools (AIX 6100-02)

 For JFS2, use inline logs  For JFS, one log per file system provides the best performance

 If using LVM mirroring, use active MWC  Passive MWC creates more IOs than active MWC

 Use RAID in preference to LVM mirroring  Reduces IOs as there’s no additional writes for MWC

 Use PP striping in preference to LV striping 19  2011 IBM Corporation LVM limits

Standard Big VG Scalable VG VG Max PVs/VG 32 128 1024 Max LVs/VG 256 512 4096 Max PPs/VG 32,512 130,048 2,097,152 Max LPs/LV 32,512 130,048 2,097,152

Max PPs per VG and max LPs per LV restrict your PP size  Use a PP size that allows for growth of the VG  Use a PP size that allows your LVs to be spread across all PVs  Unless your disk subsystem ensures your LVs are spread across all physical disks Valid LV strip sizes range from 4 KB to 128 MB in powers of 2 for striped LVs

20  2011 IBM Corporation LUN size and how many?

Does LUN size matter? It depends.  Fewer larger LUNs are easier to manage  We can do many IOs in parallel to a LUN – depends on its queue_depth  Typically limited by:  Backend physical disks  Other disk subsystem bottlenecks  Theoretical bandwidth is:  Queue_depth/average IO service time IOPS  # physical disks x physical disk IOPS taking into account use of RAID  Assumes no other disk subsystem bottlenecks More LUNs mean more hdisk driver threads Very high IOPS rates will require more LUNs

21  2011 IBM Corporation Application IO characteristics  Random IO  Typically small (4-32 KB)  Measure and size with IOPS  Usually disk actuator limited

 Sequential IO  Typically large (32KB and up)  Measure and size with MB/s  Usually limited on the interconnect to the disk actuators

 To determine application IO characteristics  Use filemon

# filemon –o /tmp/filemon.out –O lf,lv,pv, detailed –T 500000; sleep 90; trcstop

 Check for trace buffer wraparounds which may invalidate the data, run filemon with a larger –T value or shorter sleep

22  2011 IBM Corporation filemon summary reports  Summary reports at PV and LV layers

Most Active Logical Volumes ------util #rblk #wblk KB/s volume description ------1.00 10551264 5600 17600.8 /dev/rms09_lv /RMS/bormspr0/oradata07 1.00 6226928 7584 10394.4 /dev/rms06_lv /RMS/bormspr0/oradata04 1.00 128544 3315168 5741.5 /dev/rms04_lv /RMS/bormspr0/oracletemp 1.00 13684704 38208 22879.4 /dev/rms02_lv /RMS/bormspr0/oradata01 0.99 11798800 16480 19698.9 /dev/rms03_lv /RMS/bormspr0/oradata02 0.99 600736 7760 1014.5 /dev/rms13_lv /RMS/bormspr0/oradata11 0.98 6237648 128 10399.9 /dev/oraloblv01 /RMS/bormspr0/oralob01 0.96 0 3120 5.2 /dev/hd8 jfslog 0.55 38056 104448 237.6 /dev/rms041_lv /RMS/bormspr0/oraredo 0.48 2344656 3328 3914.6 /dev/rms11_lv /RMS/bormspr0/oradata09

Most Active Physical Volumes ------util #rblk #wblk KB/s volume description ------1.00 3313059 4520 5531.2 /dev/hdisk66 SAN Volume Controller Device 1.00 7563668 22312 12647.6 /dev/hdisk59 SAN Volume Controller Device 1.00 53691 1868096 3204.1 /dev/hdisk61 SAN Volume Controller Device 1.00 11669 6478 30.3 /dev/hdisk0 N/A 1.00 6247484 4256 10423.1 /dev/hdisk77 SAN Volume Controller Device 1.00 6401393 10016 10689.3 /dev/hdisk60 SAN Volume Controller Device 1.00 5438693 3128 9072.8 /dev/hdisk69 SAN Volume Controller Device 23  2011 IBM Corporation filemon detailed reports

 Detailed reports at PV and LV layers (only for one LV shown)  Similar reports for each PV VOLUME: /dev/rms09_lv description: /RMS/bormspr0/oradata07 reads: 23999 (0 errs) read sizes (blks): avg 439.7 min 16 max 2048 sdev 814.8 read times (msec): avg 85.609 min 0.139 max 1113.574 sdev 140.417 read sequences: 19478 read seq. lengths: avg 541.7 min 16 max 12288 sdev 1111.6 writes: 350 (0 errs) write sizes (blks): avg 16.0 min 16 max 16 sdev 0.0 write times (msec): avg 42.959 min 0.340 max 289.907 sdev 60.348 write sequences: 348 write seq. lengths: avg 16.1 min 16 max 32 sdev 1.2 seeks: 19826 (81.4%) seek dist (blks): init 18262432, avg 24974715.3 min 16 max 157270944 sdev 44289553.4 time to next req(msec): avg 12.316 min 0.000 max 537.792 sdev 31.794 throughput: 17600.8 KB/sec utilization: 1.00

24  2011 IBM Corporation Using filemon  Look at PV summary report  Look for balanced IO across the disks  Lack of balance may be a data layout problem  Depends upon PV to physical disk mapping  LVM mirroring scheduling policy also affects balance for reads  IO service times in the detailed report is more definitive on data layout issues  Dissimilar IO service times across PVs indicates IOs are not balanced across physical disks

 Look at most active LVs report  Look for busy file system logs  Look for file system logs serving more than one file system

 At 6.1, filemon also has reports showing the processes/threads doing IO to files

25  2011 IBM Corporation Using iostat  Use a meaningful interval, 30 seconds to 15 minutes  The first report is since system boot (if sys0’s attribute iostat=true)  Examine IO balance among hdisks  Look for bursty IO (based on syncd interval)

 Useful flags:  -T Puts a time stamp on the data  -a Adapter report (IOs for an adapter) for both physical and virtual  -m Disk path report (IOs down each disk path)  -s System report (overall IO)  -A or –P For standard AIO or POSIX AIO  -D for hdisk queues and IO service times  -R to reset min and max values for each interval  -l puts data on one line (better for scripts)  -p for tape statistics  -f/-F for file system statistics (AIX 6.1 TL1) 26  2011 IBM Corporation Using iostat

# iostat For individual disk and system statistics tty: tin tout avg-cpu: % user % sys % idle % iowait 24.7 71.3 8.3 2.4 85.6 3.6 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 2.2 19.4 2.6 268 894 hdisk1 5.0 231.8 28.1 1944 11964 hdisk2 5.4 227.8 26.9 2144 11524 hdisk3 4.0 215.9 24.8 2040 10916 ... # iostat –ts For total system statistics System configuration: lcpu=4 drives=2 ent=1.50 paths=2 vdisks=2 tty: tin tout avg-cpu: % user % sys % idle % iowait physc % entc 0.0 8062.0 0.0 0.4 99.6 0.0 0.0 0.7 Kbps tps Kb_read Kb_wrtn 82.7 20.7 248 0 0.0 13086.5 0.0 0.4 99.5 0.0 0.0 0.7 Kbps tps Kb_read Kb_wrtn 80.7 20.2 244 0 0.0 16526.0 0.0 0.5 99.5 0.0 0.0 0.8

27  2011 IBM Corporation Using iostat

# iostat -f … FS Name: % tm_act Kbps tps Kb_read Kb_wrtn / - 85.7 113.3 257 0 /usr - 961.1 274.1 2892 0 /var - 0.0 0.0 0 0 /tmp - 0.0 0.0 0 0 /home - 0.0 0.0 0 0 /admin - 0.0 0.0 0 0 /proc - 7.6 17.3 22 0 /opt - 0.0 0.0 0 0 /var/adm/ras/livedum - 0.0 0.0 0 0 /oracle - 2.2 22.9 0 6 /staging - 0.0 0.0 0 0 /ggs - 0.0 0.0 0 0

28  2011 IBM Corporation Using iostat # iostat -DRTl Disks: xfers read write queue time ------%tm bps tps bread bwrtn rps avg min max time fail wps avg min max time fail avg min max avg avg serv act serv serv serv outs serv serv serv outs time time time wqsz sqsz qfull hdisk41 4.6 89.8K 5.7 24.8K 65.0K 3.0 8.5 0.2 28.9 0 0 2.6 9.4 0.4 233.2 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk44 21.6 450.2K 52.0 421.5K 28.7K 51.5 4.3 0.2 39.0 0 0 0.6 5.9 0.5 30.9 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk42 6.6 57.3K 6.8 42.3K 15.0K 5.2 10.9 0.2 32.7 0 0 1.6 7.0 0.3 22.4 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk43 37.2 845.5K 101.4 818.2K 27.3K 99.9 4.0 0.2 47.6 0 0 1.5 17.2 0.4 230.2 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk37 94.4 700.0K 2.2 0.0 700.0K 0.0 0.0 0.0 0.0 0 0 2.2 1.1S 117.9 4.1S 0 0 0.0 0.0 0.1 0.0 0.1 0.0 04:52:25 hdisk53 23.5 296.2K 35.5 269.5K 26.8K 32.9 7.7 0.2 47.0 0 0 2.6 2.5 0.4 27.7 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk51 32.5 471.2K 55.6 445.5K 25.7K 54.4 6.7 0.2 58.8 0 0 1.2 3.1 0.4 13.0 0 0 0.0 0.0 0.1 0.0 0.0 0.0 04:52:25 hdisk56 19.5 178.0K 20.7 122.3K 55.7K 14.9 9.8 0.2 55.0 0 0 5.7 55.8 0.4 318.9 0 0 2.8 0.0 194.4 0.0 0.0 0.6 04:52:25 hdisk48 18.0 149.6K 18.0 101.0K 48.6K 12.3 10.6 0.2 38.5 0 0 5.7 19.0 0.4 250.2 0 0 0.0 0.0 3.7 0.0 0.0 0.3 04:52:25 hdisk46 12.9 167.4K 19.8 156.7K 10.6K 19.1 6.8 0.2 37.5 0 0 0.7 4.4 0.4 17.0 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk57 55.2 608.8K 71.1 574.4K 34.4K 69.5 8.9 0.2 118.3 0 0 1.6 10.1 0.4 216.3 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk55 13.4 244.9K 29.8 234.0K 10.9K 28.6 4.8 0.2 36.9 0 0 1.3 2.6 0.4 22.3 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk50 48.6 616.7K 73.3 575.5K 41.2K 70.3 7.9 0.2 84.5 0 0 3.1 5.7 0.4 40.1 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25 hdisk52 14.5 174.2K 20.6 116.0K 58.1K 14.2 7.7 0.2 36.9 0 0 6.5 10.7 0.4 270.1 0 0 0.0 0.0 0.0 0.0 0.0 0.0 04:52:25

Shows average IO service times for reads and writes, IO rates, IOPS (tps) and time in the hdisk driver queue One can calculate R/W ratio and average IO size Time spent in the queue indicates increasing queue_depth may improve performance sqfull = number of times the hdisk driver’s service queue was full avgserv = average IO service time avgsqsz = average service queue size This can't exceed queue_depth for the disk avgwqsz = average wait queue size Waiting to be sent to the disk If avgwqsz is often > 0, then increase queue_depth If sqfull in the first report is high, then increase queue_depth

29  2011 IBM Corporation Using sar

 sar -d formerly reported zeros for avwait and avserv  avque definition changes in AIX 5.3

# sar -d 1 2 AIX sq1test1 3 5 00CDDEDC4C00 06/22/04 System configuration: lcpu=2 drives=1 ent=0.30

10:01:37 device %busy avque r+w/s Kbs/s avwait avserv 10:01:38 hdisk0 100 36.1 363 46153 51.1 8.3 10:01:39 hdisk0 99 38.1 350 44105 58.0 8.5 Average hdisk0 99 37.1 356 45129 54.6 8.4 avque - average IOs in the wait queue  Waiting to get sent to the disk (the disk's queue is full)  Values > 0 indicate increasing queue_depth may help performance  Used to mean number of IOs in the disk queue avgwait - time (ms) waiting in wait queue avgserv - IO service time (ms) when sent to the disk

30  2011 IBM Corporation Using lvmstat  Provides IO statistics for LVs, VGs and PPs  Useful for SSD data placement  You must enable data collection first for a VG: # lvmstat –e –v  Useful to find busy LVs and PPs root/ # lvmstat -sv rootvg Logical Volume iocnt Kb_read Kb_wrtn Kbps hd8 212 0 848 24.00 hd4 11 0 44 0.23 hd2 3 12 0 0.01 hd9var 2 0 8 0.01 .. hd8 3 0 12 8.00 . hd8 12 0 48 32.00 hd4 1 0 4 2.67

# lvmstat -l lv00 1 Log_part mirror# iocnt Kb_read Kb_wrtn Kbps 1 1 65536 32768 0 0.02 2 1 53718 26859 0 0.01 Log_part mirror# iocnt Kb_read Kb_wrtn Kbps 2 1 5420 2710 0 14263.16 Log_part mirror# iocnt Kb_read Kb_wrtn Kbps 3 1 4449 2224 0 13903.12 2 1 979 489 0 3059.38 31  2011 IBM Corporation Using # nmon - then press “a” for all adapters or “^” for FC adapters

 Easy way to monitor adapter thruput  NMON can also be used to create Excel graphs showing IO over time  Plus CPU, memory, and network IO data 32  2011 IBM Corporation Testing thruput  Sequential IO  Test sequential read thruput from a device: # timex dd if= of=/dev/null bs=1m count=100 # timex dd if=/dev/rhdisk20 of=/dev/null bs=1m count=1024 1024+0 records in. 1024+0 records out. real 3.44 user 0.00 sys 0.17  1024 MB/3.44 s = 297.7 MB/s  Test sequential write thruput to a device: # timex dd if=/dev/zero of= bs=1m count=100  Note that /dev/zero writes the null character, so writing this character to files in a file system will result in sparse files  For file systems, either create a file, or use the lptest command to generate a file, e.g., # lptest 127 32 > 4kfile

33  2011 IBM Corporation Testing thruput with ndisk

Use ndisk which is part of the nstress package, or ndisk64 for structures > 2GB http://www.ibm.com/collaboration/wiki/display/WikiPtype/nstress Do IO to a file or raw LV or hdisk Do IO to multiple devices or files Specify the number of threads doing IO  You need a lot of threads doing IO to stress a disk subsystem Synchronous or asynchronous writes to file system files Specify the IO size or a set of IO sizes Specify the R/W ratio

34  2011 IBM Corporation Testing thruput with ndisk # ndisk64 -R -f /dev/rhdisk20 -r 100 -t 30 –M 20 –s 716800 Command: ndisk -R -f /dev/rhdisk20 -r 100 -t 60 Synchronous Disk test (regular read/write) No. of processes = 20 I/O type = Random Block size = 4096 Read-Write = Read only Sync type: none = just close the file Number of files = 1 File size = … 716800 MB Run time = 30 seconds Snooze % = 0 percent ----> Running test with block Size=4096 (4KB) . Proc - <-----Disk IO----> | <-----Throughput------> RunTime Num - TOTAL IO/sec | MB/sec KB/sec Seconds 1 - 12577 419.2 | 1.64 1676.94 30.00 … 20 - 12577 419.2 | 1.64 1676.98 30.00 TOTALS 251540 8384.8 | 32.75 Rand procs= 20 read=100% bs=4KB

35  2011 IBM Corporation Dealing with cache effects

Prime the cache (recommended) Run the test twice or more and ignore the first run It's recommended to prime the cache, as most applications will be using it and you've paid for it, so you should use it or Flush the cache Unmount and remount file systems For disk subsystems, use #cat > /dev/null The unused file(s) must be larger than the disk subsystem read cache Write cache If we fill up the write cache, IO service times will be at disk speed, not cache speed Use a long running job Reads from the disk subsystem will also inhibit unloading of the write cache

36  2011 IBM Corporation AIX 6.1 Restricted Tunables

 Some ioo/vmo/schedo/raso/nfso/no tuning parameters are now restricted  Generally should only be changed per AIX Support  Display all the tunables using: # -FL  Display non-restricted tunables without the –F flag  smit access via # smitty tuningDev  Dynamic change will show a warning message  Permanent changes require a confirmation  Permanent changes will result in a warning message at boot in the error log  Some restricted tunables relating to disk IO tuning include:

Most aio tunables lru_file_repage j2_nBufferPerPagerDevice lru_poll_interval minpgahead maxperm numclust minperm pv_min_pbuf strict_maxclient sync_release_ilock strict_maxperm page_steal_method

37  2011 IBM Corporation Tuning IO buffers and queues General rule – increase buffers or queue depths until either:  You aren’t running out of buffers or filling the queue  IO service times indicate a bottleneck at the disk subsystem or SAN IOs are delayed due to lack of a buffer or a queue slot Disks and disk subsystem have limits to the maximum number of in-flight IOs they can handle  More than this will result in lost IOs, time outs and resubmission of the IO which severely affects IO performance

38  2011 IBM Corporation The AIX IO stack

Application

Logical file system Rawdisks RawLVs

JFS JFS2 NFS Other File system buffers at this layer

VMM

LVM (LVM device drivers) Disk buffers (pbufs) at this layer Multi-path IO driver (optional) Disk Device Drivers hdisk queue_depth Adapter Device Drivers adapter num_cmd_elems Disk subsystem (optional) Disk Write cache Read cache or memory area used for IO

39  2011 IBM Corporation Tuning IO buffers # -v | tail -5 <-- only last 5 lines needed 0 pending disk I/Os blocked with no pbuf 0 paging space I/Os blocked with no psbuf 8755 filesystem I/Os blocked with no fsbuf 0 client filesystem I/Os blocked with no fsbuf 2365 external pager filesystem I/Os blocked with no fsbuf

 First field is a count of IOs delayed since boot due to lack of the specified buffer  For pbufs, use lvmo to increase pv_pbuf_count (see the next slide)  For psbufs, stop paging or add paging spaces  For filesystem fsbufs, increase numfsbufs with ioo  For external pager fsbufs, increase j2_dynamicBufferPreallocation with ioo  For client filesystem fsbufs, increase nfso's nfs_v3_pdts and nfs_v3_vm_bufs (or the NFS4 equivalents)  Run # ioo –FL to see defaults, current settings and what’s required to make the changes go into effect

40  2011 IBM Corporation Disk pbuf tuning

 Disk buffers are configurable for disks in VGs lvmo -v VgName -o Tunable [ =NewValue ] lvmo [-v VgName] -a # lvmo -a vgname = rootvg pv_pbuf_count = 512 - Number of pbufs added when one PV is added to the VG total_vg_pbufs = 512 - Current pbufs available for the VG max_vg_pbuf_count = 16384 - max pbufs available for the VG, requires remount pervg_blocked_io_count = 1 - delayed IO count since last varyon for the VG pv_min_pbuf = 512 - Minimum number of pbufs added when PV is added to any VG global_blocked_io_count = 1 - System wide delayed IO count  To increase a VG’s pbufs dynamically: # lvmo –v -o pv_pbuf_count=  pv_min_pbuf is tuned via ioo or lvmo  Changes to pv_pbuf_count via lvmo are dynamic  Increase value, collect statistics and change again if necessary  See # lvmo –L

41  2011 IBM Corporation Queue depth tuning

 If IO service times are reasonably good, but queues are getting filled up, then  Increase queue depths until:  You aren’t filling the queues or  IO service times start degrading You’ve moved the bottleneck to the disk  For hdisks, queue_depth controls the maximum number of in-flight IOs  For FC adapters, num_cmd_elems controls maximum number of in-flight IOs  Drivers for hdisks and adapters have service and wait queues  When the queue is full and an IO completes, then another is issued

42  2011 IBM Corporation Queue depth tuning IO flow:  Multipath IO code submits IO to hdisk driver  SDD queues IOs and won’t submit more than queue_depth IOs to a hdisk  Disable this with # datapath qdepth disable for heavy IO  SDDPCM does not queue IOs  Hdisk driver has in process and wait queues – in process queue contains up to queue_depth IOs  Hdisk driver submits IOs to adapter driver  Adapter driver has in process and wait queues – FC adapter in process queue contains up to num_cmd_elems IOs  Adapter driver uses DMA to do IOs  Adapter driver submits IOs to disk subsystem

43  2011 IBM Corporation Queue depth tuning  Useful things to know about attributes for all AIX devices:  List device attributes with # lsattr –EHl # lsattr -EHl hdisk10 attribute value description user_settable

PCM PCM/friend/vscsi Path Control Module False algorithm fail_over Algorithm True hcheck_cmd test_unit_rdy Health Check Command True hcheck_interval 0 Health Check Interval True hcheck_mode nonactive Health Check Mode True max_transfer 0x40000 Maximum TRANSFER Size True pvid 00cee79eaed0872d0000000000000000 Physical volume identifier False queue_depth 3 Queue DEPTH True reserve_policy no_reserve Reserve Policy True  Attributes with user_settable=True can be changed  List allowable values for an attribute with # lsattr –Rl -a # lsattr -Rl hdisk10 -a queue_depth 1...256 (+1)

 To change an attribute use # chdev –l -a = -P  Then reboot, or if the device is not in use, eliminate the “-P” so the change is immediately effective

44  2011 IBM Corporation Queue depth tuning  Fibre channel adapter attributes: # lsattr -El fcs0 bus_intr_lvl 8355 Bus interrupt level False bus_io_addr 0xffc00 Bus I/O address False bus_mem_addr 0xf8040000 Bus memory address False init_link al INIT Link flags True intr_priority 3 Interrupt priority False lg_term_dma 0x1000000 Long term DMA True max_xfer_size 0x100000 Maximum Transfer Size True num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True pref_alpa 0x1 Preferred AL_PA True sw_fc_class 2 FC Class for Fabric True  The max_xfer_size attribute also controls a DMA memory area used to hold data for transfer, and at the default is 16 MB  Changing to other allowable values increases it to 128 MB and increases the adapter’s bandwidth  Often changed to 0x200000  This can result in a problem if there isn’t enough memory on PHB chips in the IO drawer with too many adapters/devices on the PHB  Make the change and reboot – check for Defined devices or errors in the error log, and change back if necessary  For NPIV and virtual FC adapters the DMA memory area is 128 MB at 6.1 TL2 or later 45  2011 IBM Corporation Queue depth tuning

 How to determine if queues are being filled  With SDDPCM: # pcmpath query devstats # pcmpath query adaptstats  With SDD: # datapath query devstats # datapath query adaptstats  With iostat: # iostat –D for data since system boot and # iostat –D for interval data  With fcstat: # fcstat fcs0

46  2011 IBM Corporation Queue depth tuning

 Sample output: # pcmpath query devstats … DEV#: 4 DEVICE NAME: hdisk4 ======Total Read Total Write Active Read Active Write Maximum I/O: 446958 1510783 0 0 128 SECTOR: 13006902 25715160 0 0 24536

Transfer Size: <= 512 <= 4k <= 16K <= 64K > 64K 1032 1825589 40591 54946 35583  Indicates that we queued 128 IOs to the hdisk driver  If queue_depth is 128, we filled the queue # iostat -D hdisk10

System configuration: lcpu=4 drives=35 paths=35 vdisks=2 hdisk10 xfer: %tm_act bps tps bread bwrtn 0.1 1.4K 0.2 442.6 940.9 read: rps avgserv minserv maxserv timeouts fails 0.0 4.6 0.3 67.9 0 0 write: wps avgserv minserv maxserv timeouts fails 0.2 8.2 0.5 106.8 0 0 queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull 5.4 0.0 579.5 0.0 0.0 0.4  The sqfull value represents the number of times we filled the queue per second  Non-zero values indicate we filled the queue 47  2011 IBM Corporation Adapter queue depth tuning

# pcmpath query adaptstats Adapter #: 0 ======Total Read Total Write Active Read Active Write Maximum I/O: 1105909 78 3 0 200 SECTOR: 8845752 0 24 0 88

 Maximum of 200 with num_cmd_elems=200 means we filled the queue

# fcstat fcs0 … FC SCSI Adapter Driver Information No DMA Resource Count: 4490 <- Increase max_xfer_size No Adapter Elements Count: 105688 No Command Resource Count: 133 <- Increase num_cmd_elems …

48  2011 IBM Corporation VIO

 The VIO Server (VIOS) uses multi-path IO code for the attached disk subsystems  The VIO client (VIOC) always uses SCSI MPIO if accessing storage thru two VIOSs  In this case only entire LUNs are served to the VIOC  Set the queue_depth at the VIOC equal to queue_depth at the VIOS for the LUN  If you increase vFC adapter num_cmd_elems, also do it on the real FC adapter  Preferably treat the real FC adapter num_cmd_elems as a shared resource  The VSCSI adapter has a queue also  To avoid queuing on the VSCSI adapter:  Max LUNs/VSCSI adapter =INT(510/(Q+3))  Q is the queue depth of the LUN assuming all are the same  One can monitor adapters with NMON in the oem_setup_env shell

49  2011 IBM Corporation Read ahead  Read ahead detects that we're reading sequentially and gets the data before the application requests it  Reduces %iowait  Too much read ahead means you do IO that you don't need  Operates at the file system layer - sequentially reading files  Set maxpgahead for JFS and j2_maxPgReadAhead for JFS2  Values of 1024 for max page read ahead are not unreasonable  Disk subsystems read ahead too - when sequentially reading disks  Improves IO service time and thruput  Tunable on DS4000, fixed on ESS, DS6000, DS8000 and SVC

50  2011 IBM Corporation Write behind  Initiates writes from file system cache before syncd does it  Write behind tuning for sequential writes to a file  Tune numclust for JFS  Tune j2_nPagesPerWriteBehindCluster for JFS2  These represent 16 KB clusters  Larger values allow IO to be coalesced  When the specified number of sequential 16 KB clusters are updated, start the IO to disk rather than wait for syncd  Write behind tuning for random writes to a file  Tune maxrandwrt for JFS  Tune j2_maxRandomWrite and j2_nRandomCluster for JFS2  Max number of random writes allowed to accumulate to a file before additional IOs are flushed, default is 0 or off  j2_nRandomCluster specifies the number of clusters apart two consecutive writes must be in order to be considered random  If you have bursty IO, consider using write behind to smooth out the IO rate 51  2011 IBM Corporation More on write behind and syncd  syncd - system wide file system cache flushing  Historical Unix feature to improve performance  Applies to asynchronous IOs (not necessarily aio)  inode is locked when each file is synced  There is a tradeoff:  Longer intervals allow more IO to be coalesced  Longer intervals can:  Create bursty IO  Bursty IO can slow down other IO  As IOPS increase, IO service times also increase

52  2011 IBM Corporation JFS2 Sync Tunables – ioo JFS2 Sync Tunables The file system sync operation can be problematic in situations where there is very heavy random I/O activity to a large file. When a sync occurs all reads and writes from user programs to the file are blocked. With a large number of dirty pages in the file the time required to complete the writes to disk can be large. New JFS2 tunables are provided to relieve that situation. • j2_syncPageCount Limits the number of modified pages that are scheduled to be written by sync in one pass for a file. When this tunable is set, the file system will write the specified number of pages without blocking IO to the rest of the file. The sync call will iterate on the write operation until all modified pages have been written. Default: 0 (off), Range: 0-65536, Type: Dynamic, Unit: 4KB pages • j2_syncPageLimit Overrides j2_syncPageCount when a threshold is reached. This is to guarantee that sync will eventually complete for a given file. Not applied if j2_syncPageCount is off. Default: 16, Range: 1-65536, Type: Dynamic, Unit: Numeric • If application response times are impacted by syncd, try j2_syncPageCount settings from 256 to 1024. Smaller values improve short term response times, but still result in larger syncs that impact response times over larger intervals. • These will likely require a lot of experimentation, and detailed analysis of IO behavior. • Does not apply to mmap() memory mapped files. May not apply to shmat() files (TBD)

53  2011 IBM Corporation Mount options  Release behind: rbr, rbw and rbrw  Says to throw the data out of file system cache  rbr is release behind on read  rbw is release behind on write  rbrw is both  Applies to sequential IO only  DIO: Direct IO  Bypasses file system cache  No file system read ahead  No lrud or syncd overhead  No double buffering of data  Half the kernel calls to do the IO  Half the memory transfers to get the data to the application  Requires the application be written to use DIO  CIO: Concurrent IO  The same as DIO but with no i-node locking 54  2011 IBM Corporation The AIX IO stack

Application

Logical file system Rawdisks RawLVs i-node locking : when 2 or more threads access JFS JFS2 NFS Other the same file, and one is a write, the write will block all other read/write threads at this level

VMM

LVM (LVM device drivers) Multi-path IO driver Disk Device Drivers Adapter Device Drivers Disk subsystem (optional) Disk Write cache Read cache or memory area used for IO

55  2011 IBM Corporation Mount options  Direct IO  IOs must be aligned on file system block boundaries  IOs that don’t adhere to this will dramatically reduce performance  Avoid large file enabled JFS file systems - block size is 128 KB after 4 MB # mount -o dio # chfs -a options=rw,dio  DIO process 1 Application issues IO request to kernel 2 Kernel initiates disk IO 3 Data transferred to/from application buffer to disk  Normal file system IO process File system reads File system writes

1 Application issues read request 1 Application issues write request 2 Kernel checks FS cache 2 Kernel writes data to FS cache and returns 1 Data found - kernel copies it to the acknowledgment to app application buffer 1 Application continues 2 Data not found - kernel does disk IO 3 Syncd periodically flushes dirty cache to 3 Data transferred FS cache disk 4 Kernel copies data to app buffer

56  2011 IBM Corporation Mount options  Concurrent IO for JFS2 (not JFS): # mount -o cio # chfs -a options=rw,cio  Assumes that the application ensures data integrity for multiple simultaneous IOs to a file  Changes to meta-data are still serialized  I-node locking: When two threads (one of which is a write) to do IO to the same file are at the file system layer of the IO stack, reads will be blocked while a write proceeds  Provides raw LV performance with file system benefits  Requires an application designed to use CIO  For file system maintenance (e.g. restore a backup) one usually mounts without cio during the maintenance  Some applications now make CIO/DIO calls directly without requiring cio/dio mounts, in which case don’t use the mount options  Important for times when alignment requirements aren’t met, or when file system read ahead helps (like during backups) 57  2011 IBM Corporation No time for atime

 Ingo Molnar ( kernel developer) said:  "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"  If you have a lot of file activity, you have to update a lot of timestamps  File timestamps  File creation (ctime)  File last modified time (mtime)  File last access time (atime)  The noatime mount option disables last access time updates for JFS2  File systems with heavy inode access activity due to file opens can have significant performance improvements  First customer benchmark efix reported 35% improvement with DIO noatime mount (20K+ files)  Most customers should expect much less for production environments

# mount –a rw,noatime /myfilesystem

58  2011 IBM Corporation Disabling file system journaling

 You may lose data in the event of a system crash!  Improves performance for meta-data changes to file systems  When you frequently add, delete or change the size of files  Eliminates IOs to file system log  JFS # mount –o nointegrity  JFS2 # mount -o log=NULL

59  2011 IBM Corporation IO Pacing

 IO pacing - causes the CPU to do something else with a specified amount of IOs to a file in process  Turning it off improves backup times and thruput  Turning it on ensures that no process hogs CPU for IO, and ensures good keyboard response on systems with heavy IO workloads  Default is on with minpout=4096 and maxpout=8193  Originally used to avoid HACMP's dead man switch  Old HACMP recommended values of 33 and 24 significantly inhibit thruput but are reasonable for uniprocessors with non- cached disk  Changed via: # chgsys –l sys0 –a maxpout= -a minpout=  IO pacing per file system via the mount command # mount -o minpout=256 –o maxpout=513 /myfs

60  2011 IBM Corporation Asynchronous IO

 Asynchronous IO automatically turned on at AIX 6.1  AIO kernel threads automatically exit after aio_server_inactivity seconds  AIO kernel threads not used for AIO to raw LVs or CIO mounted file systems  Only aio_maxservers and aio_maxreqs need to be changed  Defaults are 21 and 8K respectively per logical CPU  Set via ioo  Some may want to adjust minservers for heavy AIO use  maxservers is the maximum number of AIOs that can be processed at any one time  maxreqs is the maximum number of AIO requests that can be handled at one time and is a total for the system (they are queued to the AIO kernel threads)  Typical values:

Default OLTP SAP minservers 3 200 400 maxservers 10 800 1200 maxreqs 4096 16384 16384

61  2011 IBM Corporation Asynchronous IO tuning

 Use iostat –A to monitor AIO (or -P for POSIX AIO) # iostat -A System configuration: lcpu=4 drives=1 ent=0.50 aio: avgc avfc maxg maxf maxr avg-cpu: %user %sys %idle %iow physc %entc 25 6 29 10 4096 30.7 36.3 15.1 17.9 0.0 81.9

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 100.0 61572.0 484.0 8192 53380

 avgc - Average global non-fastpath AIO request count per second for the specified interval  avfc - Average AIO fastpath request count per second for the specified interval for IOs to raw LVs (doesn’t include CIO fast path IOs)  maxg - Maximum non-fastpath AIO request count since the last time this value was fetched  maxf - Maximum fastpath request count since the last time this value was fetched  maxr - Maximum AIO requests allowed - the AIO device maxreqs attribute  If maxg or maxf gets close to maxr or maxservers then increase maxreqs or maxservers

62  2011 IBM Corporation SAN attached FC adapters

 Set fscsi dynamic tracking to yes  Allows dynamic SAN changes  Set FC fabric event error recovery fast_fail to yes if the switches support it  Switch fails IOs immediately without timeout if a path goes away  Switches without support result in errors in the error log

# lsattr -El fscsi0 attach switch How this adapter is CONNECTED False dyntrk no Dynamic Tracking of FC Devices True fc_err_recov delayed_fail FC Fabric Event Error RECOVERY Policy True scsi_id 0x1c0d00 Adapter SCSI ID False sw_fc_class 3 FC Class for Fabric True

# chdev –l fscsi0 –a dyntrk=yes –a fc_err_recov=fast_fail –P # shutdown –Fr

63  2011 IBM Corporation VMM the Virtual Memory Manager  All IO requires memory All input goes to memory, all output comes from memory File system cache consumes memory File system cache takes CPU cycles to manage  Initial tuning recommendations: minfree = max [ 960, lcpus x 120 / mempools ] maxfree = minfree + MaxIOSizeIn4KBunits x lcpus / mempools lcpus = number of logical CPUs mempools = number of memory pools (from vmstat –v) MaxIOSizeIn4KBunits is j2_maxPageReadAhead for file system IOs, or what you expect your application’s biggest IO request to be  The idea is that when we call lrud to free up memory for a large IO, we only call it once and it frees up sufficient memory, but not too much

64  2011 IBM Corporation QUESTIONS? COMMENTS?

65  2011 IBM Corporation