Intel AS-400 RISC Server, 7xx Servers, 170 Servers User Manual

1.38 Mb
Loading...

IBM Power Systems

Performance Capabilities Reference

IBM i operating system Version 6.1

January/April/October 2008

This

document is intended for use by qualified performance related programmers or analysts from IBM, IBM Business Partners and IBM customers using the IBM PowerTM Systems platform running IBM i operating system. Information in this document may be readily shared with IBM i customers to understand the performance and tuning factors in IBM i operating system 6.1 and earlier where applicable. For the latest updates and for the latest on IBM i performance information, please refer to the Performance Management Website: http://www.ibm.com/systems/i/advantages/perfmgmt/index.html

Requests for use of performance information by the technical trade press or consultants should be directed to Systems Performance Department V3T, IBM Rochester Lab, in Rochester, MN. 55901 USA.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

1

Note!

Before using this information, be sure to read the general information under “Special Notices.”

Twenty Fifth Edition (January/April/October 2008) SC41-0607-13

This edition applies to IBM i operating System V6.1 running on IBM Power Systems.

You can request a copy of this document by download from IBM i Center via the System i Internet site at: http://www.ibm.com/systems/i/ . The Version 5 Release 1 and Version 4 Release 5 Performance Capabilities Guides are also available on the IBM iSeries Internet site in the "On Line Library", at: http://publib.boulder.ibm.com/pubs/html/as400/online/chgfrm.htm.

Documents are viewable/downloadable in Adobe Acrobat (.pdf) format. Approximately 1 to 2 MB download. Adobe Acrobat reader plug-in is available at: http://www.adobe.com .

To request the CISC version (V3R2 and earlier), enter the following command on VM:

REQUEST V3R2 FROM FIELDSIT AT RCHVMW2 (your name)

To request the IBM iSeries Advanced 36 version, enter the following command on VM:

TOOLCAT MKTTOOLS GET AS4ADV36 PACKAGE

© Copyright International Business Machines Corporation 2008. All rights reserved.

Note to U.S. Government Users -- Documentation related to restricted rights -- Use, duplication, or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

2

Table of Contents

Special Notices . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Purpose of this Document . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

Chapter 1. Introduction . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Chapter 2. iSeries and AS/400 RISC Server Model Performance Behavior . . . . . . . . . . . . . . . . .

14

2.1

 

Overview . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

 

2.1.1 Interactive Indicators and Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

 

2.1.2 Disclaimer and Remaining Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

 

2.1.3 V5R3 . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

 

2.1.4 V5R2 and V5R1 . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2

 

Server Model Behavior . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

 

2.2.1 In V4R5 - V5R2 . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

 

2.2.2 Choosing Between Similarly Rated Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

 

2.2.3 Existing Older Models . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.3

 

Server Model Differences . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.4

 

Performance Highlights of Model 7xx Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.5

 

Performance Highlights of Model 170 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

2.6

 

Performance Highlights of Custom Server Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.7

 

Additional Server Considerations .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.8

 

Interactive Utilization . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.9

 

Server Dynamic Tuning (SDT) . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.10

Managing Interactive Capacity . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.11

Migration from Traditional Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.12

Upgrade Considerations for Interactive Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

2.13 iSeries for Domino and Dedicated Server for Domino Performance Behavior . . . . . . . . . . . . .

34

 

2.13.1 V5R2 iSeries for Domino & DSD Performance Behavior updates . . . . . . . . . . . . . . . . . . . .

34

 

2.13.2 V5R1 DSD Performance Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

Chapter 3. Batch Performance . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.1

 

Effect of CPU Speed on Batch . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.2

 

Effect of DASD Type on Batch . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.3

 

Tuning Parameters for Batch . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

Chapter 4. DB2 for i5/OS Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.1 New for i5/OS V6R1 . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

 

i5/OS V6R1 SQE Query Coverage .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2

DB2 i5/OS V5R4 Highlights . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

 

i5/OS V5R4 SQE Query Coverage .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.3 i5/OS V5R3 Highlights . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

 

i5/OS V5R3 SQE Query Coverage .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

 

Partitioned Table Support . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.4

V5R2 Highlights - Introduction of the SQL Query Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.5

Indexing . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.6

DB2 Symmetric Multiprocessing feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.7

 

DB2 for i5/OS Memory Sharing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.8

 

Journaling and Commitment Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.9

 

DB2 Multisystem for i5/OS . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

4.10

Referential Integrity . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

4.11

Triggers . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.12

Variable Length Fields . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.13 Reuse Deleted Record Space . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

4.14 Performance References for DB2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

3

Chapter 5. Communications Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.2

Communication Performance Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.5

TCP/IP Secure Performance . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

5.6

Performance Observations and Tips

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

5.7

APPC, ICF, CPI-C, and Anynet . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

5.8

HPR and Enterprise extender considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

5.9

Additional Information . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

Chapter 6. Web Server and WebSphere Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

6.1

HTTP Server (powered by Apache)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

6.2

PHP - Zend Core for i . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

6.3

WebSphere Application Server . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

6.4

IBM WebFacing . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107

6.5

