Performance Tune Your

iSeries for E1
Session: 27960
Tom Davidson
IBM Certified ILE Specialist
RS Infocon
tdavidson@rsinfocon.com
Ground Rules
• Please set cell phones to ‘stun’

• Feel free to ask questions as we go along, I

may defer to later in the session or offline

• Not all slides in handout will be on-screen,

they are included for your reference
Speaker Bio
• CNC for a $3B Chemical Company for 7
years
• 24+ years on the System i & predecessors
• 10+ years performance tuning
• Now a consultant, working with Xe through
8.12 installations
RS Infocon
• Consulting firm, not a network of contractors
• “Rightsourcer” On-site, off-site, off-shore
• Specialties include complex implementations
& architectures

• Milwaukee Metropolitan Area of Commerce

"Future 50" award in 2006 and 2007
Agenda
• Theory
– How work is processed on System i
– General performance info
– Segregation of work
– E1 units of work
– SQL Indexes
• Practice
– Tools
– System Values
– Segregation of work
– SQL Indexes
– Caching
Definitions
• Job, task, thread – I use these inter
changeably. Normally they are
equivalent (major exception is WAS)

• Indexes - I use index to indicate both an

SQL index and a System I Logical File
Definitions (cont)
• Resource – Something a job needs to continue
it’s work. i.e. CPU, memory, data (disk)

• Performance Tuning – Process of improving

throughput of a system, while simultaneously
ensuring the important work gets done first
Theory
• Goal is to reduce faults, this will increase CPU &
Memory utilization.
• Ensure that all tasks get the appropriate amount
of resources, when they need it.
• Cost is an important element of performance
Theory
• 3 Primary elements of tuning
– CPU Utilization
– Memory Utilization
– Disk Utilization
Acceptable CPU utilization
• Depends upon the # of CPU’s
–# Max Utilization
–1 70%
–4 85%
– 10 92%
– 20 95%
Timeslices
• Used to determine how long a task can
hold the CPU
• Default settings the same as they were
in 1983
• Batch use 1500
• Interactive use 1200
Acceptable Memory Utilization
• This the most subjective, but arguably
the most important
– Memory is ALWAYS over committed
– More is not always better (but normally is)
– Hardest to get a ‘read’ on.
Acceptable Disk Utilization
• Depends on # of arms and total disk space
• In general:
– < 500 G, 70% used
– < 1T, 75% used
– > 5T, 80-85% used
• This assumes that you are using smaller
drives, if you are using large drives these
numbers will be significantly lower
• The number of disk arms is as important as
the amount of disk space
How things work
• Once a job goes active it will hold the CPU
until one of the following occur:
– It consumes its timeslice (known as TSE)
– It reaches a ‘long’ wait.
• Waiting for disk I/O
• Waiting for user input
• Waiting for Communications
How things work (cont)
• Lifecycle of a task
– Job goes active
– Job structures/data paged in (if needed)
– Begins execution
– One of 3 things happen:
• Job reaches TSE
• Job faults
• Job ends
How things work (cont)
– If TSE, question is asked:
• Is there a HIGHER priority task waiting?
– Yes, give up the CPU
– No, continue
– If a fault, question is asked:
• What is the highest priority task waiting
– If job ends, highest priority task waiting is
started
The DATABASE:
• The job of an System I is:
– Maintain the integrity of the database

– Serve the DB to requestors

– Perform other tasks as required

