iSeries tweaks for better OneWorld performance
So you know, there is really no silver-bullet to improving performance for OneWorld. There are many tweaks that need to be made. So are controllable on the iSeries and Deployment side, and some are on the network side.
TCP/IP - iSeries
Double-check with your network admins before making any of these changes to assure that your network can handle this and that you will not have any conflicts
MTU (Maximum Transmission Unit):
Under the Routing Entry Information (CHGRCPRTE) there is a setting for the MTU, this should be set to *IFC so the max bandwidth can be used.
Buffer Size
The TCP Attributes has a buffer size, this should be set to 64k (65536) for both the send and receive.
DNS Names:
Make sure that your Deployment Servers DNS name is in the Host Table. The iSeries will look there first, before accessing your network DNS system. This will shave off a few milliseconds on any query return.
Memory
Put the QUSRWRK in its own share-pool – OneWorld INIT jobs will consume as much memory as you give it.
Rule of thumb for the Citrix side is that a users job will take on average 100 Mb of memory per session (if BSFN’s run on the MetaFrame server – you PD environment, not the WPD environment).
On the server side, they will consume as much as they need to fulfill the job. We had 290 concurrent users (and about 30 other web users) coming in through QUSRWRK, and took 20 Gb of memory. Rule of thumb for consumption of OneWorld users on the iSeries (Xe statistic) is 15Mb allocated in the memory pool of the QSERVER sbs for every OneWorld user.
If you do not put them in a share pool of their own, they will take memory from *BASE which is used for all batch jobs and app jobs – this will effect everything (besides the OS which runs in *MACHINE and printers which run in *SPOOL).
An average UBE will take about 150-200Mb of memory to run. This really depends upon the UBE running, but for your average user, this is reasonable.
Grid
In Xe you can choose between painting the grid all-at-once or page-at-a-time. Using Page-at-a-time is much faster initial results for the user and easier on the INIT job, but if they need to go to the end of the output, it will take longer than all-at-once.
This has been changed in E810 (pre update I1) to go back to all-at-once. A step back in my opinion, and they are planning on fixing this in 8.95
System Values:
QQRYDEGREE
This should be set to *OPTIMIZE (not *MAX – that will kill your system)
If you have SMP (symmetric multi-processing), this is very handy for OW jobs.
QZDASOINIT Jobs
These are the pre-start jobs for QUSRWRK and what OneWorld uses to connect to the iSeries. OneWorld users typically use 7-9 ODBC connections for their session. Therefore the initial number of INIT jobs should be 5-8 times the number of concurrent users you will be expecting.
An easy way to tell the number of concurrent connections is to run this command on your iSeries DSPACTPJ QUSRWRK QSYS/QZDASOINIT (or where ever your QZDASOINIT jobs run). You will want to reset the statistics then run it again awhile longer to get a good average.
The rule of thumb for setting these up are as follows:
Start jobs – *YES
Do you want these jobs to start when the SBS comes up
Initial number of jobs – 800
This is the number of jobs that will start when QUSRWRK comes up, the larger the number, the longer it takes to bring the SBS completely up, but you will have that many ready for the users when they start signing on. This number should be about ½ to ¾ your peak total number of users.
Threshold – 8
This number will equal the number of ODBC connections (Data Sources) it takes for a user’s session – normally 7-9, unless you’ve added a bunch of custom libraries to OCM. An easy way to tell this number is to list all the libraries that your OneWorld users will hit:
DD*** – Data Dictionary
OL*** – Object Librarian
SY*** – System Lib
SVM*** – Server Lib
***DTA – Business Data
***CTL – Control Tables
CO***** – Central Objects
***** – Any Custom Libs
Additional number of jobs – 16
This number should be equal to starting up 2 new user sessions in OneWorld, or double the number in the threshold parameter – that way you always have enough open connections to fill two OneWorld user requests, plus anyone else sneaking in there.
Maximum number of jobs – *NOMAX
I would suggest a large number here. Ours is set to *NOMAX
Note; whatever number you put in here will not prevent people from signing on. If you indicate 1000 here and 999 INIT jobs are in use, the next person to sign on with sign in using a BATCH Immediate (BCHI) job rather than a pre-start job.
Maximum number of uses – 100
This can vary, if you restart the subsystem and the OneWorld services every night, this can be lower, if you restart the SBS and services once a week, then setting it between 100 & 150 should be okay. It takes just as much memory and IO to start a new one as it does to keep one listening.
Here is a write up from IBM on this parameter:
The maximum number of sequential uses which can be handled by each prestart job before the job will be ended rather than reinitialized. The default is 200. The same job number is used for 200 different connections. If this is set to 1, the job is used one time and then ended after the client disconnects.
Note: The subsystem will immediately end QZDASOINIT jobs in a status of PSRW when the number of QZDASOINIT jobs in a status of PSRW is above the Threshold plus the Additional number of jobs values. It will end QZDASOINIT jobs that are in a PSRW state until the number of jobs in a PSRW state is equal to or below the Threshold plus the Additional number of jobs values.
Pool identifier – 1
This should be pointing the newly setup share pool – not *BASE which will be 2, as a failover
iSeries Processors:
PeopleSoft (JDE) takes advantage of SMP (Symmetrical Multiprocessor). If you have purchased this feature, make sure you’re taking advantage of it:
WRKSYSVAL QPRCMLTTSK
0 = OFF
1 = ON
2 = System Controlled
Make sure it is 1 (ON)
UBE’s
UBE’s can really tax the system. Make sure that any large UBEs are scheduled (if they can be) to run during off-peak hours (and that the BSFN’s they call run on the enterprise server).
Prior to the new i5 Chips that are in the new 5 Series, the rule of thumb was to run 1 less concurrent UBE than you have processors. The new chips will handle a little more load than prior.
Tuning UBE’s is specific to your shop though and is a hard area to suggest tips on. I would really check the load that long running UBE’s put on your system and the possibilities of off-loading BSFN’s that users kick off, to run on the server if they tax the MFrame.
Database Indexes:
Definitely make sure that your files are setup to handle the MAX 1 TB index size.
Ex. DSPFD – PRODDTA/F0101 (ACCPTHSIZ *MAX1TB).
If you moved from World to OneWorld, these could still be set to *MAX4GB.
Make sure that you utilize OneWorld indexes. World did not always have keys on their files or logicals, this allowed for duplicate data and would produce several unnecessary informational messages on OneWorld UBEs
SQL Packages (SQLPKG):
If you are using Client Access (now called iSeries Access, and soon to be changed again), there is an option to utilize a SQL Package. Setting your DSN up to have a SQL package for each library will eliminate corruption and the packages from filling up too quickly.
OneWorld like SQLPKG’s to have a max setting of 500Mb, even though the iSeries can handle much larger (max depends on the OS version). If the SQLPKG gets any larger, the query will spend more time searching the package than running the query.
These should be cleaned up at least once every two weeks. Anytime a new file is created or an existing one is modified, this need to be deleted so the SQLPKG will reflect the changes.
If you have a lot of security on your users, these will fill up with security query information, rather than file information.
To see what is in a SQLPKG – run the command (PRTSQLINF – PRODDTA/**** *SQLPKG). This will printout a spool file with the information.
Note – We have seen that in 8.10, if you run a UBE from the command line with the RUNUBE command, it will use a different index (or at least do a table scan vs index scan) for a file, than if you ran that same UBE from within OneWorld. To fix this, we had to run all the UBE’s from within OneWorld to create the SQLPKG for that UBE in the system library (E810SYS or B7333SYS).
Journaling:
OneWorld requires journaling to be turned on for numerous files. Hence why OWJRNL is installed with the upgrade or initial install of OneWorld.
It is beneficial to keep the journals and the journal receivers in a separate ASP than the rest of the data. This is a good rule for any system that uses journaling or a HA (High Availability) application.
Packages are built in the IFS; they are then deployed to a library and the IFS. When submitting a full package, turn off journaling of the IFS (if you are using an HA system) directory /ONEWORLD/PACKAGES/ to speed up the process. When you turn it back on, double check afterwards that your package has been sent across to your backup system.
Client Access (iSeries Access):
These settings take a lot of testing because they are specific to your shop and to the version of both OneWorld and Client Access that you are on. They will also change as you upgrade and enable new modules.
Ex. The Enable Lazy Close Support – in Xe it was suggested to check this. In E810, we were having issues with the security kernel not relieving locks on the F98OWSEC, unchecking this so it forced a close on exit fixed that problem.
JDE.INI
Changing the INI is a pretty touchy area. If you have a test server (not environment), that would be the ideal place to make the change, since this does effect all environments and can cause some interesting results. Here’s a few tips on the INI settings to look at:
iSeries Side:
[JDENET]
maxNetProcesses=3 There should be 1 for every 3-4 Call Object Kernels
[LOCK MANAGER]
Server=XYZ
The Lock Manager (sometimes called the TP Monitor) should contain the AS/400 system name (Server= ). With this entry, the Server name will get cached and UBE’s that refer to it will run faster (anytime a UBE has to log the system it ran on and the time will benefit from this). This also helps any Master BSFN that runs on the server for data integrity.
Deployment Server:
[NETWORK QUEUE SETTINGS]
InstallERSpecs=N (This is primarily for the Event Rules)
Configuring your kernels – again this area is my suggestions only, but I will describe what they are for and you can determine how many to put in.
Description Number of Kernels
[JDENET_KERNEL_DEF1] 1
JDENET Kernel
[JDENET_KERNEL_DEF2] 1 per CPU -1 (if you have 8 processors, then set this to 7)
The UBE_Kernel does not do all the UBE work. UBE’s will run in their designated JOBQ’s, not solely through here. UBE’s and package installs run as RUNBATCH processes on the server.
[JDENET_KERNEL_DEF3] 1
Data replication Kernel
[JDENET_KERNEL_DEF4] 1 for every 50 concurrent users
Security Kernel – Processes will fail if there are not enough security kernels. Users will also get the message that the security kernel is busy. Set the max to follow the rule in number of kernels, but the Autostart to 1 or 2.
[JDENET_KERNEL_DEF5] 1
There can only be one Lock Manager running
[JDENET_KERNEL_DEF6] Experimental
This is the Call Object Kernel. This runs not only the MBF’s but all BSFN’s mapped to the server. This will take some toying with to get tuned for your shop.
[JDENET_KERNEL_DEF7] 1
The JDBNET (server-to-server) Kernel should start with 1, add more if you utilize it more.
[JDENET_KERNEL_DEF8] (Xe and prior) 1 per CPU
The Package Build Kernel should follow closely the same guidelines as the UBE Kernel. This is replaced with DEF11 in later releases.
[JDENET_KERNEL_DEF9] 1
You should only need one SAW Kernel. One CNC and Admins will use SAW.
[JDENET_KERNEL_DEF10] 1
There is really only one Scheduler per system
[JDENET_KERNEL_DEF11] 1 per CPU
Same as DEF8, the JDE Queue is what is important rather than the number of Kernels.
[JDENET_KERNEL_DEF12] 1
There can only be one UBE Subsystem Kernel
[JDENET_KERNEL_DEF13 - 24]
These are all new to 8.10 & 8.11 and I have not spent a lot of time tweaking these & testing them.
DASD:
As any iSeries Admin will tell you – the more disk arms you have on a system, the faster it’ll run.
Last Minute Notes:
Make sure that you are current on OS400 cumulative updates and the APARs. If you use TSE’s and seeing sluggish performance, try setting them to 16 color mode instead of the default 256 color mode. You don’t need a lot of colors in OneWorld (I’m color blind and function just fine in there).
NoticeThis is personal documentation from Kristian Bryant and not PeopleSoft. Changes to enhance performance should be done with careful consideration and not during peak load times.