WebSphere Host Access Transformation Services (HATS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

117

6.6

System Application Server Instance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119

6.7

WebSphere Portal . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

121

6.8 WebSphere Commerce . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

121

6.9

WebSphere Commerce Payments .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122

6.10 Connect for iSeries . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122

Chapter 7. Java Performance . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126

7.1

Introduction . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126

7.2

What’s new in V6R1 . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126

7.3

IBM Technology for Java (32-bit and 64-bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

127

 

Native Code . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

128

 

Garbage Collection . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

128

7.4

Classic VM (64-bit) . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

 

JIT Compiler . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

 

Garbage Collection . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

131

 

Bytecode Verification . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

132

7.5

Determining Which JVM to Use . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

133

7.6

Capacity Planning . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

135

 

General Guidelines . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

135

7.7

Java Performance – Tips and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

136

 

Introduction . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

136

 

i5/OS Specific Java Tips and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

137

 

Classic VM-specific Tips . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

137

 

Java Language Performance Tips .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

138

 

Java i5/OS Database Access Tips .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

141

Resources . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142

Chapter 8. Cryptography Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143

8.1

System i Cryptographic Solutions . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143

8.2

Cryptography Performance Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

144

8.3

Software Cryptographic API Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

145

8.4

Hardware Cryptographic API Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

146

8.5

Cryptography Observations, Tips and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

148

8.6

Additional Information . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149

Chapter 9. iSeries NetServer File Serving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150

9.1

iSeries NetServer File Serving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

150

Chapter 10. DB2 for i5/OS JDBC and ODBC Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

153

10.1 DB2 for i5/OS access with JDBC .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

153

 

JDBC Performance Tuning Tips . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

153

 

References for JDBC . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

154

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

4

10.2

DB2 for i5/OS access with ODBC

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155

References for ODBC . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

157

Chapter 11. Domino on i . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

158

11.1

Domino Workload Descriptions .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

159

11.2 Domino 8 . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

160

11.3

Domino 7 . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

160

11.4

Domino 6 . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161

Notes client improvements with Domino 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161

Domino Web Access client improvements with Domino 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

162

11.5

Response Time and Megahertz relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

163

11.6

Collaboration Edition and Domino Edition offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

11.7

Performance Tips / Techniques . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

164

11.8

Domino Web Access . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

11.9

Domino Subsystem Tuning . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

168

11.10 Performance Monitoring Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

168

11.11 Main Storage Options . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

169

11.12 Sizing Domino on System i . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

172

11.13 LPAR and Partial Processor Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

173

11.14 System i NotesBench Audits and Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

174

Chapter 12. WebSphere MQ for iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

12.1

Introduction . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

12.2

Performance Improvements for WebSphere MQ V5.3 CSD6 . . . . . . . . . . . . . . . . . . . . . . . . . . .

175

12.3

Test Description and Results . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

176

12.4

Conclusions, Recommendations and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

176

Chapter 13. Linux on iSeries Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

13.1 Summary . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

Key Ideas . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

13.2

Basic Requirements -- Where Linux Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

178

13.3

Linux on iSeries Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Linux on iSeries Architecture . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

179

Linux on iSeries Run-time Support .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

180

13.4

Basic Configuration and Performance Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181

13.5

General Performance Information and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182

Computational Performance -- C-based code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182

Computational Performance -- Java

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Web Serving Performance . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

183

Network Operations . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

Gcc and High Optimization (gcc compiler option -O3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

184

The Gcc Compiler, Version 3 . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

13.6

Value of Virtual LAN and Virtual Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

Virtual LAN . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

Virtual Disk . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

185

13.7

DB2 UDB for Linux on iSeries . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

186

13.8

Linux on iSeries and IBM eServer Workload Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

187

13.9

Top Tips for Linux on iSeries Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

187

Chapter 14. DASD Performance . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191

14.1

Internal (Native) Attachment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191

14.1.0 Direct Attach (Native) . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

192

14.1.1

Hardware Characteristics

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

192

14.1.2 iV5R2 Direct Attach DASD . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

193

14.1.3

571B . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

5

14.1.3.1 571B RAID5 vs RAID6 - 10 15K 35GB DASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195

14.1.3.2 571B IOP vs IOPLESS - 10 15K 35GB DASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195

14.1.4 571B, 5709, 573D, 5703, 2780 IOA Comparison Chart . . . . . . . . . . . . . . . . . . . . . . . . . .

196

14.1.5 Comparing Current 2780/574F with the new 571E/574F and 571F/575B

 

NOTE: iV5R3 has support for the features in this section but all of our

 

performance measurements were done on iV5R4 systems. For information on the

 

supported features see the IBM Product Announcement Letters. . . . . . . . . . . . . . . . . . . . . . . . . . .

198

14.1.6 Comparing 571E/574F and 571F/575B IOP and IOPLess . . . . . . . . . . . . . . . . . . . . . . . . .

199

14.1.7 Comparing 571E/574F and 571F/575B RAID5 and RAID6 and Mirroring . . . . . . . . . . .

200

14.1.8 Performance Limits on the 571F/575B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

202

14.1.9 Investigating 571E/574F and 571F/575B IOA, Bus and HSL limitations. . . . . . . . . . . . .

203

14.1.10 Direct Attach 571E/574F and 571F/575B Observations . . . . . . . . . . . . . . . . . . . . . . . . .

205

14.2 New in iV5R4M5 . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

14.2.1 9406-MMA CEC vs 9406-570 CEC DASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206

14.2.2 RAID Hot Spare . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

14.2.3 12X Loop Testing . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

208

14.3 New in iV6R1M0 . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

209

14.3.1 Encrypted ASP . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

209

14.3.2 57B8/57B7 IOA . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211

14.3.3 572A IOA . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

213

14.4 SAN - Storage Area Network (External) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

214

14.5.1 General VIOS Considerations . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

216

14.5.1.1 Generic Concepts . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

216

14.5.1.2 Generic Configuration Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

217

14.5.1.3 Specific VIOS Configuration Recommendations -- Traditional (non-blade)

 

Machines . .

. .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

220

14.5.1.3 VIOS and JS12 Express and JS22 Express Considerations . . . . . . . . . . . . . . . . . . . . . . . . . .

222

14.5.1.3.1

BladeCenter H JS22 Express running IBM i operating system/VIOS . . . . . . . . . .

222

14.5.1.3.2

BladeCenter S and JS12 Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

227

14.5.1.3.3

JS12 Express and JS22 Express Configuration Considerations . . . . . . . . . . . . . . . . .

228

14.5.1.3.4 DS3000/DS4000 Storage Subsystem Performance Tips . . . . . . . . . . . . . . . . . . . . . . .

229

14.6 IBM i operating system 5.4 Virtual SCSI Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

231

14.6.1 Introduction . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

233

14.6.2 Virtual SCSI Performance Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

234

14.6.2.1

Native vs. Virtual Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

235

14.6.2.2

Virtual SCSI Bandwidth-Multiple Network Storage Spaces . . . . . . . . . . . . . . . . . . . . . .

235

14.6.2.3

Virtual SCSI Bandwidth-Network Storage Description (NWSD) Scaling . . . . . . . . . . . .

236

14.6.2.4

Virtual SCSI Bandwidth-Disk Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

237

14.6.3 Sizing

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

238

14.6.3.1

Sizing when using Dedicated Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

238

14.6.3.2

Sizing when using Micro-Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

240

14.6.3.3

Sizing memory . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

241

14.6.4 AIX Virtual IO Client Performance Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242

14.6.5 Performance Observations and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242

14.6.6 Summary . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242

Chapter 15. Save/Restore Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

243

15.1 Supported Backup Device Rates .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

243

15.2 Save Command Parameters that Affect Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244

Use Optimum Block Size (USEOPTBLK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244

Data Compression (DTACPR) . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244

Data Compaction (COMPACT) . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

244

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

6

15.3

Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

245

15.4

Comparing Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

246

15.5

Lower Performing Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

247

15.6

Medium & High Performing Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

247

15.7

Ultra High Performing Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

247

15.8

The Use of Multiple Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

248

15.9

Parallel and Concurrent Library Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

249

15.9.1 Hardware (2757 IOAs, 2844 IOPs, 15K RPM DASD) . . . . . . . . . . . . . . . . . . . . . . . . . . .

249

15.9.2

Large File Concurrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

250

15.9.3

Large File Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

251

15.9.4 User Mix Concurrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

252

15.10 Number of Processors Affect Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

253

15.11 DASD and Backup Devices Sharing a Tower . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

254

15.12

Virtual Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

255

15.13

Parallel Virtual Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

257

15.14

Concurrent Virtual Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

258

15.15Save and Restore Scaling using a Virtual Tape Drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

15.16Save and Restore Scaling using 571E IOAs and U320 15K DASD units to a

3580 Ultrium 3 Tape Drive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

260

15.17

High-End Tape Placement on System i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

262

15.18

BRMS-Based Save/Restore Software Encryption and DASD-Based ASP

 

Encryption . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

263

15.19

5XX Tape Device Rates . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

265

15.20

5XX Tape Device Rates with 571E & 571F Storage IOAs and 4327 (U320)

 

Disk Units . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

267

15.21

5XX DVD RAM and Optical Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

268

15.23

9406-MMA DVD RAM . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

270

15.24

9406-MMA 576B IOPLess IOA

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

271

Chapter 16 IPL Performance . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

273

16.1

IPL Performance Considerations .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

273

16.2

IPL Test Description . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

273

16.3

9406-MMA System Hardware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

274

16.3.1 Small system Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

274

16.3.2 Large system Hardware Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

274

16.4

9406-MMA IPL Performance Measurements (Normal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

275

16.5

9406-MMA IPL Performance Measurements (Abnormal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

275

16.6 NOTES on MSD . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

276

16.6.1 MSD Affects on IPL Performance Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

276

16.7

5XX System Hardware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

277

16.7.1 5XX Small system Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

277

16.7.2 5XX Large system Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

277

16.8

5XX IPL Performance Measurements (Normal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

278

16.9

5XX IPL Performance Measurements (Abnormal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

278

16.10

5XX IOP vs IOPLess effects on IPL Performance (Normal) . . . . . . . . . . . . . . . . . . . . . . . . . . .

279

16.11

IPL Tips . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

279

Chapter 17. Integrated BladeCenter and System x Performance . . . . . . . . . . . . . . . . . . . . . . . . .

280

17.1

Introduction . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

280

17.2

Effects of Windows and Linux loads on the host system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

281

17.2.1 IXS/IXA Disk I/O Operations: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

281

17.2.2 iSCSI Disk I/O Operations: .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

282

17.2.3 iSCSI virtual I/O private memory pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

283

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

7

17.2.4 Virtual Ethernet Connections: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

284

17.2.5 IXS/IXA IOP Resource: . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285

17.3

System i memory rules of thumb for IXS/IXA and iSCSI attached servers. . . . . . . . . . . . . . . . .

285

17.3.1 IXS and IXA attached servers: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285

17.3.2 iSCSI attached servers: . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285

17.4

Disk I/O CPU Cost . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

286

17.4.1 Further notes about IXS/IXA Disk Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

287

17.5

Disk I/O Throughput . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

288

17.6

Virtual Ethernet CPU Cost and Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

289

17.6.1 VE Capacity Comparisons .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

290

17.6.2 VE CPW Cost . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

291

17.6.3 Windows CPU Cost . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

291

17.7

File Level Backup Performance . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

292

17.8 Summary . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

293

17.9

Additional Sources of Information

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

293

Chapter 18. Logical Partitioning (LPAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

18.1

Introduction . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

V5R3 Information . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

V5R2 Additions . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

General Tips . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

V5R1 Additions . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

18.2

Considerations . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296

18.3

Performance on a 12-way system .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

297

18.4 LPAR Measurements . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

300

18.5 Summary . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

301

Chapter 19. Miscellaneous Performance Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

302

19.1

Public Benchmarks (TPC-C, SAP, NotesBench, SPECjbb2000, VolanoMark) . . . . . . . . . . . . .

302

19.2

Dynamic Priority Scheduling . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

304

19.3

Main Storage Sizing Guidelines .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

307

19.4

Memory Tuning Using the QPFRADJ System Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

307

19.5

Additional Memory Tuning Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

308

19.6

User Pool Faulting Guidelines . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

310

19.7

AS/400 NetFinity Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

311

Chapter 20. General Performance Tips and Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

314

20.1

Adjusting Your Performance Tuning for Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

314

20.2

General Performance Guidelines -- Effects of Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

316

20.3

How to Design for Minimum Main Storage Use (especially with Java, C, C++) . . . . . . . . . . . . .

317

Theory -- and Practice . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

317

System Level Considerations . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

318

Typical Storage Costs . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

318

A Brief Example . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

319

Which is more important? . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

320

A Short but Important Tip about Data Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

321

A Final Thought About Memory and Competitiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

321

20.4

Hardware Multi-threading (HMT)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

322

HMT Described . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

322

HMT and SMT Compared and Contrasted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

323

Models With/Without HMT . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

323

20.5 POWER6 520 Memory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324

20.6

Aligning Floating Point Data on Power6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

325

Chapter 21. High Availability Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

8

21.1 Switchable IASP’s . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

327

21.2 Geographic Mirroring . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

329

Chapter 22. IBM Systems Workload Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

334

22.1 Overview . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

334

22.2 Merging PM for System i data into the Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335

22.3 Estimator Access . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335

22.4 What the Estimator is Not . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

335

Appendix A. CPW and CIW Descriptions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

337

A.1 Commercial Processing Workload - CPW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

337

A.2 Compute Intensive Workload - CIW .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

339

Appendix B. System i Sizing and Performance Data Collection Tools . . . . . . . . . . . . . . . . . . . .

341

B.1

Performance Data Collection Services

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

342

B.2

Batch Modeling Tool (BCHMDL).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

343

Appendix C. CPW and MCU Relative Performance Values for System i . . . . . . . . . . . . . . . . . .

345

C.1

V6R1 Additions (October 2008) . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

346

C.2

V6R1 Additions (August 2008) . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

347

C.3

V6R1 Additions (April 2008) . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

347

C.4

V6R1 Additions (January 2008) . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

348

C.5

V5R4 Additions (July 2007) . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

349

C.6

V5R4 Additions (January/May/August 2006 and January/April 2007) . . . . . . . . . . . . . . . . . . . .

349

C.7

V5R3 Additions (May, July, August, October 2004, July 2005) . . . . . . . . . . . . . . . . . . . . . . . . .

351

 

C.7.1 IBM ~® i5 Servers . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

351

C.8

V5R2 Additions (February, May, July 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

353

 

C.8.1 iSeries Model 8xx Servers . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

353

C.8.2 Model 810 and 825 iSeries for Domino (February 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

354

C.9

V5R2 Additions . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

354

 

C.9.1 Base Models 8xx Servers . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

354

 

C.9.2 Standard Models 8xx Servers . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

354

C.10 V5R1 Additions . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

355

 

C.10.1 Model 8xx Servers . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

356

 

C.10.2 Model 2xx Servers . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

357

 

C.10.3 V5R1 Dedicated Server for Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

357

 

C.10.4 Capacity Upgrade on-demand Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

357

 

C.10.4.1 CPW Values and Interactive Features for CUoD Models . . . . . . . . . . . . . . . . . . . . . . .

358

C.11 V4R5 Additions . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

360

 

C.11.1 AS/400e Model 8xx Servers . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

360

 

C.11.2 Model 2xx Servers . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361

 

C.11.3 Dedicated Server for Domino .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361

 

C.11.4 SB Models . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

362

C.12 V4R4 Additions . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

362

 

C.12.1 AS/400e Model 7xx Servers . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

362

 

C.12.2 Model 170 Servers . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

363

C.13 AS/400e Model Sxx Servers . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

365

C.14 AS/400e Custom Servers . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

365

C.15 AS/400 Advanced Servers . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

365

C.16 AS/400e Custom Application Server Model SB1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

366

C.17 AS/400 Models 4xx, 5xx and 6xx Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

367

C.18 AS/400 CISC Model Capacities . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

368

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

9

Special Notices

DISCLAIMER NOTICE

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. This information is presented along with general recommendations to assist the reader to have a better understanding of IBM(*) products. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

All performance data contained in this publication was obtained in the specific operating environment and under the conditions described within the document and is presented as an illustration. Performance

obtained in other operating environments may vary and customers should conduct their own testing.

Information is provided "AS IS" without warranty of any kind.

The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.

Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Commercial Relations, IBM Corporation, Purchase, NY 10577.

Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

10

The following terms, which may or may not be denoted by an asterisk (*) in this publication, are trademarks of the IBM Corporation.

iSeries or AS/400

System/370

Operating System/400

C/400

IPDS

i5/OS

OS/400

COBOL/400

Application System/400

System i5

RPG/400

OfficeVision

System i

CallPath

Facsimile Support/400

PS/2

DRDA

Distributed Relational Database Architecture

OS/2

SQL/400

Advanced Function Printing

DB2

ImagePlus

Operational Assistant

AFP

VTAM

Client Series

IBM

APPN

Workstation Remote IPL/400

SQL/DS

SystemView

Advanced Peer-to-Peer Networking

400

ValuePoint

OfficeVision/400

CICS

DB2/400

iSeries Advanced Application Architecture

S/370

ADSM/400

ADSTAR Distributed Storage Manager/400

RPG IV

AnyNet/400

IBM Network Station

AIX

 

Lotus, Lotus Notes, Lotus Word Pro, Lotus 1-2-3

Micro-partitioning

POWER4

POWER4+

POWER

POWER5

POWER5+

PowerTM Systems

POWER6

POWER6+

PowerPC

PowerTM Systems Software

PowerTM Systems Software

The following terms, which may or may not be denoted by a double asterisk (**) in this publication, are trademarks or registered trademarks of other companies as follows:

TPC Benchmark

Transaction Processing Performance Council

TPC-A, TPC-B

Transaction Processing Performance Council

TPC-C, TPC-D

Transaction Processing Performance Council

ODBC, Windows NT Server, Access

Microsoft Corporation

Visual Basic, Visual C++

Microsoft Corporation

Adobe PageMaker

Adobe Systems Incorporated

Borland Paradox

Borland International Incorporated

CorelDRAW!

Corel Corporation

Paradox

Borland International

WordPerfect

Satelite Software International

BEST/1

BGS Systems, Inc.

NetWare

Novell

Compaq

Compaq Computer Corporation

Proliant

Compaq Computer Corporation

BAPCo

Business Application Performance Corporation

Harvard

Gaphics Software Publishing Corporation

HP-UX

Hewlett Packard Corporation

HP 9000

Hewlett Packard Corporation

INTERSOLV

Intersolve, Inc.

Q+E

Intersolve, Inc.

Netware

Novell, Inc.

SPEC

Systems Performance Evaluation Cooperative

UNIX

UNIX Systems Laboratories

WordPerfect

WordPerfect Corporation

Powerbuilder

Powersoft Corporation

SQLWindows

Gupta Corporation

NetBench

Ziff-Davis Publishing Company

DEC Alpha

Digital Equipment Corporation

Microsoft, Windows, Windows 95, Windows NT, Internet Explorer, Word, Excel, and Powerpoint, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product or service names may be trademarks or service marks of others.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

11

Purpose of this Document

The intent of this document is to help provide guidance in terms of IBM i operating system performance, capacity planning information, and tips to obtain optimal performance on IBM i operating system. This document is typically updated with each new release or more often if needed. This October 2008 edition of the IBM i V6.1 Performance Capabilities Reference Guide is an update to the April 2008 edition to reflect new product functions announced on October 7, 2008.

This edition includes performance information on newly announced IBM Power Systems including Power 520 and Power 550, utilizing POWER6 processor technology. This document further includes information on IBM System i 570 using POWER6 processor technology, IBM i5/OS running on IBM BladeCenter JS22 using POWER6 processor technology, recent System i5 servers (model 515, 525, and 595) featuring new user-based licensing for the 515 and 525 models and a new 2.3GHz model 595, DB2 UDB for iSeries SQL Query Engine Support, Websphere Application Server including WAS V6.1 both with the Classic VM and the IBM Technology for Java (32-bit) VM, WebSphere Host Access Transformation Services (HATS) including the IBM WebFacing Deployment Tool with HATS Technology (WDHT), PHP - Zend Core for i, Java including Classic JVM (64-bit), IBM Technology for Java (32-bit), IBM Technology for Java (64-bit) and bytecode verification, Cryptography, Domino 7, Workplace Collaboration Services (WCS), RAID6 versus RAID5 disk comparisons, new internal storage adapters, Virtual Tape, and IPL Performance.

The wide variety of applications available makes it extremely difficult to describe a "typical" workload. The data in this document is the result of measuring or modeling certain application programs in very specific and unique configurations, and should not be used to predict specific performance for other applications. The performance of other applications can be predicted using a system sizing tool such as IBM Systems Workload Estimator (refer to Chapter 22 for more details on Workload Estimator).

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

IBM i Performance Capabilities

12

Chapter 1. Introduction

IBM System i and IBM System p platforms unified the value of their servers into a single, powerful lineup of servers based on industry leading POWER6 processor technology with support for IBM i operating system (formerly known as i5/OS), IBM AIX and Linux for Power.

Following along with this exciting unification are a number of naming changes to the formerly named i5/OS, now officially called IBM i operating system. Specifically, recent versions of the operating system are referred to by IBM i operating system 6.1 and IBM i operating system 5.4, formerly i5/OS V6R1 and i5/OS V5R4 respectively. Shortened forms of the new operating system name are IBM i 6.1, i 6.1, i V6.1 iV6R1, and sometimes simply ‘i’. As always, references to legacy hardware and software will commonly use the naming conventions of the time.

The Power 520 Express Edition is the entry member of the Power Systems portfolio, supporting both IBM i 5.4 and IBM i 6.1. The System i 570 is enhanced to enable medium and large enterprises to grow and extend their IBM i business applications more affordably and with more granularity, while offering effective and scalable options for deploying Linux and AIX applications on the same secure, reliable system.

The IBM Power 570 running IBM i offers IBM's fastest POWER6 processors in 2 to 16-way configurations, plus an array of other technology advances. It is designed to deliver outstanding price/performance, mainframe-inspired reliability and availability features, flexible capacity upgrades, and innovative virtualization technologies. New 5.0GHz and 4.4GHz POWER6 processors use the very latest 64-bit IBM POWER processor technology. Each 2-way 570 processor card contains one two-core chip (two processors) and comes with 32 MB of L3 cache and 8 MB of L2 cache.

The CPW ratings for systems with POWER6 processors are approximately 70% higher than equivalent POWER5 systems and approximately 30% higher than equivalent POWER5+ systems. For some compute-intensive applications, the new System i 570 can deliver up to twice the performance of the original 570 with 1.65 GHz POWER5 processors.

The 515 and 525 models introduced in April 2007, introduce user-based licensing for IBM i. For assistance in determining the required number of user licenses, see http://www.ibm.com/systems/i/hardware/515 (model 515) or http://www.ibm.com/systems/i/hardware/525 (model 525). User-based licensing is not a replacement for system sizing; instead, user-based licensing enables appropriate user connectivity to the system. Application environments require different amounts of system resources per user. See Chapter 22 (IBM Systems Workload Estimator) for assistance in system sizing.

Customers who wish to remain with their existing hardware but want to move to IBM i 6.1 may find functional and performance improvements. IBM i 6.1 continues to help protect the customer's investment while providing more function and better price/performance over previous

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 1- Introduction

13

versions. The primary public performance information web site is found at: http://www.ibm.com/systems/i/advantages/perfmgmt/index.html

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 1- Introduction

14

Chapter 2. iSeries and AS/400 RISC Server Model Performance Behavior

2.1 Overview

iSeries and AS/400 servers are intended for use primarily in client/server or other non-interactive work environments such as batch, business intelligence, network computing etc. 5250-based interactive work can be run on these servers, but with limitations. With iSeries and AS/400 servers, interactive capacity can be increased with the purchase of additional interactive features. Interactive work is defined as any job doing 5250 display device I/O. This includes:

All 5250 sessions

RUMBA/400

Any green screen interface

Screen scrapers

Telnet or 5250 DSPT workstations

Interactive subsystem monitors

5250/HTML workstation gateway

Twinax printer jobs

PC's using 5250 emulation

BSC 3270 emulation

Interactive program debugging

5250 emulation

PC Support/400 work station function

 

Note that printer work that passes through twinax media is treated as interactive, even though there is no “user interface”. This is true regardless of whether the printer is working in dedicated mode or is printing spool files from an out queue. Printer activity that is routed over a LAN through a PC print controller are not considered to be interactive.

This explanation is different than that found in previous versions of this document. Previous versions indicated that spooled work would not be considered to be interactive and were in error.

As of January 2003, 5250 On-line Transaction Processing (OLTP) replaces the term “interactive” when referencing interactive CPW or interactive capacity. Also new in 2003, when ordering a iSeries server, the customer must choose between a Standard Package and an Enterprise Package in most cases. The Standard Packages comes with zero 5250 CPW and 5250 OLTP workloads are not supported. However, the Standard Package does support a limited 5250 CPW for a system administrator to manage various aspects of the server. Multiple administrative jobs will quickly exceed this capability. The Enterprise Package does not have any limits relative to 5250 OLTP workloads. In other words, 100% of the server capacity is available for 5250 OLTP applications whenever you need it.

5250 OLTP applications can be run after running the WebFacing Tool of IBM WebSphere Development Studio for iSeries and will require no 5250 CPW if on V5R2 and using model 800, 810, 825, 870, or 890 hardware.

2.1.1 Interactive Indicators and Metrics

Prior to V4R5, there were no system metrics that would allow a customer to determine the overall interactive feature capacity utilization. It was difficult for the customer to determine how much of the total interactive capacity he was using and which jobs were consuming interactive capacity. This got much easier with the system enhancements made in V4R5 and V5R1.

Starting with V4R5, two new metrics were added to the data generated by Collection Services to report the system's interactive CPU utilization (ref file QAPMSYSCPU). The first metric (SCIFUS) is the

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

15

interactive utilization - an average for the interval. Since average utilization does not indicate potential problems associated with peak activity, a second metric (SCIFTE) reports the amount of interactive utilization that occurred above threshold. Also, interactive feature utilization was reported when printing a System Report generated from Collection Services data. In addition, Management Central now monitors interactive CPU relative to the system/partition capacity.

Also in V4R5, a new operator message, CPI1479, was introduced for when the system has consistently exceeded the purchased interactive capacity on the system. The message is not issued every time the capacity is reached, but it will be issued on an hourly basis if the system is consistently at or above the limit. In V5R2, this message may appear slightly more frequently for 8xx systems, even if there is no change in the workload. This is because the message event was changed from a point that was beyond the purchased capacity to the actual capacity for these systems in V5R2.

In V5R1, Collection Services was enhanced to mark all tasks that are counted against interactive capacity (ref file QAPMJOBMI, field JBSVIF set to ‘1’). It is possible to query this file to understand what tasks have contributed to the system’s interactive utilization and the CPU utilized by all interactive tasks. Note: the system’s interactive capacity utilization may not be equal to the utilization of all interactive tasks. Reasons for this are discussed in Section 2.10, Managing Interactive Capacity.

With the above enhancements, a customer can easily monitor the usage of interactive feature and decide when he is approaching the need for an interactive feature upgrade.

2.1.2 Disclaimer and Remaining Sections

The performance information and equations in this chapter represent ideal environments. This information is presented along with general recommendations to assist the reader to have a better understanding of the iSeries server models. Actual results may vary significantly.

This chapter is organized into the following sections:

yServer Model Behavior

yServer Model Differences

yPerformance Highlights of New Model 7xx Servers

yPerformance Highlights of Current Model 170 Servers

yPerformance Highlights of Custom Server Models

yAdditional Server Considerations

yInteractive Utilization

yServer Dynamic Tuning (SDT)

yManaging Interactive Capacity

yMigration from Traditional Models

yMigration from Server Models

yDedicated Server for Domino (DSD) Performance Behavior

2.1.3 V5R3

Beginning with V5R3, the processing limitations associated with the Dedicated Server for Domino (DSD) models have been removed. Refer to section 2.13, “Dedicated Server for Domino Performance Behavior”, for additional information.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

16

2.1.4 V5R2 and V5R1

There were several new iSeries 8xx and 270 server model additions in V5R1 and the i890 in V5R2. However, with the exception of the DSD models, the underlying server behavior did not change from V4R5. All 27x and 8xx models, including the new i890 utilize the same server behavior algorithm that was announced with the first 8xx models supported by V4R5. For more details on these new models, please refer to Appendix C, CPW, CIW and MCU Values for iSeries”.

Five new iSeries DSD models were introduced with V5R1. In addition, V5R1 expanded the capability of the DSD models with enhanced support of Domino-complementary workloads such as Java Servlets and WebSphere Application Server. Please refer to Section 2.13, Dedicated Server for Domino Performance Behavior, for additional information.

2.2 Server Model Behavior

2.2.1 In V4R5 - V5R2

Beginning with V4R5, all 2xx, 8xx and SBx model servers utilize an enhanced server algorithm that manages the interactive CPU utilization. This enhanced server algorithm may provide significant user benefit. On prior models, when interactive users exceed the interactive CPW capacity of a system, additional CPU usage visible in one or more CFINT tasks, reduces system capacity for all users including client/server. New in V4R5, the system attempts to hold interactive CPU utilization below the threshold where CFINT CPU usage begins to increase. Only in cases where interactive demand exceeds the limitations of the interactive capacity for an extended time (for example: from long-running, CPU-intensive transactions), will overhead be visable via the CFINT tasks. Highlights of this new algorithm include the following:

yAs interactive users exceed the installed interactive CPW capacity, the response times of those applications may significantly lengthen and the system will attempt to manage these interactive excesses below a level where CFINT CPU usage begins to increase. Generally, increased CFINT may still occur but only for transient periods of time. Therefore, there should be remaining system capacity available for non-interactive users of the system even though the interactive capacity has been exceeded. It is still a good practice to keep interactive system use below the system interactive CPW threshold to avoid long interactive response times.

yClient/server users should be able to utilize most of the remaining system capacity even though the interactive users have temporarily exceeded the maximum interactive CPW capacity.

yThe iSeries Dedicated Server for Domino models behave similarly when the Non Domino CPW capacity has been exceeded (i.e. the system attempts to hold Non Domino CPW capacity below the threshold where CFINT overhead is normally activated). Thus, Domino users should be able to run in the remaining system capacity available.

yWith the advent of the new server algorithm, there is not a concept known as the interactive knee or interactive cap. The system just attempts to manage the interactive CPU utilization to the level of the interactive CPW capacity.

yDynamic priority adjustment (system value QDYNPTYADJ) will not have any effect managing the interactive workloads as they exceed the system interactive CPW capacity. On the other hand, it won’t hurt to have it activated.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

17

yThe new server algorithm only applies to the new hardware available in V4R5 (2xx, 8xx and SBx models). The behavior of all other hardware, such as the 7xx models is unchanged (see section 2.2.3 Existing Model section for 7xx algorithm).

2.2.2 Choosing Between Similarly Rated Systems

Sometimes it is necessary to choose between two systems that have similar CPW values but different processor megahertz (MHz) values or L2 cache sizes. If your applications tend to be compute intensive such as Java, WebSphere, EJBs, and Domino, you may want to go with the faster MHz processors because you will generally get faster response times. However, if your response times are already sub-second, it is not likely that you will notice the response time improvements. If your applications tend to be L2 cache friendly such as many traditional commercial applications are, you may want to choose the system that has the larger L2 cache. In either case, you can use the IBM eServer Workload Estimator to help you select the correct system (see URL: http://www.ibm.com/iseries/support/estimator ) .

2.2.3 Existing Older Models

Server model behavior applies to:

yAS/400 Advanced Servers

yAS/400e servers

yAS/400e custom servers

yAS/400e model 150

yiSeries model 170

yiSeries model 7xx

Relative performance measurements are derived from commercial processing workload (CPW) on iSeries and AS/400. CPW is representative of commercial applications, particularly those that do significant database processing in conjunction with journaling and commitment control.

Traditional (non-server) AS/400 system models had a single CPW value which represented the maximum workload that can be applied to that model. This CPW value was applicable to either an interactive workload, a client/server workload, or a combination of the two.

Now there are two CPW values. The larger value represents the maximum workload the model could support if the workload were entirely client/server (i.e. no interactive components). This CPW value is for the processor feature of the system. The smaller CPW value represents the maximum workload the model could support if the workload were entirely interactive. For 7xx models this is the CPW value for the interactive feature of the system.

The two CPW values are NOT additive - interactive processing will reduce the system's client/server processing capability. When 100% of client/server CPW is being used, there is no CPU available for interactive workloads. When 100% of interactive capacity is being used, there is no CPU available for client/server workloads.

For model 170s announced in 9/98 and all subsequent systems, the published interactive CPW represents the point (the "knee of the curve") where the interactive utilization may cause increased overhead on the system. (As will be discussed later, this threshold point (or knee) is at a different value for previously announced server models). Up to the knee the server/batch capacity is equal to the processor capacity (CPW) minus the interactive workload. As interactive requirements grow beyond the knee, overhead

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

18

grows at a rate which can eventually eliminate server/batch capacity and limit additional interactive growth. It is best for interactive workloads to execute below (less than) the knee of the curve.

(However, for those models having the knee at 1/3 of the total interactive capacity, satisfactory performance can be achieved.) The following graph illustrates these points.

Model 7xx and 9/98 Model 170 CPU CPU Distribution vs. Interactive Utilization

 

100

 

 

Announced

 

 

 

 

Capacities

%

80

 

 

Stop Here!

 

 

 

CPU

60

Available for

 

available

Available

 

Client/Server

Knee

overhead

40

 

 

 

interactive

 

 

 

 

20

 

 

 

 

0

 

 

 

 

0

 

Full

7/6

 

 

Fraction of Interactive CPW

 

Applies to: Model 170 announced in 9/98 and ALL systems announced on or after 2/99

Figure 2.1. Server Model behavior

The figure above shows a straight line for the effective interactive utilization. Real/customer environments will produce a curved line since most environments will be dynamic, due to job initiation, interrupts, etc.

In general, a single interactive job will not cause a significant impact to client/server performance

Microcode task CFINTn, for all iSeries models, handles interrupts, task switching, and other similar system overhead functions. For the server models, when interactive processing exceeds a threshold amount, the additional overhead required will be manifest in the CFINTn task. Note that a single interactive job will not incur this overhead.

There is one CFINTn task for each processor. For example, on a single processor system only CFINT1 will appear. On an 8-way processor, system tasks CFINT1 through CFINT8 will appear. It is possible to see significant CFINT activity even when server/interactive overhead does not exist. For example if there are lots of synchronous or communication I/O or many jobs with many task switches.

The effective interactive utilization (EIU) for a server system can be defined as the useable interactive utilization plus the total of CFINT utilization.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

19

2.3 Server Model Differences

Server models were designed for a client/server workload and to accommodate an interactive workload. When the interactive workload exceeds an interactive CPW threshold (the “knee of the curve”) the client/server processing performance of the system becomes increasingly impacted at an accelerating rate beyond the knee as interactive workload continues to build. Once the interactive workload reaches the maximum interactive CPW value, all the CPU cycles are being used and there is no capacity available for handling client/server tasks.

Custom server models interact with batch and interactive workloads similar to the server models but the degree of interaction and priority of workloads follows a different algorithm and hence the knee of the curve for workload interaction is at a different point which offers a much higher interactive workload capability compared to the standard server models.

For the server models the knee of the curve is approximately: y100% of interactive CPW for:

yiSeries model 170s announced on or after 9/98

y7xx models

y6/7 (86%) of interactive CPW for: yAS/400e custom servers

y1/3 of interactive CPW for:

yAS/400 Advanced Servers

yAS/400e servers

yAS/400e model 150

yiSeries model 170s announced in 2/98

For the 7xx models the interactive capacity is a feature that can be sized and purchased like any other feature of the system (i.e. disk, memory, communication lines, etc.).

The following charts show the CPU distribution vs. interactive utilization for Custom Server and pre-2/99 Server models.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

20

Custom Server Model

CPU Distribution vs. Interactive Utilization

 

100

 

 

 

CPU

80

 

 

 

60

Available for

 

available

Available

Knee

40

Client/Server

CFINT

 

 

interactive

20

 

 

 

 

0

0

6/7

Full

 

 

Fraction of Interactive CPW

Applies to: AS/400e Custom Servers, AS/400e Mixed Mode Servers

Figure 2.2. Custom Server Model behavior

Server Model

CPU Distribution vs. Interactive Utilization

 

100

 

 

 

80

 

 

CPU

60

Available for

available

Client/Server

Available

 

CFINT

 

 

40

 

interactive

 

Knee

 

 

20

 

 

 

 

 

0

 

 

 

0

1/3 Int-CPW

Full Int-CPW

Fraction of Interactive CPW

Applies to: AS/400 Advanced Servers, AS/400e servers,

Model 150, Model 170s announced in 2/98

Figure 2.3. Server Model behavior

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

21

2.4 Performance Highlights of Model 7xx Servers

7xx models were designed to accommodate a mixture of traditional “green screen” applications and more intensive “server” environments. Interactive features may be upgraded if additional interactive capacity is required. This is similar to disk, memory, or other features.

Each system is rated with a processor CPW which represents the relative performance (maximum capacity) of a processor feature running a commercial processing workload (CPW) in a client/server environment. Processor CPW is achievable when the commercial workload is not constrained by main storage or DASD.

Each system may have one of several interactive features. Each interactive feature has an interactive CPW associated with it. Interactive CPW represents the relative performance available to perform host-centric (5250) workloads. The amount of interactive capacity consumed will reduce the available processor capacity by the same amount. The following example will illustrate this performance capacity interplay:

Model 7xx and 9/98 Model 170

CPU Distribution vs. Interactive Utilization

 

 

Model 7xx Processor FC 206B

(240 / 70 CPW)

 

100

 

 

 

 

 

Announced

 

 

 

 

 

 

 

 

80

 

 

 

 

 

Capacities

%

 

 

 

 

 

Stop Here!

CPU

60

Available for

 

 

 

available

Available

40

Client/Server

 

Knee

CFINT

 

 

 

 

 

interactive

20

 

 

 

 

 

34%

 

 

 

 

 

 

 

0

 

 

 

 

29.2%

 

 

 

 

 

 

 

 

 

0

20

40

60

80

100 (7/6)117

 

% of Published Interactive CPU

Applies to: Model 170 announced in 9/98 and ALL systems announced on or after 2/99

Figure 2.4. Model 7xx Utilization Example

At 110% of percent of the published interactive CPU, or 32.1% of total CPU, CFINT will use an additional 39.8% (approximate) of the total CPU, yielding an effective interactive CPU utilization of approximately 71.9%. This leaves approximately 28.1% of the total CPU available for client/server work. Note that the CPU is completely utilized once the interactive workload reaches about 34%. (CFINT would use approximately 66% CPU). At this saturation point, there is no CPU available for client/server.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

22

2.5 Performance Highlights of Model 170 Servers

iSeries Dedicated Server for Domino models will be generally available on September 24, 1999. Please refer to Section 2.13, iSeries Dedicated Server for Domino Performance Behavior, for additional information.

Model 170 servers (features 2289, 2290, 2291, 2292, 2385, 2386 and 2388) are significantly more powerful than the previous Model 170s announced in Feb. '98. They have a faster processor (262MHz vs. 125MHz) and more main memory (up to 3.5GB vs. 1.0GB). In addition, the interactive workload balancing algorithm has been improved to provide a linear relationship between the client/server (batch) and published interactive workloads as measured by CPW.

The CPW rating for the maximum client/server workload now reflects the relative processor capacity rather than the "system capacity" and therefore there is no need to state a "constrained performance" CPW. This is because some workloads will be able to run at processor capacity if they are not DASD, memory, or otherwise limited.

Just like the model 7xx, the current model 170s have a processor capacity (CPW) value and an interactive capacity (CPW) value. These values behave in the same manner as described in the

Performance highlights of new model 7xx servers section.

As interactive workload is added to the current model 170 servers, the remaining available client/server (batch) capacity available is calculated as: CPW (C/S batch) = CPW(processor) - CPW(interactive)

This is valid up to the published interactive CPW rating. As long as the interactive CPW workload does not exceed the published interactive value, then interactive performance and client/server (batch) workloads will be both be optimized for best performance. Bottom line, customers can use the entire interactive capacity with no impacts to client/server (batch) workload response times.

On the current model 170s, if the published interactive capacity is exceeded, system overhead grows very quickly, and the client/server (batch) capacity is quickly reduced and becomes zero once the interactive workload reaches 7/6 of the published interactive CPW for that model.

The absolute limit for dedicated interactive capacity on the current models can be computed by multiplying the published interactive CPW rating by a factor of 7/6. The absolute limit for dedicated client/server (batch) is the published processor capacity value. This assumes that sufficient disk and memory as well as other system resources are available to fit the needs of the customer's programs, etc. Customer workloads that would require more than 10 disk arms for optimum performance should not be expected to give optimum performance on the model 170, as 10 disk access arms is the maximum configuration.

When the model 170 servers are running less than the published interactive workload, no Server Dynamic Tuning (SDT) is necessary to achieve balanced performance between interactive and client/server (batch) workloads. However, as with previous server models, a system value (QDYNPTYADJ - Server Dynamic Tuning ) is available to determine how the server will react to work requests when interactive workload exceeds the "knee". If the QDYNPTYADJ value is turned on, client/server work is favored over additional interactive work. If it is turned off, additional interactive work is allowed at the expense of low-priority client/server work. QDYNPTYADJ only affects the server when interactive requirements exceed the published interactive capacity rating. The shipped default value is for QDYNPTYADJ to be turned on.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

23

The next chart shows the performance capacity of the current and previous Model 170 servers.

Previous vs. Current AS/400e server 170 Performance

 

1200

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1090

 

1000

 

 

 

 

 

 

 

 

 

 

 

 

 

Values

800

 

 

Previous *

 

 

 

Current

 

 

 

 

 

 

 

 

 

 

 

 

600

 

 

 

 

 

 

 

 

 

 

 

 

 

CPW

 

 

 

 

 

 

 

 

 

 

 

460

460

 

400

 

 

 

319

319

 

 

 

 

 

 

 

 

 

200

 

 

210

 

 

 

 

 

 

220

 

 

 

 

 

114

 

 

 

 

 

 

115

 

 

 

 

 

 

73

 

 

67

 

 

 

 

 

70

70

 

 

23

29

40

 

50

73

30

50

 

0

16

 

15

20

25

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2159

2160

2164

2176

2183

2289

2290

2291

2292

2385

2386

2388

Interactive

Processor

* Unconstrained V4R2 rates

Figure 2.5. Previous vs. Current Server 170 Performance

2.6 Performance Highlights of Custom Server Models

Custom server models were available in releases V4R1 through V4R3. They interact with batch and interactive workloads similar to the server models but the degree of interaction and priority of workloads is different, and the knee of the curve for workload interaction is at a different point. When the interactive workload exceeds approximately 6/7 of the maximum interactive CPW (the knee of the curve), the client/server processing performance of the system becomes increasingly impacted. Once the interactive workload reaches the maximum interactive CPW value, all the CPU cycles are being used and there is no

capacity available for handling client/server tasks.

2.7 Additional Server Considerations

It is recommended that the System Operator job run at runpty(9) or less. This is because the possibility exists that runaway interactive jobs will force server/interactive overhead to their maximum. At this point it is difficult to initiate a new job and one would need to be able to work with jobs to hold or cancel runaway jobs.

You should monitor the interactive activity closely. To do this take advantage of PM/400 or else run Collection Services nearly continuously and query monitor data base each day for high interactive use

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

24

and higher than normal CFINT values. The goal is to avoid exceeding the threshold (knee of the curve) value of interactive capacity.

2.8 Interactive Utilization

When the interactive CPW utilization is beyond the knee of the curve, the following formulas can be used to determine the effective interactive utilization or the available/remaining client/server CPW. These equations apply to all server models.

CPWcs(maximum) = client/server CPW maximum value

CPWint(maximum) = interactive CPW maximum value

CPWint(knee)

= interactive CPW at the knee of the curve

CPWint

= interactive CPW of the workload

X is the ratio that says how far into the overhead zone the workload has extended:

X = (CPWint - CPWint(knee)) / (CPWint(maximum) - CPWint(knee))

EIU = Effective interactive utilization. In other words, the free running, CPWint(knee), interactive plus the combination of interactive and overhead generated by X.

EIU = CPWint(knee) + (X * (CPWcs(maximum) - CPWint(knee)))

CPW remaining for batch = CPWcs(maximum) - EIU

Example 1:

A model 7xx server has a Processor CPW of 240 and an Interactive CPW of 70. The interactive CPU percent at the knee equals (70 CPW / 240 CPW) or 29.2%.

The maximum interactive CPU percent (7/6 of the Interactive CPW ) equals (81.7 CPW / 240 CPW) or

34%.

Now if the interactive CPU is held to less than 29.2% CPU (the knee), then the CPU available for the System, Batch, and Client/Server work is 100% - the Interactive CPU used.

If the interactive CPU is allowed to grow above the knee, say for example 32.1 % (110% of the knee), then the CPU percent remaining for the Batch and System is calculated using the formulas above:

X = (32.1 - 29.2) / (34 - 29.2) = .604

EIU = 29.2 + (.604 * (100 - 29.2)) = 71.9%

CPW remaining for batch = 100 - 71.9 = 28.1%

Note that a swing of + or - 1% interactive CPU yields a swing of effective interactive utilization (EIU) from 57% to 87%. Also note that on custom servers and 7xx models, environments that go beyond the interactive knee may experience erratic behavior.

Example 2:

A Server Model has a Client/Server CPW of 450 and an Interactive CPW of 50. The maximum interactive CPU percent equals (50 CPW / 450 CPW) or 11%.

The interactive CPU percent at the knee is 1/3 the maximum interactive value. This would equal 4%.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

25

Now if the interactive CPU is held to less than 4% CPU (the knee), then the CPU available for the System, Batch, and Client/Server work is 100% - the Interactive CPU used.

If the interactive CPU is allowed to grow above the knee, say for example 9% (or 41 CPW), then the CPU percent remaining for the Batch and System is calculated using the formulas above:

X = (9 - 4) / (11 - 4) = .71 (percent into the overhead area)

EIU = 4 + (.71 * (100 - 4)) = 72%

CPW remaining for batch = 100 - 72 = 28%

Note that a swing of + or - 1% interactive CPU yields a swing of effective interactive utilization (EIU) from 58% to 86%.

On earlier server models, the dynamics of the interactive workload beyond the knee is not as abrupt, but because there is typically less relative interactive capacity the overhead can still cause inconsistency in response times.

2.9 Server Dynamic Tuning (SDT)

Logic was added in V4R1 and is still in use today so customers could better control the impact of interactive work on their client/server performance. Note that with the new Model 170 servers (features 2289, 2290, 2291, 2292, 2385, 2386 and 2388) this logic only affects the server when interactive requirements exceed the published interactive capacity rating. For further details see the section,

Performance highlights of current model 170 servers.

Through dynamic prioritization, all interactive jobs will be put lower in the priority queue, approximately at the knee of the curve. Placing the interactive jobs at a lesser priority causes the interactive jobs to slow down, and more processing power to be allocated to the client/server processing. As the interactive jobs receive less processing time, their impact on client/server processing will be lessened. When the interactive jobs are no longer impacting client/server jobs, their priority will dynamically be raised again.

The dynamic prioritization acts as a regulator which can help reduce the impact to client/server processing when additional interactive workload is placed on the system. In most cases, this results in better overall throughput when operating in a mixed client/server and interactive environment, but it can cause a noticeable slowdown in interactive response.

To fully enable SDT, customers MUST use a non-interactive job run priority (RUNPTY parameter) value of 35 or less (which raises the priority, closer to the default priority of 20 for interactive jobs).

Changing the existing non-interactive job’s run priority can be done either through the Change Job (CHGJOB) command or by changing the RUNPTY value of the Class Description object used by the non-interactive job. This includes IBM-supplied or application provided class descriptions.

Examples of IBM-supplied class descriptions with a run priority value higher than 35 include QBATCH and QSNADS and QSYSCLS50. Customers should consider changing the RUNPTY value for QBATCH and QSNADS class descriptions or changing subsystem routing entries to not use class descriptions QBATCH, QSNADS, or QSYSCLS50.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

26

If customers modify an IBM-supplied class description, they are responsible for ensuring the priority value is 35 or less after each new release or cumulative PTF package has been installed. One way to do this is to include the Change Class (CHGCLS) command in the system Start Up program.

NOTE: Several IBM-supplied class descriptions already have RUNPTY values of 35 or less. In these cases no user action is required. One example of this is class description QPWFSERVER with RUNPTY(20). This class description is used by Client Access database server jobs QZDAINIT (APPC) and QZDASOINIT (TCP/IP).

The system deprioritizes jobs according to groups or "bands" of RUNPTY values. For example, 10-16 is band 1, 17-22 is band 2, 23-35 is band 3, and so on.

Interactive jobs with priorities 10-16 are an exception case with V4R1. Their priorities will not be adjusted by SDT. These jobs will always run at their specified 10-16 priority.

When only a single interactive job is running, it will not be dynamically reprioritized.

When the interactive workload exceeds the knee of the curve, the priority of all interactive jobs is decreased one priority band, as defined by the Dynamic Priority Scheduler, every 15 seconds. If needed, the priority will be decreased to the 52-89 band. Then, if/when the interactive CPW work load falls below the knee, each interactive job's priority will gradually be reset to its starting value when the job is dispatched.

If the priority of non-interactive jobs are not set to 35 or lower, SDT stills works, but its effectiveness is greatly reduced, resulting in server behavior more like V3R6 and V3R7. That is, once the knee is exceeded, interactive priority is automatically decreased. Assuming non-interactive is set at priority 50, interactive could eventually get decreased to the 52-89 priority band. At this point, the processor is slowed and interactive and non-interactive are running at about the same priority. (There is little priority difference between 47-51 band and the 52-89 band.) If the Dynamic Priority Scheduler is turned off, SDT is also turned off.

Note that even with SDT, the underlying server behavior is unchanged. Customers get no more CPU cycles for either interactive or non-interactive jobs. SDT simply tries to regulate interactive jobs once they exceed the knee of the curve.

Obviously systems can still easily exceed the knee and stay above it, by having a large number of interactive jobs, by setting the priority of interactive jobs in the 10-16 range, by having a small client/server workload with a modest interactive workload, etc. The entire server behavior is a partnership with customers to give non-interactive jobs the bulk of the CPU while not entirely shutting out interactive.

To enable the Server Dynamic Tuning enhancement ensure the following system values are on: (the shipped defaults are that they are set on)

yQDYNPTYSCD - this improves the job scheduling based on job impact on the system.

yQDYNPTYADJ - this uses the scheduling tool to shift interactive priorities after the threshold is reached.

The Server Dynamic Tuning enhancement is most effective if the batch and client/server priorities are in the range of 20 to 35.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

27

Server Dynamic Tuning Recommendations

On the new systems and mixed mode servers have the QDYNPTYSCD and QDYNPTYADJ system value set on. This preserves non-interactive capacities and the interactive response times will be dynamic beyond the knee regardless of the setting. Also set non-interactive class run priorities to less than 35.

On earlier servers and 2/98 model 170 systems use your interactive requirements to determine the settings. For “pure interactive” environments turn the QDYNPTYADJ system value off. in mixed environments with important non-interactive work, leave the values on and change the run priority of important non-interactive work to be less than 35.

Affects of Server Dynamic Tuning

Server Dynamic Tuning - .

Server Dynamic Tuning

High "Server" Demand

Mixed "Server" Demand

 

100

 

 

 

 

100

 

 

 

CPU

80

 

 

 

CPU

80

 

 

 

60

Available for

 

60

Available for

available

available

O.H. or Server

Available

 

Client/Server

Available

 

Client/Server

40

interactive

40

Int. or Server

Knee

 

 

Knee

 

interactive

20

 

 

 

20

 

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

0

 

 

 

 

0

1/3 Int-CPW

Full Int-CPW

 

0

1/3 Int-CPW

Full Int-CPW

Fraction of Interactive CPW

Fraction of Interactive CPW

With sufficient batch or client/server load, Interactive is constrained to the "knee-level" by priority degradation

Interactive suffers poor response times

Without high "server" demand, Interactive allowed to grow to limit

Overhead introduced just as when Dynamic Priority Adjust is turned off

Figure 2.6.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

28

2.10 Managing Interactive Capacity

Interactive/Server characteristics in the real world.

Graphs and formulas listed thus far work perfectly, provided the workload on the system is highly regular and steady in nature. Of course, very few systems have workloads like that. The more typical case is a dynamic combination of transaction types, user activity, and batch activity. There may very well be cases where the interactive activity exceeds the documented limits of the interactive capacity, yet decreases quickly enough so as not to seriously affect the response times for the rest of the workload. On the other hand, there may also be some intense transactions that force the interactive activity to exceed the documented limits interactive feature for a period of time even though the average CPU utilization appears to be less than these documented limits.

For 7xx systems, current 170 systems, and mixed-mode servers, a goal should be set to only rarely exceed the threshold value for interactive utilization. This will deliver the most consistent performance for both interactive and non-interactive work.

The questions that need to be answered are:

1.“How do I know whether my system is approaching the interactive limits or not?”

2.“What is viewed as ‘interactive’ by the system?”

3.“How close to the threshold can a system get without disrupting performance?”

This section attempts to answer these questions.

Observing Interactive CPU utilization

The most commonly available method for observing interactive utilization is Collection Services used in conjunction with the Performance Tools program product. The monitor collects system data as well as data for each job on the system, including the CPU consumed and the type of job. By examining the reports generated by the Performance Tools product, or by writing a query against the data in the various performance data base files.

Note: data is written to these files based on sample interval (Smallest is 5 minutes, default is 15 minutes). This data is an average for the duration of a measurement interval.

1.The first metric of interest is how much of the system’s interactive capacity has been used. The file QAPMSYSCPU field SCIFUS contains the amount of interactive feature CPU time used. This metric became available with Collection Services in V4R5.

2.Even though average CPU may be reasonable your interactive workload may still be exceeding limits at times. The file QAPMSYSCPU field SCIFTE contains the amount of time the interactive threshold was exceeded during the interval. This metric became available with Collection Services in V4R5.

3.To determine what jobs are responsible for interactive feature consumption, you can look at the data in QAPMJOBL (Collection Services) or QAPMJOBS (Performance Monitor):

y If using Collection Services on a V5R1 or later system, those jobs which the machine considers to be interactive are indicated by the field JBSVIF =’1’. These are all jobs that could contribute to your interactive feature utilization.

y In all cases you can examine the jobs that are considered interactive by OS/400 as indicated by field JBTYPE = “I”. Although not totally accurate, in most cases this will provide an adequate list of jobs that contributed to interactive utilization.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

29

There are other means for determining interactive utilization. The easiest of these is the performance monitoring function of Management Central, which became available with V4R3. Management Central can provide:

yGraphical, real-time monitoring of interactive CPU utilization

yCreation of an alert threshold when an alert feature is turned on and the graph is highlighted

yCreation of an reverse threshold below which the highlights are turned off

yMultiple methods of handling the alert, from a console message to the execution of a command to the forwarding of the alert to another system.

By taking the ratio of the Interactive CPW rating and the Processor CPW rating for a system, one can determine at what CPU percentage the threshold is reached (This ratio works for the 7xx models and the current model 170 systems. For earlier models, refer to other sections of this document to determine what fraction of the Interactive CPW rating to use.) Depending on the workload, an alert can be set at some percentage of this level to send a warning that it may be time to redistribute the workload or to consider upgrading the interactive feature.

Finally, the functions of PM400 can also show the same type of data that Collection Services shows, with the advantage of maintaining a historical view, and the disadvantage of being only historical. However, signing up for the PM400 service can yield a benefit in determining the trends of how interactive capacities are used on the system and whether more capacity may be needed in the future.

Is Interactive really Interactive?

Earlier in this document, the types of jobs that are classified as interactive were listed. In general, these jobs all have the characteristic that they have a 5250 workstation communications path somewhere within the job. It may be a 5250 data stream that is translated into html, or sent to a PC for graphical display, but the work on the iSeries is fundamentally the same as if it were communicating with a real 5250-type display. However, there are cases where jobs of type “I” may be charged with a significant amount of work that is not “interactive”. Some examples follow:

yJob initialization: If a substantial amount of processing is done by an interactive job’s initial program, prior to actually sending and receiving a display screen as a part of the job, that processing may not be included as a part of the interactive work on the system. However, this may be somewhat rare, since most interactive jobs will not have long-running initial programs.

yMore common will be parallel activities that are done on behalf of an interactive job but are not done within the job. There are two database-related activities where this may be the case.

1.If the QQRYDEGREE system value is adjusted to allow for parallelism or the CHGQRYA command is used to adjust it for a single job, queries may be run in service jobs which are not interactive in nature, and which do not affect the total interactive utilization of the system. However, the work done by these service jobs is charged back to the interactive job. In this case, Collection Services and most other mechanisms will all show a higher sum of interactive CPU utilization than actually occurs. The exception to this is the WRKSYSACT command, which may show the current activity for the service jobs and/or the activity that they have “charged back” to the requesting jobs. Thus, in this situation it is possible for WRKSYSACT to show a lower system CPU utilization than the sum of the CPU consumption for all the jobs.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

30

2.A similar effect can be found with index builds. If parallelism is enabled, index creation (CRTLF, Create Index, Open a file with MAINT(*REBUILD), or running a query that requires an index to be build) will be sent to service jobs that operate in non-interactive mode, but charge their work back to the job that requested the service. Again, the work does not count as “interactive”, but the performance data will show the resource consumption as if they were.

yLastly when only a single interactive job is running, the machine grants an exemption and does not include this job’s activity in the interactive feature utilization.

There are two key ideas in the statements above. First, if the workload has a significant component that is related to queries or there is a single interactive job running, it will be possible to show an interactive job utilization in the performance tools that is significantly higher than what would be assumed and reported from the ratings of the Interactive Feature and the Processor Feature. Second, although it may make monitoring interactive utilization slightly more difficult, in the case where the workload has a significant query component, it may be beneficial to set the QQRYDEGREE system value to allow at least 2 processes, so that index builds and many queries can be run in non-interactive mode. Of course, if the nature of the query is such that it cannot be split into multiple tasks, the whole query is run inside the interactive job, regardless of how the system value is set.

How close to the threshold can a system get without disrupting performance?

The answer depends on the dynamics of the workload, the percentage of work that is in queries, and the projected growth rate. It also may depend on the number of processors and the overall capacity of the interactive feature installed. For example, a job that absorbs a substantial amount of interactive CPU on a uniprocessor may easily exceed the threshold, even though the “normal” work on the system is well under it. On the other hand, the same job on a 12-way can use at most 1/12th of the CPU, or 8.3%. a single, intense transaction may exceed the limit for a short duration on a small system without adverse affects, but on a larger system the chances of having multiple intense transactions may be greater.

With all these possibilities, how much of the Interactive feature can be used safely? A good starting point is to keep the average utilization below about 70% of the threshold value (Use double the threshold value for the servers and earlier Model 170 systems that use the 1/3 algorithm described earlier in this document.) If the measurement mechanism averages the utilization over a 15 minute or longer period, or if the workload has a lot of peaks and valleys, it might be worthwhile to choose a target that is lower than 70%. If the measurement mechanism is closer to real-time, such as with Management Central, and if the workload is relatively constant, it may be possible to safely go above this mark. Also, with large interactive features on fairly large processors, it may be possible to safely go to a higher point, because the introduction of workload dynamics will have a smaller effect on more powerful systems.

As with any capacity-related feature, the best answer will be to regularly monitor the activity on the system and watch for trends that may require an upgrade in the future. If the workload averages 60% of the interactive feature with almost no overhead, but when observed at 65% of the feature capacity it shows some limited amount of overhead, that is a clear indication that a feature upgrade may be required. This will be confirmed as the workload grows to a higher value, but the proof point will be in having the historical data to show the trend of the workload.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

31

2.11 Migration from Traditional Models

This section describes a suggested methodology to determine which server model is appropriate to contain the interactive workload of a traditional model when a migration of a workload is occurring. It is assumed that the server model will have both interactive and client/server workloads.

To get the same performance and response time, from a CPU perspective, the interactive CPU utilization of the current traditional model must be known. Traditional CPU utilization can be determined in a number of ways. One way is to sum up the CPU utilization for interactive jobs shown on the Work with Active Jobs (WRKACTJOB) command.

***************************************************************************

Work with Active Jobs

CPU %: 33.0

Elapsed time: 00:00:00

Active jobs:

152

Type

options, press Enter.

 

 

 

 

2=Change

3=Hold

4=End

5=Work with

6=Release 7=Display message

8=Work with spooled files

13=Disconnect ...

 

Opt

Subsystem/Job

User

Type

CPU %

Function

Status

__

BATCH

 

QSYS

SBS

0

 

DEQW

__

QCMN

 

QSYS

SBS

0

 

DEQW

__

QCTL

 

QSYS

SBS

0

PGM-QEZSCNEP

DEQW

__

QSYSSCD

QPGMR

BCH

0

EVTW

__

QINTER

 

QSYS

SBS

0

PGM-BUPMENUNE

DEQW

__

DSP05

 

TESTER

INT

0.2

DSPW

__

QPADEV0021

TEST01

INT

0.7

CMD-WRKACTJOB

RUN

__

QSERVER

 

QSYS

SBS

0

 

DEQW

__

QPWFSERVSD

QUSER

BCH

0

 

SELW

__

QPWFSERVS0

QUSER

PJ

0

 

DEQW

**************************************************************************

(Calculate the average of the CPU utilization for all job types "INT" for the desired time interval for interactive CPU utilization - "P" in the formula shown below.)

Another method is to run Collection Services during selected time periods and review the first page of the Performance Tools for iSeries licensed program Component Report. The following is an example of this section of the report:

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

32

***********************************************************************************

Component Report Component Interval Activity Data collected 190396 at 1030

Member . . . : Q960791030

Model/Serial . : 310-2043/10-0751D Main St...

 

 

Library. . : PFR

System name. . : TEST01

Version/Re..

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ITV

 

 

Tns/hr

 

Rsp/Tns

CPU %

 

CPU%

CPU %

 

Disk I/O

Disk I/O

 

End

 

 

 

 

 

Total

 

Inter

Batch

 

per sec

per sec

 

 

 

 

 

 

 

 

 

 

 

 

Sync

Async

 

10:36

 

 

6,164

 

0.8

85.2

 

32.2

46.3

 

102.9

39

 

10:41

 

 

7,404

 

0.9

91.3

 

45.2

39.5

 

103.3

33.9

 

10:46

 

 

5,466

 

0.7

97.6

 

38.8

51

 

96.6

33.2

 

10:51

 

 

5,622

 

1.2

97.9

 

35.6

57.4

 

86.6

49

 

10:56

 

 

4,527

 

0.8

97.9

 

16.5

77.4

 

64.2

40.7

 

:

 

 

 

 

 

 

 

 

 

 

 

 

 

11:51

 

 

5,068

 

1.8

99.9

 

74.2

25.7

 

56.5

19.9

 

11:56

 

 

5,991

 

2.4

99.9

 

46.8

45.5

 

65.5

32.6

Itv End------

Interval end time (hour and minute)

 

 

 

 

 

 

Tns/hr-------

Number of interactive transactions per hour

 

 

 

 

Rsp/Tns-----

Average interactive transaction response time

 

 

 

 

***********************************************************************************

(Calculate the average of the CPU utilization under the "Inter" heading for the desired time interval for interactive CPU utilization - "P" in the formula shown below.)

It is possible to have interactive jobs that do not show up with type "INT" in Collection Services or the Component Report. An example is a job that is submitted as a batch job that acquires a work station. These jobs should be included in the interactive CPU utilization count.

Most systems have peak workload environments. Care must be taken to ensure that peaks can be contained in server model environments. Some environments could have peak workloads that exceed the interactive capacity of a server model or could cause unacceptable response times and throughput.

In the following equations, let the interactive CPU utilization of the existing traditional system be represented by percent P. A server model that should then produce the same response time and throughput would have a CPW of:

Server Interactive CPW = 3 * P * Traditional CPW

 

or for Custom Models use:

 

Server Interactive CPW = 1.0 * P * Traditional CPW

(when P < 85%)

or

 

Server interactive CPW = 1.5 * P * Traditional CPW

(when P >= 85%)

Use the 1.5 factor to ensure the custom server is sized less than 85% CPU utilization.

These equations provide the server interactive CPU cycles required to keep the interactive utilization at or below the knee of the curve, with the current interactive workload. The equations given at the end of the Server and Custom Server Model Behavior section can be used to determine the effective interactive utilization above the knee of the curve. The interactive workload below the knee of the curve represents

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

33

one third of the total possible interactive workload, for non-custom models. The equation shown in this section will migrate a traditional system to a server system and keep the interactive workload at or below the knee of the curve, that is, using less than two thirds of the total possible interactive workload. In some environments these equations will be too conservative. A value of 1.2, rather than 1.5 would be less conservative. The equations presented in the Interactive Utilization section should be used by those customers who understand how server models work above the knee of the curve and the ramifications of the V4R1 enhancement.

These equations are for migration of “existing workload” situations only. Installation workload projections for “initial installation” of new custom servers are generally sized by the business partner for 50 - 60% CPW workloads and no “formula increase” would be needed.

For example, assume a model 510-2143 with a single V3R6 CPW rating of 66.7 and assume the Performance Tools for iSeries report lists interactive work CPU utilization as 21%. Using the previous formula, the server model must have an interactive CPW rating of at least 42 to maintain the same performance as the 510-2143.

Server interactive CPW = 3 * P * Traditional CPW

=3 * .21 * 66.7

=42

A server model with an interactive CPW rating of at least 42 could approximate the same interactive work of the 510-2143, and still leave system capacity available for client/server activity. An S20-2165 is the first AS/400e series with an acceptable CPW rating (49.7).

Note that interactive and client/server CPWs are not additive. Interactive workloads which exceed (even briefly) the knee of the curve will consume a disproportionate share of the processing power and may result in insufficient system capacity for client/server activity and/or a significant increase in interactive response times.

2.12 Upgrade Considerations for Interactive Capacity

When upgrading a system to obtain more processor capacity, it is important to consider upgrading the interactive capacity, even if additional interactive work is not planned. Consider the following hypothetical example:

yThe original system has a processor capacity of 1000 CPW and an interactive capacity of 250 ICPW

yThe proposed upgrade system has a processor capacity of 4000 CPW and also offers an interactive capacity of 250 ICPW.

yOn the original system, the interactive capacity allowed 25% of the total system to be used for interactive work. On the new system, the same interactive capacity only allows 6.25% of the total system to be used for interactive work.

yEven though the total interactive capacity of the system has not changed, the faster processors (and likely larger memory and faster disks) will allow interactive requests to complete more rapidly, which can cause greater spikes of interactive demand.

ySo, just as it is important to consider balancing memory and disk upgrades with processor upgrades, optimal performance may also require an interactive capacity upgrade when moving to a new system.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

34

2.13 iSeries for Domino and Dedicated Server for Domino Performance Behavior

In preparation for future Domino releases which will provides support for DB2 files, the previous processing limitations associated with DSD models have been removed in i5/OS V5R3.

In addition, a PTF is available for V5R2 which also removes the processing limitations for DSD models and allows full use of DB2. Please refer to PTF MF32968 and its prerequisite requirements.

The sections below from previous versions of this document are provided for those users on OS/400 releases prior to V5R3.

2.13.1 V5R2 iSeries for Domino & DSD Performance Behavior updates

Included in the V5R2 February 2003 iSeries models are five iSeries for Domino offerings. These include three i810 and two i825 models. The iSeries for Domino offerings are specially priced and configured for Domino workloads. There are no processing guidelines for the iSeries for Domino offerings as with non-Domino processing on the Dedicated Server for Domino models. With the iSeries for Domino offerings the full amount of DB2 processing is available, and it is no longer necessary to have Domino processing active for non-Domino applications to run well. Please refer to Chapter 11 for additional information on Domino performance in iSeries, and Appendix C for information on performance specifications for iSeries servers.

For existing iSeries servers, OS/400 V5R2 (both the June 2002 and the updated February 2003 version) will exhibit similar performance behavior as V5R1 on the Dedicated Server for Domino models. The following discussion of the V5R1 Domino-complimentary behavior is applicable to V5R2.

Five new DSD models were announced with V5R1. These included the iSeries Model 270 with a 1-way and a 2-way feature, and the iSeries Model 820 with 1-way, 2-way, and 4-way features. In addition, OS/400 V5R1 was enhanced to bolster DSD server capacity for robust Domino applications that require Java Servlet and WebSphere Application Server integration. The new behavior which supports Domino-complementary workloads on the DSD was available after September 28, 2001 with a refreshed version of OS/400 V5R1. This enhanced behavior is applicable to all DSD models including the model 170 and previous 270 and 820 models. Additional information on Lotus Domino for iSeries can be found in Chapter 11, “Domino for iSeries”.

For information on the performance behavior of DSD models for releases prior to V5R1, please refer the to V4R5 version of this document.

Please refer to Appendix C for performance specifications for DSD models, including the number of Mail and Calendaring Users (MCU) supported.

2.13.2 V5R1 DSD Performance Behavior

This section describes the performance behavior for all DSD models for the refreshed version of OS/400 V5R1 that was available after September 28, 2001.

A white paper, Enhanced V5R1 Processing Capability for the iSeries Dedicated Server for Domino, provides additional information on DSD behavior and can be accessed at: http://www.ibm.com/eserver/iseries/domino/pdf/dsdjavav5r1.pdf .

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

35

Domino-Complementary Processing

Prior to V5R1, processing that did not spend the majority of its time in Domino code was considered non-Domino processing and was limited to approximately 10-15% of the system capacity. With V5R1, many applications that would previously have been treated as non-Domino may now be considered as Domino-complementary when they are used in conjunction with Domino. Domino-complementary processing is treated the same as Domino processing, provided it also meets the criteria that the DB2 processing is less than 15% CPU utilization as described below. This behavioral change has been made to support the evolving complexity of Domino applications which frequently require integration with function such as Java Servlets and WebSphere Application Server. The DSD models will continue to have a zero interactive CPW rating which allows sufficient capacity for systems management processing. Please see the section below on Interactive Processing.

In other words, non-Domino workloads are considered complementary when used simultaneously with Domino, provided they meet the DB2 processing criteria. With V5R1, the amount of DB2 processing on a DSD must be less than 15% CPU. The DB2 utilization is tracked on a system-wide basis and all applications on the DSD cumulatively should not exceed 15% CPU utilization. Should the 15% DB2 processing level be reached, the jobs and/or threads that are currently accessing DB2 resources may experience increased response times. Other processing will not be impacted.

Several techniques can used to determine and monitor the amount of DB2 processing on DSD (and non-DSD) iSeries servers for V4R5 and V5R1.

yWork with System Status (WRKSYSSTS) command, via the % DB capability statistic

yWork with System Activity (WRKSYSACT) command which is part of the IBM Performance Tools for iSeries, via the Overall DB CPU util statistic

yManagement Central - by starting a monitor to collect the CPU Utilization (Database Capability) metric

yWorkload section in the System Report which can be generated using the IBM Performance Tools for iSeries, via the Total CPU Utilization (Database Capability) statistic

V5R1 Non-Domino Processing

Since all non-interactive processing is considered Domino-complementary when used simultaneously with Domino, provided it meets the DB2 criteria, non-Domino processing with V5R1 refers to the processing that is present on the system when there is no Domino processing present. (Interactive processing is a special case and is described in a separate section below). When there is no Domino processing present, all processing, including DB2 access, should be less than 10-15% of the system capacity. When the non-Domino processing capacity is reached, users may experience increased response times. In addition, CFINT processing may be present as the system attempts to manage the non-Domino processing to the available capacity. The announced “Processor CPW” for the DSD models refers to the amount of non-Domino processing that is supported .

Non-Domino processing on the 270 and 820 DSD models can be tracked using the Management Central function of Operations Navigator. Starting with V4R5, Management Central provides a special metric called “secondary utilization” which shows the amount of non-Domino processing. Even when Domino processing is present, the secondary utilization metric will include the Domino-complementary processing. And , as discussed above, the Domino-complementary processing running in conjunction with Domino will not be limited unless it exceeds the DB2 criteria.

Interactive Processing

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

36

Similar to previous DSD performance behavior for interactive processing, the Interactive CPW rating of 0 allows for system administrative functions to be performed by a single interactive user. In practice, a single interactive user will be able to perform necessary administrative functions without constraint. If multiple interactive users are simultaneously active on the DSD, the Interactive CPW capacity will likely be exceeded and the response times of those users may significantly lengthen. Even though the Interactive CPW capacity may be temporarily exceeded and the interactive users experience increased response times, other processing on the system will not be impacted. Interactive processing on the 270 and 820 DSD models can be tracked using the Management Central function of Operations Navigator.

Logical Partitioning on a Dedicated Server

With V5R1, iSeries logical partitioning is supported on both the Model 270 and Model 820. Just to be clear, iSeries logical partitioning is different from running multiple Domino partitions (servers). It is not necessary to use iSeries logical partitioning in order to be able to run multiple Domino servers on an iSeries system. iSeries logical partitioning lets you run multiple independent servers, each with its own processor, memory, and disk resources within a single symmetric multiprocessing iSeries. It also provides special capabilities such as having multiple versions of OS/400, multiple versions of Domino, different system names, languages, and time zone settings. For additional information on logical partitioning on the iSeries please refer to Chapter 18. Logical Partitioning (LPAR) and LPAR web at: http://www.ibm.com/eserver/iseries/lpar .

When you use logical partitioning with a Dedicated Server, the DSD CPU processing guidelines are pro-rated for each logical partition based on how you divide up the CPU capability. For example, suppose you use iSeries logical partitioning to create two logical partitions, and specify that each logical partition should receive 50% of the CPU resource. From a DSD perspective, each logical partition runs independently from the other, so you will need to have Domino-based processing in each logical partition in order for non-Domino work to be treated as complementary processing. Other DSD processing requirements such as the 15% DB2 processing guidelines and the 15% non-Domino processing guideline will be divided between the logical partitions based on how the CPU was allocated to the logical partitions. In our example above with 50% of the CPU in each logical partition, the DB2 database guideline will be 7.5% CPU for each logical partition. Keep in mind that WRKSYSSTS and other tools show utilization only for the logical partition they are running in; so in our example of a partition that has been allocated 50% of the processor resource, a 7.5% system-wide load will be shown as 15% within that logical partition. The non-Domino processing guideline would be divided in a similar manner as the DB2 database guideline.

Running Linux on a Dedicated Server

As with other iSeries servers, to run Linux on a DSD it is necessary to use logical partitioning. Because Linux is it’s own unique operating environment and is not part of OS/400, Linux needs to have its own logical partition of system resources, separate from OS/400. The iSeries Hypervisor allows each partition to operate independently. When using logical partitioning on iSeries, the first logical partition, the primary partition, must be configured to run OS/400. For more information on running Linux on iSeries, please refer to Chapter 13. iSeries Linux Performance and Linux for iSeries web site at: Http://www.ibm.com/eserver/iseries/linux .

Running Linux in a DSD logical partition will exhibit different performance characteristics than running OS/400 in a DSD logical partition. As described in the section above, when running OS/400 in a DSD logical partition, the DSD capacities such as the 15% DB2 processing guideline and the 15% non-Domino processing guidelines are divided proportionately between the logical partitions based on how the processor resources were allocated to the logical partitions. However, for Linux logical partitions, the DSD guidelines are relaxed, and the Linux logical partition is able to use all of the resources allocated to it outside the normal guidelines for DSD processing. This means that it is not necessary to have Domino

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

37

processing present in the Linux logical partition, and all resources allocated to the Linux logical partition can essentially be used as though it were complementary processing. It is not necessary to proportionally increase the amount of Domino processing in the OS/400 logical partition to account for the fact that Domino processing is not present in the Linux logical partition .

By providing support for running Linux logical partitions on the Dedicated Server, it allows customers to run Linux-based applications, such as internet fire walls, to further enhance their Domino processing environment on iSeries. At the time of this publication, there is not a version of Domino that is supported for Linux logical partitions on iSeries.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 2 - Server Performance Behavior

38

Chapter 3. Batch Performance

In a commercial environment, batch workloads tend to be I/O intensive rather than CPU intensive. The factors that affect batch throughput for a given batch application include the following:

yMemory (Pool size)

yCPU (processor speed)

yDASD (number and type)

ySystem tuning parameters

Batch Workload Description

The Batch Commercial Mix is a synthetic batch workload designed to represent multiple types of batch processing often associated with commercial data processing. The different variations allow testing of sequential vs random file access, changing the read to write ratio, generating "hot spots" in the data and running with expert cache on or off. It can also represent some jobs that run concurrently with interactive work where the work is submitted to batch because of a requirement for a large amount of disk I/O.

3.1 Effect of CPU Speed on Batch

The capacity available from the CPU affects the run time of batch applications. More capacity can be provided by either a CPU with a higher CPW value, or by having other contending applications on the same system consuming less CPU.

Conclusions/Recommendations

yFor CPU-intensive batch applications, run time scales inversely with Relative Performance Rating (CPWs). This assumes that the number synchronous disk I/Os are only a small factor.

yFor I/O-intensive batch applications, run time may not decrease with a faster CPU. This is because I/O subsystem time would make up the majority of the total run time.

yIt is recommended that capacity planning for batch be done with tools that are available for iSeries. For example, PATROL for iSeries - Predict from BMC Software, Inc. * (PID# 5620FIF) can be used for modeling batch growth and throughput. BATCH400 (an IBM internal tool) can be used for estimating batch run-time.

3.2 Effect of DASD Type on Batch

For batch applications that are I/O-intensive, the overall batch performance is very dependent on the speed of the I/O subsystem. Depending on the application characteristics, batch performance (run time) will be improved by having DASD that has:

yfaster average service times

yread ahead buffers

ywrite caches

Additional information on DASD devices in a batch environment can be found in Chapter 14, “DASD Performance”.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 3 - Batch Performance

39

3.3 Tuning Parameters for Batch

There are several system parameters that affect batch performance. The magnitude of the effect for each of them depends on the specific application and overall system characteristics. Some general information is provided here.

yExpert Cache

Expert Cache did not have a significant effect on the Commercial Mix batch workload. Expert Cache does not start to provide improvement unless the following are true for a given workload. These include:

y the application that is running is disk intensive, and disk I/O's are limiting the throughput. y the processor is under-utilized, at less than 60%.

y the system must have sufficient main storage.

For Expert Cache to operate effectively, there must be spare CPU, so that when the average disk access time is reduced by caching in main storage, the CPU can process more work. In the Commercial Mix benchmark, the CPU was the limiting factor.

However, specific batch environments that are DASD I/O intensive, and process data sequentially may realize significant performance gains by taking advantage of larger memory sizes available on the RISC models, particularly at the high-end. Even though in general applications require more main storage on the RISC models, batch applications that process data sequentially may only require slightly more main storage on RISC. Therefore, with larger memory sizes in conjunction with using Expert Cache, these applications may achieve significant performance gains by decreasing the number of DASD I/O operations.

yJob Priority

Batch jobs can be given a priority value that will affect how much CPU processing time the job will get. For a system with high CPU utilization and a batch job with a low job priority, the batch throughput may be severely limited. Likewise, if the batch job has a high priority, the batch throughput may be high at the expense of interactive job performance.

yDynamic Priority Scheduling

See 19.2, “Dynamic Priority Scheduling” for details.

yApplication Techniques

The batch application can also be tuned for optimized performance. Some suggestions include:

y Breaking the application into pieces and having multiple batch threads (jobs) operate concurrently. Since batch jobs are typically serialized by I/O, this will decrease the overall required batch window requirements.

y Reduce the number of opens/closes, I/Os, etc. where possible.

yIf you have a considerable amount of main storage available, consider using the Set Object Access (SETOBJACC) command. This command pre-loads the complete database file, database index, or program into the assigned main storage pool if sufficient storage is available . The objective is to

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 3 - Batch Performance

40

improve performance by eliminating disk I/O operations.

yIf communications lines are involved in the batch application, try to limit the number of communications I/Os by doing fewer (and perhaps larger) larger application sends and receives. Consider blocking data in the application. Try to place the application on the same system as the frequently accessed data.

*BMC Software, the BMC Software logos and all other BMC Software products including PATROL for iSeries - Predict are registered trademarks or trademarks of BMC Software, Inc.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

 

© Copyright IBM Corp. 2008

Chapter 3 - Batch Performance

41

Chapter 4. DB2 for i5/OS Performance

This chapter provides a summary of the new performance features of DB2 for i5/OS on V6R1, V5R4 and V5R3, along with V5R2 highlights. Summaries of selected key topics on the performance of DB2 for i5/OS are provided. General information and some recommendations for improving performance are included along with links to the latest information on these topics. Also included is a section of performance references for DB2 for i5/OS.

4.1 New for i5/OS V6R1

In i5/OS V6R1 there are several performance enhancements to DB2 for i5/OS. The evolution of the SQL Query Engine (SQE), with this release, again supports more queries. Some of the new function supported may also have a sizable effect on performance, including derived key indexes, decimal floating-point data type, and select from insert. Lastly, modifications specifically to improve performance were made in several key areas, including optimization improvements to produce more efficient access plans, reducing full open and optimization time, and path length reduction of some basic, high use paths.

i5/OS V6R1 SQE Query Coverage

The query dispatcher controls whether an SQL query will be routed to SQE or to the Classic Query Engine (CQE). SQL queries with the following attributes, which were routed to CQE in previous releases, may now be routed to SQE in i5/OS V6R1:

yNLSS/CCSID translation between columns

yUser-defined table functions

ySort sequence

yLateral correlation

yUPPER/LOWER functions

yUTF8/16 Normalization support (NORMALIZE_DATA INI option of *YES)

yLIKE with UTF8/UTF16 data

yCharacter based substring and length for UTF8/UTF16 data

Also, in V6R1, the default value for the QAQQINI option IGNORE_DERIVED_INDEX has changed from *NO to *YES. The default behavior will now be to run supported queries through SQE even if there is a select/omit logical file index created over any of the tables in the query. In V6R1 many types of derived indexes are now supported by the SQE optimizer and usage of the QAQQINI option IGNORE_DERIVED_INDEX only applies to select/omit logical file indexes.

SQL queries with the attributes listed above will be processed by the SQE optimizer and engine in V6R1. Due to the robust SQE optimizer potentially choosing a better plan along with the more efficient query engine processing, there is the potential for better performance with these queries than was experienced in previous releases.

SQL queries which continue to be routed to CQE in i5/OS V6R1 have the following attributes:

yINSERT WITH VALUES statement or the target of an INSERT with subselect statement

yLogical files referenced in the FROM clause

yTables with Read Triggers

yRead-only queries with more than 1000 dataspaces or updateable queries with more than 256 dataspaces.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

42

yDB2 Multisystem tables

New function available in V6R1 whose use may affect SQL performance are derived key indexes, decimal floating point data type support, and the select from insert statement. A derived key index can have an expression in place of a column name that can use built-in functions, user defined functions, or some other valid expression. Additionally, you can use the SQL CREATE INDEX statement to create a sparse index using a WHERE condition.

The decimal floating-point data type has been implemented in V6R1. A decimal floating-point number is an IEEE 754R number with a decimal point. The position of the decimal point is stored in each decimal floating-point value. The maximum precision is 34 digits. The range of a decimal floating-point number is either 16 or 34 digits of precision, and an exponent range of 10-383 to 10384 or 10-6143 to 106144 respectively. Use of the new decimal floating-point data type depends on whether you desire the new functionality. In general, more CPU is used to process data of this type versus decimal or floating-point data. The increased amount of processing time needed depends on the processor technology being used. Power6 hardware has special hardware support for processing decimal floating-point data, while Power5 does not. Power6 hardware enables much better performance for decimal floating-point processing. The CPU used to process this data depends on other factors also, including the application code, the functions used, and the data itself. As an example, for a specific set of queries run over a particular database, ranges for increased processing time for decimal floating-point data versus either decimal or floating point are shown in the chart below in Figure 4.1. The query attribute column shows the type of operations over the decimal floating-point columns in the queries.

Query Attribute

POWER5 Processor

POWER6 Processor

Select

0% to 15%

0% to 15%

Arithmetic ( +, -, *, / )

15% improved to 400%

35% improved to 45%

Functions ( AVG, MAX, MIN, SUM, CHAR, TRUN)

15% improved to 1200%

35% improved to 300%

Casts ( to/from int, decimal, float)

40% improved to 600%

35% improved to 500%

Inserts, Updates, and Create Index

0% to 20%

0% to 35%

Figure 4.1 Processing time degradation with decimal floating-point data versus decimal or float

Given the additional processing time needed for decimal floating-point data, the recommendation is to use this data type only when the increased precision and rounding capabilities are needed. It is also recommended to avoid conversions to and from this data type, when possible. It should not normally be necessary to migrate existing packed or zoned decimal fields within a mature data base file to the new decimal floating point data type. Any decimal fields in the file will be converted to decimal float in host variables, as provided by the languages and APIs chosen. That will, in many cases, be a better performer overall (especially including existing code considerations) than a migration of the data field to a new format.

The ability to insert records into a table and then select from those inserted records in one statement, called Select From Insert, has been added to V6R1. Using a single SQL statement to insert and then retrieve the records can perform much better than doing an insert followed by a select statement. The chart below in figure 4.2 shows an example of the performance of a basic select from insert compared to the insert followed by select when inserting/selecting various number of records, from 1 to 1000. The data is for a particular database and SQL queries, and one specific hardware and software configuration running V6R1 i5/OS. The ratio of the clock times for these operations is shown. A ratio of less than 1 indicates that the select from insert ran faster than the insert followed by a select. Select from insert using NEW TABLE performs better than insert then select for all quantities of rows inserted. Select from insert using FINAL TABLE performs better in the one row case, but takes longer with more rows. This is due to the additional locking needed with FINAL TABLE to insure the rows are not modified until

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

43

the statement is complete. The implementation to invoke the locking causes a physical DASD write to the journal for each record, which causes journal waits. Journal caching on allows the journal writes to accumulate in memory and have one DASD write per multiple journal entries, greatly reducing the journal wait time. So select from insert statements with FINAL TABLE run much faster with journal caching on. Figure 4.2 shows that select from insert with FINAL TABLE and journal caching on ran faster than the insert followed by select for all but the 1000 row insert size.

 

Select

6.00

 

 

 

 

5.00

 

 

 

 

 

 

 

 

Clock Time Ratio

from Insert / Insert then

4.00

 

 

 

3.00

 

 

 

2.00

 

 

 

1.00

 

 

 

 

Select

 

 

 

 

0.00

 

 

 

 

 

1

10

100

1000

Records Inserted/Selected

Select from Insert: Final Table

Select from Insert: Final Table Journal caching on

Select from Insert: New Table

Select from Insert: New Table Journal caching on

Figure 4.2 Select from Insert versus Insert followed by Select clock time ratios

In addition to updates for new functionality, in V6R1 substantial performance improvements were made to some SQL code paths. Improvements were made to the optimizer to make query execution cost estimates more accurate. This means that the optimizer is producing more efficient access plans for some queries, which may reduce their run time. The time required to full open and optimize queries was also largely reduced for many queries in V6R1. On average, for a group of greatly varying queries, the total open time including optimization has been reduced 45%. For a given set of very simple queries which go through a full open, but whose access plan already exists in the plan cache, the full open time was reduced by up to 30%.

In addition to the optimization and full open performance improvements, for V6R1 there was a comprehensive effort to reduce the basic path of a simple query which is running in re-use mode (pseudo open), and in particular is using JDBC to access the database. The results of this are potentially large reductions in the CPU time used in processing queries, particularly very simple queries. For a stock trade workload running through JDBC, throughput improvements of up to 78% have been measured. For more information please see Chapter 6. Web Server and WebSphere Performance.

4.2 DB2 i5/OS V5R4 Highlights

In i5/OS V5R4 there were several performance enhancements to DB2 for i5/OS. With support in SQE for Like/Substring, LOBs and the use of temporary indexes, many more queries now go down the SQE path. Thus there is the potential for better performance due to the robust SQE optimizer choosing a better plan along with the more efficient query engine processing. Also supported is use of Recursive Common

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

44

Table Expressions (RCTE) which allow for more elegant and better performing implementations of recursive processing. In addition, enhancements have been made in i5/OS V5R4 to the support for materialize query tables (MQTs) and partitioned table processing, which were both new in i5/OS V5R3.

i5/OS V5R4 SQE Query Coverage

The query dispatcher controls whether an SQL query will be routed to SQE or to CQE. SQL queries with the following attributes, which were routed to CQE in previous releases, may now be routed to SQE in i5/OS V5R4:

y

Sensitive cursor

y

LOB columns

y

Like/Substring predicates

y

ALWCPYDTA(*NO)

SQL queries which continue to be routed to CQE in i5/OS V5R4 have the following attributes:

y

References to DDS logical files

y

DB2 Multisystem

y

NLSS/CCSID translation between columns

y

Tables with select/omit logicals over them

yUser-defined table unctions

In general, queries with Like and Substring predicates which are newly routed to SQE see substantial performance improvements in i5/OS V5R4. For a group of widely varying queries and data, including a wide range of Like and Substring predicates and various file sizes, a large percentage of the queries saw up to a 10X reduction in query run time. Queries with references to LOB columns, which were newly routed to SQE,, in general, also experience substantial performance improvements in i5/OS V5R4. For a set of queries which have references to LOB columns, in which the queries and data vary greatly a large percentage ran up to a 5X faster. .

A new addition to SQE is the creation and use of temporary indexes. These indexes will be created because they are required for implementing certain types of query requests or because they allow for better performance. The implementation of queries which require live data may require temporary indexes, for example, queries that run with a sensitive cursor or with ALWCPYDTA(*NO). In the case of using a temporary index for better performance, the SQE optimizer costs the creation and use of temporary indexes during plan optimization. An access plan will choose a temporary index if the amortized cost of building the index, provided one does not exist, reduces the query run time of the access plan enough that this plan wins over other plan options. The temporary indexes that the optimizer considers building are the same indexes in the ‘index advised’ list for a given query. Features unique to SQE temporary indexes, compared to CQE temporary indexes, are the longer lifetimes and higher degree of sharing of these indexes. SQE temporary indexes may be reused by the same query or other queries in the same job or in other jobs. The SQE temporary indexes will persist and will be maintained until the last query which references the temporary index is hard closed and the plan is removed from the plan cache. In many cases, this means the temporary indexes will persist until the last job which was using the index is ended. The high degree of sharing and longer lifetime allow for more reuse of the indexes without repeated create index cost.

New function for implementing applications that work with recursive data has been added to i5/OS V5R4. Recursive Common Table Expressions (RCTE) and Recursive Views may now be used in these types of applications, versus using SQL Stored Procedures and temporary results tables. For more information on using RCTEs and Recursive Views see the DB2 for System i Database Performance and Query Optimization manual.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

45

Enhancements to extend the use of materialized query tables (MQTs) were added in i5/OS V5R4. New supported function in MQT queries by the MQT matching algorithm are unions and partitioned tables, along with limited support for scalar subselects, UDFs and user defined table functions, RCTE, and some scalar functions. Also new to i5/OS V5R4, the MQT matching algorithm now tries to match constants in the MQT with parameter markers or host variable values in the query. For more information on using MQTs see the DB2 for System i Database Performance and Query Optimization manual and the white paper, The creation and use of materialized query tables within IBM DB2 FOR i5/OS, available at http://www-304.ibm.com/jct09002c/partnerworld/wps/servlet/ContentHandler/SROY-6UZ5E6

The performance of queries which reference partitioned tables has been enhanced in i5/OS V5R4. The overhead when optimizing queries which reference a partitioned table has been reduced. Additionally, general improvements in plan quality have yielded run time improvements as well.

4.3 i5/OS V5R3 Highlights

In i5/OS V5R3, the SQL Query Engine (SQE) roll-out in DB2 for i5/OS took the next step. The new SQL Query Optimizer, SQL Query Engine and SQL Database Statistics were introduced in V5R2 with a limited set of queries being routed to SQE. In i5/OS V5R3 many more SQL queries are implemented in SQE. In addition, many performance enhancements were made to SQE in i5/OS V5R3 to decrease query runtime and to use System i resources more efficiently. Additional significant new features in this release are: table partitioning, the lookahead predicate generation (LPG) optimization technique for enhanced star-join support and a technology preview of materialized query tables. Also an April 2005 addition to the DB2 FOR i5/OS V5R3 support was query optimizer support for recognizing and using materialized query tables (MQTs) (also referred to as automatic summary tables or materialized views) for limited query functions. Two other improvements worth mentioning are faster delete support and SQE constraint awareness. This section contains a summary of the V5R3 information in the System i Performance Capabilities Reference i5/OS Version 5 Release 3 available at http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzahx/sc410607.pdf.

i5/OS V5R3 SQE Query Coverage

The query dispatcher controls whether an SQL query will be routed to SQE or to CQE (Classic Query Engine). The staged implementation of SQE enabled a very limited set of queries to be routed to SQE in V5R2. In general, read only single table queries with a limited set of attributes would be routed to SQE. The details of the query attributes for routing to SQE versus CQE in V5R2 are documented in the V5R2 redbook Preparing for and Tuning the V5R2 SQL Query Engine. With the V5R2 enabling PTF applied, PTF SI07650 documented in Info APAR II13486, the dispatcher routes many more queries through SQE. More single table queries and a limited set of multi-table queries are able to take advantage of the SQE enhancements. Queries with OR and IN predicates may be routed to SQE with the enabling PTF as will SQL queries with the appropriate attributes on systems with SMP enabled.

In i5/OS V5R3 a much larger set of queries are implemented in SQE including those with the enabling PTF on V5R2 and many queries with the following types of attributes:

y

Subqueries

y

Unions

y

Views

y

Updates

y

Common table expressions

y

Deletes

yDerived tables

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

46

SQL queries which continue to be routed to CQE in i5/OS V5R3 have the following attributes:

y

Sensitive cursor

y NLSS/CCSID translation between columns

y

Like/Substring predicates

y

DB2 Multisystem

y

LOB columns

y

ALWCPYDTA(*NO)

y References to DDS logical files

y Tables with select/omit logicals over them

i5/OS V5R3 SQE Performance Enhancements

Many enhancements were made in i5/OS V5R3 to enable faster query runtime and use less system resource. Highlights of these enhancements include the following:

yNew optimization techniques including Lookahead Predication Generation and Constraint Awareness

ySharing of temporary result sets across jobs

yReduction in size of temporary result sets

yMore efficient I/O for temporary result sets

yAbility to do some aggregates with EVI symbol table access only

yReduction in memory used during optimization

yReduction in DB structure memory usage

yMore efficient statistics generation during optimization

yGreater accuracy of statistics usage for optimization plan generation

The DB2 performance enhancements in i5/OS V5R3 substantially reduced the runtime of many queries. Performance improvements vary substantially due to many factors -- file size and layout, indexes and statistics available -- making generalization of performance expectations for a given query difficult. However, longer running queries which are newly routed to SQE in i5/OS V5R3, in general, have a greater likelihood of significant performance benefit.

For the short running queries, those that run less than 2 seconds, performance improvements are nominal. For subsecond queries there is little to no improvement for most queries. As the runtime increases, the reduction in runtime and CPU time become more substantial. In general, for short running queries there is less opportunity for improving performance. Also, the first execution of all the queries in these figures was measured so that a database open and full optimization were required. Database open and full optimization overhead may be higher with SQE, as it evaluates more information and examines more potential query implementation plans. As this overhead is much more expensive relative to actual query implementation for short running queries, performance benefits from SQE for the short running queries are minimized. However, in OLTP environments the plan caching and open data path (ODP) reuse design minimizes the number of opens and full optimizations needed. A very small percentage of queries in typical customer OLTP workloads go through full open and optimization.

The performance benefits are substantial for many of the medium to long running queries newly routed to SQE in i5/OS V5R3. Typically, the longer the runtime, the more potential for improvements. This is due to the optimizer constructing a more efficient access plan and the faster execution of the access plan with the SQE query engine. Many of the queries with runtimes greater than 2 seconds, especially those with runtimes greater than 10 seconds, reduced their runtime by a factor of 2 or more. Queries which run longer than 200 seconds were typically improved from 15% to over 100 times.

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

47

Partitioned Table Support

Table partitioning is a new feature introduced in i5/OS V5R3. The design is localized on an individual table basis rather than an entire library. The user specifies one or more fields which collectively act as a partitioning key. Next the records in the table are distributed into multiple disjoint sets based on the partitioning scheme used: either a system-supplied hashing function or a set of value ranges (such as dates by month or year) supplied by the user. The user can partition data using up to 256 partitions in i5/OS V5R3. The partitions are stored as multiple members associated with the same file object, which continues to represent the overall table as a single entity from an SQL data-access viewpoint.

The primary motivations for the initial release of this feature are twofold:

yEliminate the limitation of at most 4 billion (2^32) rows in a single table

yEnhance data administration tasks such as save/restore, import/export, and add/drop which can be done more quickly on a partition basis (subset of a table)

In theory, table partitioning also offers opportunities for performance gains on queries that specify selection referencing a single or small number of partitions. In reality, however, the performance impact of partitioned tables in this initial release are limited on the positive side and may instead result in performance degradation when adopted too eagerly without carefully considering the ramifications of such a change. The resulting performance after partitioning a table depends critically on the mix of queries used to access the table and the number of partitions created. If fields used as partitioning keys are frequently included in selection criteria the resulting performance can be much better due to improved locality of reference for the desired records. When used incorrectly, table partitioning may degrade the performance of queries by an order of magnitude or more -- particularly when a large number of partitions (>32) are created.

Performance expectations of table partitioning on i5/OS V5R3 should not be equated at this time with partitioning concepts on other database platforms such as DB2 for Linux, Unix and Windows or offerings from other competitors. Nor should table partitioning on V5R3 be confused with the DB2 Multisystem for i5/OS offering. Carefully planned data storage schemes with active end-user disk arm management lead to the performance gains experienced with partitioned databases on those other platforms. Further gains are realized in other approaches through execution on clusters of physical nodes (in an approach similar to DB2 Multisystem for i5/OS). In addition, the entire schema is involved in the partitioning approach. On the other hand, the System i table partitioning design continues to utilize single level storage which already automatically spreads data to all disks in the relevant ASP. No new performance gains from I/O balancing are achieved when partitioning a table. Instead the gains tend to involve improved locality of reference for a subset of the data contained in a single partition or ease of administration when adding or deleting data on partition boundaries.

An in-depth discussion of table partitioning for i5/OS V5R3 is available in the white paper Table Partitioning Strategies for DB2 FOR i5/OS available at http://www.ibm.com/servers/eserver/iseries/db2/awp.html

This publication covers additional details such as:

yMigration strategies for deployment

yRequirements and Limitations

ySample Environments (OLTP, OLAP, Limits to Growth, etc.) & Recommended Settings

yIndexing Strategies

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

48

yStatistical Strategies

ySMP Considerations

yAdministration Examples (Adding a Partition, Dropping a Partition, etc.)

Materialized Query Table Support

The initial release of i5/OS V5R3 includes the Materialized Query Table (MQT) (also referred to as automatic summary tables or materialized views) support in UDB DB2 for i5/OS as essentially a technology preview. Pre-April 2005 i5/OS V5R3 provides the capability of creating materialized query tables, but no optimizer awareness of these MQTs. An April 2005 addition to DB2 for i5/OS V5R3 is query optimizer support for recognizing and using MQTs. This additional support for recognizing and using MQTs is limited to certain query functions. MQTs can provide performance enhancements in a manner similar to indexes. This is done by precomputing and storing results of a query in the materialized query table. The database engine can use these results instead of recomputing them for a user specified query. The query optimizer will look for any applicable MQTs and can choose to implement the query using a given MQT provided this is a faster implementation choice. For long running queries, the run time may be substantially improved with judicious use of MQTs. For more information on MQTs including how to enable this new support, for which queries support MQTs and how to create and use MQTs see the DB2 for System i Database Performance and Query Optimization manual. For the latest information on MQTs see http://www-1.ibm.com/servers/eserver/iseries/db2/mqt.html.

Fast Delete Support

As developers have moved from native I/O to embedded SQL, they often wonder why a Clear Physical File Member (ClrPfm) command is faster than the SQL equivalent of DELETE FROM table. The reason is that the SQL DELETE statement deletes a single row at a time. In i5/OS V5R3, DB2 for System i has been enhanced with new techniques to speed up processing when every row in the table is deleted. If the DELETE statement is not run under commitment control, then DB2 for System i will actually use the ClrPfm operation underneath the covers. If the Delete is performed with commitment control, then DB2 FOR i5/OS can use a new method that’s faster than the old delete one row at a time approach. Note however that not all DELETEs will use the new faster support. For example, delete triggers are still processed the old way.

4.4 V5R2 Highlights - Introduction of the SQL Query Engine

In V5R2 major enhancements, entitled SQL Query Engine (SQE), were implemented in DB2 for i5/OS. SQE encompasses changes made in the following areas:

ySQL query optimizer

ySQL query engine

yDatabase statistics

A subset of the read-only SQL queries are able to take advantage of these enhancements in V5R2.

SQE Optimizer

The SQL query optimizer has been enhanced with new optimization capabilities implemented in object oriented technology. This object oriented framework implements new optimization techniques and allows for future extendibility of the optimizer. Among the new capabilities of the optimizer are enhanced query access plan costing. For queries which can take advantage of the SQE enhancements,

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

49

more information may be used in the query plan costing phase than was available to the optimizer previously. The optimizer may now use newly implemented database statistics to make more accurate decisions when choosing the query access plan. Also, the enhanced optimizer may more often select plans using hash tables and sorted partial result lists to hold partial query results during query processing, rather than selecting access plans which build temporary indexes. With less reliance on temporary indexes the SQE optimizer is able to select more efficient plans which save the overhead of building temporary indexes and more fully take advantage of single-level store. The optimizer changes were designed to create efficient query access plans for the enhanced database engine.

SQE Query Engine

The database engine is the part of the database implementation which executes the access plan produced by the query optimizer. It accesses the data, processes it, and returns the SQL query results. The new engine enhancements, the SQE database engine, employ state of the art object oriented implementation. The SQE database engine was developed in tandem with the SQE optimization enhancements to allow for an efficient design which is readily extendable. Efficient new algorithms for the data access methods are used in query processing by the SQE engine.

The basic data access algorithms in SQE are designed to take full advantage of the System i single-level store to give the fastest query response time. The algorithms reduce I/O wait time by making use of available main memory and aggressively reading data from disk into memory. The goal of the data read-ahead algorithms is that the data is in memory when it is needed. This is done through the use of asynchronous I/Os. SQL queries which access large amounts of data may see a considerable improvement in the query runtime. This may also result in higher peak disk utilization.

The effects of the SQE enhancements on SQL query performance will vary greatly depending on many factors. Among these factors are hardware configuration (processor, memory size, DASD configuration...), system value settings, file layout, indexes available, query options file QAQQINI settings, and the SQL queries being run.

SQE Database Statistics

The third area of SQE enhancements is the collection and use of new database statistics. Efficient processing of database queries depends primarily on a query optimizer that is able to make judicious choices of access plans. The ability of an optimizer to make a good decision is critically influenced by the availability of database statistics on tables referenced in queries. In the past such statistics were automatically gathered during optimization time for columns of tables over which indexes exist. With SQE statistics on columns without indexes can now be gathered and will be used during optimization. Column statistics comprise histograms, frequent values list, and column cardinality.

With System i servers, the database statistics collection process is handled automatically, while on many platforms statistics collection is a manual process that is the responsibility of the database administrator. It is rarely necessary for the statistics to be manually updated, even though it is possible to manage statistics manually. The Statistics Manager determines on what columns statistics are needed, when the statistics collection should be run and when the statistics need to be refreshed. Statistics are automatically collected as low priority work in the background, so as to minimize the impact to other work on the system. The manual collection of statistics is run with the normal user job priority.

The system automatically determines what columns to collect statistics on based on what queries have run on the system. Therefore for queries which have slower than expected performance results, a check

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008

Chapter 4 - DB2 Performance

 

50

+ 318 hidden pages