The DATABASE (cont)
• Integrity
– When a record is added/changed/deleted
the file can not be used until ALL indexes
are updated, this is called a seize. Seizes
are normal, and are a required element of
a DB
– The number of indexes can affect the
length of a seize
The DATABASE
Serve the DB to requestors
• This is where performance comes in.
• The database is predictive, it knows when
you are doing sequential operations and will
‘pre-fetch’ data to prevent faults.
• It also knows when you are doing random I/O
and reduces how much it brings in.
• Determines best way to get the data
The DATABASE:
• Perform other tasks
– This is not optimized, DB processes within
these tasks do get optimized.
– This is where you can shine
Segregation of Work
• Performed by isolating tasks in their
own subsystems and memory pools.
• Allows tasks to keep resources in
memory
• Helps prevent ‘thrashing’ & promotes
‘sharing’.
• Implemented via memory pools
Memory pool basics
• All tasks run within a memory pool
• Basic memory pools are:
– 1 *MACHINE - OS runs here
– 2 *BASE - Everything else
– *SPOOL – Printing
– *INTERACT – Green Screen
– Custom Pools
Memory pool basics (cont)
– Max Active – How many tasks can compete for the
CPU, at a time
– Paging and faulting
• Definitions
– Pages is the number of pages brought in
– Faults is the number of times a task requested a page that
was not in memory
• Two types
– Database
» Shows numbers for DB operations
– Non-Database
» Shows numbers for all other operations
Memory pool basics (cont)
– *MACHINE Pool
• If the machine waits EVERYONE waits
• Very little DB work goes on here
• Base system internal tables are a large portion
of this area
• IBM recommends that the number of faults (DB
& Non-DB) be less than 10
Memory pool basics (cont)
– *BASE
• Default pool for most stuff ‘out of the box’
• Holds all memory not currently allocated to other
pools
– *SPOOL
• Used for printing
• It is OK to have large faulting numbers in this
pool
Memory pool basics (cont)
– *INTERACT
• Green Screen jobs run here
• If you are not running many GS apps, keep this
memory constrained
– Custom pools
• User defined
• You will use these pools to do your JDE work
Memory pool basics (cont)
Types of memory pools
• Private
– Dedicated to a single subsystem
• Shared
– May be shared among subsystems
– Allows you to adjust paging characteristics
if you want (you want)
Memory pool basics (cont)
How to determine what pools you need
• Determine what different TYPES of
work you have
– Kernels, ODBC, UBE’s, etc
– Interactive, batch, client/server, etc
• Determine what resources are shared
– Programs, *SRVPGM (DLL), files
Memory pool basics (cont)
• Goal is to reduce faulting
– Reduced faulting normally indicates that
the CPU is being well utilized
– With reduced faulting, active jobs spend
less time waiting and more time processing
– EXCEPTION: If you have a large amount
of jobs at the same priority, you may want
to allow faulting to perform task switching
SQL Indexes
• The only generic way to affect database
performance
• An effective indexing scheme can
improve performance even in the
absence of proper tuning
• A bad indexing scheme can make good
performance impossible
E1 Units of work
• Kernels
– Do most of the ‘real’ work in E1
– You define how many of each type may run
• UBE’s
– Essentially batch jobs
E1 Units of work (cont)
• ODBC (JDBC)
– Not technically a JDE unit of work
– Handles retrieval of data for non-kernel,
non-UBE tasks
• WAS
– Not a JDE unit of work
– Acts as a platform for JDE unit’s of work
SQL Indexes
• Improves performance multiple ways
– Indexes hold information about the data
– Many queries can be implemented in the
index. COUNT, WHERE clause if no
matches
– Reduces amount of data which needs
moving
Agenda
 Theory
