Update 3 (performance stuff)

[Michael L.]

We have an iseries 400 270 on V5R1 with just a tad > 2GB of ram. This is a net new install of "xe", SP 16.1, Update 3 on the internal 850mhz netfinity deployment server with 2.5GB of ram, 2000 professional, SP2.

The "first" workbench has been running for almost 24 hours. I have given as much ram as possible to *base and changed the timeslice to 99999999.

Would very much appreciate it if anyone could respond with any ideas at all that may improve performance.

I would imagine the "full package" build will take a verrrrrrrry long time.

Does anybody have any ideas? I had heard that making a change to either the QSECOFR (or is it OneWorld) usrprf or the associated JOBD could improve performance during the package build.

Thanking you in advance for your assistance.


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

 

[pjones75]

Hi Michael,

The AS/400 has many different ways to configure for package builds etc. I am unsure what you mean by running the "first" workbench. We run an AS/400 Enterprise server. I had to modify the number of Jobs that were allowed active in the subsystem that the build was submitted to. DO NOT set it to *NOMAX, but as a guide we use about 4-6 at one time. If it is set to one then your builds will take forever. We just upgraded to an 820 which cut our package builds down from 36hours to 12hours. If I know some of your AS/400 settings then I might be able to help more. Don't modify the QSECOFR profile. The ONEWORLD profile is what is used for builds.

Cheers
Paul Jones
The Gandel Group
XE, SP16, AS/400 820 Enterprise, Update 1(PD) and 3(DV, PY). Web Server IBM x350.

 

[richardjackson]

Your configuration and what you are doing is not clear to me.

Are you using the internal netfinity server as the deployment server? If so, what is your disk configuration? What do you mean by "first workbench"?

If by "first workbench" you mean the spec load then the app is copying full TAM specs from the CD to the path code spec directories on the 400. If you have a lot of path codes, then this will take longer.

If "first workbench" means the data load then the app is creating tables and (perhaps) copying demo data into them. If you decided to create a lot of environments or load a lot of data, this might take quite a long time.

Assuming that you are using DB2 as your database (seems like a reasonable assumption on an AS/400) then there are some tuning tips for making Client Access and the database itself run faster. There are (old) white papers in the Advanced Technologies part of the KG.

At v4r5, changing timeslice does absolutely nothing except wear the paint off the top of your keys. Memory allocated to *base is not the issue, page faulting is the issue. If you are getting a lot of page faults then you need more memory - regardless of the amount there. How busy are your disk drives?

Most important - are you transferring data between the deployment server and the 400 at 100 or 10 mhz? Most new installations get this wrong because they let the NIC cards negotiate the speed. The negotiation routine usually selects 10 half when they should be forced to 100 full. Be sure to check the deployment server, the switch, and the 400. I perform a copy/paste of a 25 megabyte .xdb files between the DS and the 400. It should take about 8 seconds - 25 megabytes * 8 bits per byte / 100 mhz * 2 for acks. Do the file copy in both directions. Sometimes it is much faster one way than the other. If so, there is a network problem. If it takes much more than about 8 seconds, there is a network problem.

Check to see if you have a virus scanner running on the DS. Those may cause interesting time delays (thanks to the folks in Indiana for showing me that one).

In either case, 24 hours seems too long. Which phase are you running and what else is happening?

Richard Jackson