– How work is processed on System i
– General performance info
– Segregation of work
– E1 units of work
– SQL Indexes
• Practice
– Tools
– System Values
– Segregation of work
– SQL Indexes
– Caching
Tools
• Green Screen
– WRKSYSSTS
– DSPACTPJ
• Client Access
– Work Management Tasks
• System Values
• Shared pools
• Databases
– SQL Plan Cache
– Index Advisor
Tools (cont)
• Third Party
– Centerfield
– MPG Performance Navigator
– IBM
System Values
• QDYNPTYADJ – Set to 1
• QDYNPTYSCD – Set to 1
• QPFRADJ – Set to 0 or 2
• QQRYDEGREE – Set to *OPTIMIZE
• QQRYTIMLMT=86400 (1day)
System Values (cont)
• QACTJOB = 600
• QADLACTJ = 100
• QTOTJOB = 5000
• QADLTOTJ = 100
• QMAXJOB may need changing if you
have a large shop
Disk Tuning - Journaling
• No need anymore to separate journal to
it’s own ASP
• By default journals are maintained on 1st
10 disk drives
• You may change the journal so that up
to 100 disks are used
• May be cached
Disk Tuning - Journaling
Segregation of work
• Create memory pools for different types
of work
• Create new subsystems for E1 related
tasks
• Modify existing subsystems to use
shared memory pools
Performance and E1
• Elements of E1 on the System I
– JDE Code itself
– ODBC (JDBC)
– UBE’s
– 3rd Party products
– Other products
JDE Elements (examples)
• Kernels
• QZDASOINIT/QSQSRVR
• WAS
• R09801
• Scheduler
Memory pools
• You will need the following pools:
– *MACHINE
– *BASE
– *INTERACT
– *SPOOL
– Kernel Pool
– Batch Pool
– ODBC/JDBC Pool
– WebSphere*
– Package build*
– Cache*
Memory pools (cont)
Tuning
Kernel Memory Pool
Batch
• Create a new subsystem
• Components
– Subsystem description
– Class
– Job Queue
– Routing entry
• Handout contains the ‘How-To’
Create Subsystem Description
Create Class
Add routing entry
Create the job queue
Add job queue to subsystem
JDBC/ODBC - Monitoring
• Use DSPACTPJ command
JDBC/ODBC - Monitoring
JDBC
• Connections handled by QSQSRVR job in
QSYSWRK
• By default they run in *BASE
• Shipped with 5 pre-started
• You want it to share with ODBC
• Rule of thumb: 5 + (3 for each JAS server) + (2 for
each CO kernel)
• Set threshold to 1/3 or 10 which ever is larger
• Set additional to 2 times threshold
ODBC
• Used mostly by developers
• Handled by QZDASOINIT (not SSL) or
QZDASSINIT (SSL)
• Run in it’s own subsystem
• Share memory with JDBC
• Rule of thumb: Start with 100 jobs, Threshold
of 10, Additional twice threshold
ODBC (cont)
• Process
– Create Subsystem
– Add job queue
– Add pre-start job entry
– Create the job description
– Create the ODBC class
– Start subsystem
– Use iSeries Access to route IP’s to new
subsystem
Create ODBC Subsystem
Create job queue
Add job queue to subsystem
Create the job description
Create the class
Add ODBC Pre-start job entry
Add ODBC Pre-start job entry (cont)
Route requests
• Notes:
– Requires static IP’s OR IP address range
• Static IP’s usually not a problem for servers
• Address range works best for DHCP &
developers
Routing Requests (cont)
Routing requests (cont)
SQL Indexing
• You WILL need to add indexes
• I recommend that when you add an index, you do it
via E1
• Several different advisors for what indexes to add.
– iSeries Nav
– QSYS2/SYSIXADV
– Centerfield (third party)
– DBMON (V5R3 & before)
• No matter what method you use, you will need to
determine what the value of the index is.
SQL Indexing
• Considerations
– What is the business purpose for the index.
– Can I extend an existing index?
– Is the index for batch or interactive use?
– How often is the index really used?
– Does it make sense? Can training remove the need?
– If over 60 or so indexes, is it more important than one
of them?
– Remember NOTHING IS FREE.
SQL Indexes – iSeries Navigator
• Index Advisor
– Works at system, database, and file level
– Advantages
• Free, kind of
• Covers a lot
– Disadvantages
• Voluminous
• No selection criteria
SQL Indexes – iSeries Navigator
SQL Indexes - QSYS2/SYSIXADV
• System wide collection – Base O/S
• Advantages
– Absolutely free
– Covers everything
• Disadvantages
– No real interface, must use SQL or
programs
SQL Indexes - Centerfield
• Third party tool
• Advantages
– E1 Module
– Comprehensive
– Data selection capability
– Reporting capability
• Disadvantages
– Extra cost
SQL Indexes - Centerfield
Caching
• Optional, you may do just fine without it
• Pins programs and files in memory so
there is no wait (fault).
• I recommend starting with a cache no
larger than 1% or your system memory
• Best for often used objects.
Caching (cont)
• Reduces the likelihood of data being paged
out
• You really need to know how your DB is
used
• Easy to get carried away, can waste
memory
Caching - Implementation
• Determine what to cache
– Small highly used files, Next numbers
come to mind
– Should be pretty ‘static’
– Programs, look at invocation stacks, don’t
be afraid of QSYS objects
Caching - Implementation (cont)
• Process
– Create subsystem, with private pool
– Create job description
– Add auto-start job
– Schedule periodic refreshes via scheduler
Caching – Implementation (cont)
Caching – Implementation (cont)
Caching – Implementation (cont)
Caching – Implementation (cont)
Caching - SETOBJACC
Summary
• Lots of things you can tweak
• Proper indexing is most important
• Segregation of work helps a lot

• NOTHING HELPS MORE THAN KNOWING YOUR

BUSINESS AND YOUR DATABASE
Questions
Further Reading
• General Performance Info
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.js
• WAS 6 tuning
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebI
• IBM Techdocs
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/
Third party vendors
• RS Infocon http://www.rsinfocon.com/
• Centerfield Technologies http://
www.centerfieldtechnology.com
• Midrange Performance Group
http://www.mpginc.com/