DB2 UDB Package Build performance

Hi all,

Our full package builds are running awfully slow - 13 hours. Especially during the spec file builds ie gbrspec, rdaspec.. etc..

Has anyone has any tips regarding the optimisation parameters for the DB2 UDB v7x ODBC driver CLI parameters (either for DS or ES)?

Any other advice?

Thanks in advance,
/Philip

Philip,

We had this issue with our AS/400 (830, V5R1) as well, but our package builds were taking about 17 hours. In my experience, 13 hours is about as fast as it gets on an AS/400, if you have Central Objects stored on the 400.

We reduced our package build times to just under 13 hours by adding a 1GB switch between the AS/400 and the Deployment server, and also gained a minimal increase in performance by changing the ODBC connection block size (on the Deployment server) to 512k (for Central Objects only).

Hope this helps, but if anybody knows how to shorten this time even more (I would kill to be able to build a full package in 6 or 8 hours), I'd love to hear about it.

I build my full packages on a fat client, not the deployment machine. My fat is much quicker! I can get a full package done in 8-9 hours. We have a gig backbone and 100mb to my desk. My 400 takes about 4 hours to process the server side. The deployment machine is hooked directly to the 1gb backbone!

Good luck.


R. Shawn Cobbett
Project Leader, JD Edwards
Enersource Corporation
905.566.2727.277
416.435.5428

This speeds up the client site;
1. Created new MS Access Database - pathcode.mdb in the
E:\APPS\JDEdwardsOneWorld\B7333\PLANNER\DATA directory.

2. Copied and pasted the F00942 table from the JDEPLAN.mdb to the
pathcode.mdb.

3. Created ODBC entry Path Code - Package Build to point to the newly
created MS Access database created in step 1.

4. In OneWorld® created a database data source Path Code - Package Build to
point to the access database created in step 1.
this pointer. This database data source has been created in the
F98611(Database Data Source table) in OneWorld Planner - B7333.

5. Created an OCM mapping for the DEP7333 environment only, for the F00942
table to point to the Path Code - Package Build database data source,
this OCM mapping has been activated and the DEP7333 mapping pointing the
System - B7333 database data source has been deactivated.
This has been perform in the F986101(OCM mappings table) in OneWorld
Planner - B7333.

6. Effectively steps 1 to 5 have allowed me set up a separate path code
master table for the DEP7333 environment. Where UNC can be turned off
without
only for the package build process. To turn UNC you need to change the
following attributes in the PATH CODE master.
UNC FLAG = N instead of Y
Server Share Path = E:\APPS\JDEdwardsOneWorld\B7333 instead of B7333.

There is one small drawback to this approach. You will need to correct the
package *.inf file before deploying/installing the package.
An example of what to correct is provided below it will vary depending on
type of package but the only section you will need to
change is the [SrcDirs]

Package Inf file after build with UNC deactivated

[SrcDirs]
SPY7333=E:\APPS\JDEdwardsOneWorld\B7333\PY7333\package\PY7333FA
SSYS=E:\APPS\JDEdwardsOneWorld\B7333\systemcomp
SPY7333DATA=E:\APPS\JDEdwardsOneWorld\B7333\PY7333\package\datacomp
SHELP=E:\APPS\JDEdwardsOneWorld\B7333\helpscomp

Should be corrected to

[SrcDirs]
SPY7333=\\RIJPAT-S-263\B7333\PY7333\package\PY7333FA
SSYS=\\RIJPAT-S-263\B7333\systemcomp
SPY7333DATA==\\RIJPAT-S-263\B7333\PY7333\package\datacomp
SHELP==\\RIJPAT-S-263\B7333\helpscomp

Bilby,

two suggestions come to mind: first, enable compression in the ODBC settings for your Central Objects data sources (this should save you a couple of hours). Second, make your package build queue multi-threaded (this should also save a couple of hours). Tell us how it goes from there.

Thanks for the tips!

But I should mention that I'm currently using UDB DB2 for INTEL Windows 2000.

I am currently looking for advice on speeding up the package build using the ODBC settings on the DS & ES (CLI) that come with the UDB DB2 driver..

Any tips would be greatly appreciated.

Best regards,
/Philip

4.5 hrs for client and 1 hr for server on a combined build.

No ODBC tweaking, normal 2x2 hardware.

Post your builderror.txt

4.25 Client, but my server packages are killing me 8.5hr.

I am seeing no clear cause. CPU, Memory, Disk Utilization all seem average with plenty of resources available.

Any ideas?

network connection between the deployment server and enterprise server. Ensure that the duplexing on both nics is set to autonegotiate.

I should have been more clear. The majority of the time is spent waiting for the compiles to complete.

Oh, now I notice that you are not the original poster. A quick look at your sig verifies that you are on AS/400. Therein lies your performance problem.

What's your setup? What kind of servers? What RAID sets are you using? What version/fixpack of DB2? Do you have a seperate instance for DB2?

Since both myself and Brother Of Karamazov have the EXACT same performance bench marks I don't think it's the database since I haven't tuned DB2 UDB yet. I have however tuned the network and O/S. Once you're happy that the network and O/S are tuned then you can start looking at the database.

Here's what I've got for ERP8 SP1, SP22 for DB2 UDB 7.2 with FixPack 7b on Windows 2000 SP3. Client - 4.5 hrs, Server - 1 hour. The deployment server is a 2 way - 2.8 GHz x235 with 1.0 GB and the Enterprise Server is a 2 way 345 - 2.8 GHz with SCSI attached storage. I've got 4 network cards on each server paired in load balanced teams. All servers have a 'private' server network for only server traffic. NIC's are set to 100 Mpbs full duplex and ports on Cisco switch are also set to 100 mbps full duplex Try adding a few NIC's in teams and creating a seperate segment for server traffic.

Also, are the servers on the same switch/network segment? What NIC speed are you running at? Set the speed to 100 Mbps full. Also create a HOST/LMHOST file on the two servers. Also move the Windos page file to a seperate volume, make sure spplication priority is set for background services, etc.

As for RAID, I've got 2 RAID 1 arrays and one RAID 5 array. OS is on 1st RAID 1 and DB2 transaction logs and Windows paging file are on 2nd RAID 1 Array. DB2 data pages and OneWorld are all on the same RAID 5 array. If you don't have the proper RAID configuration then the laws of physics will really bite you.

In DB2 UDB make sure set the Application Control Heap Size on the Business Data table spaces from 128 to 256 and on the shared database (OWSH7334) from 128 to 1024.
-In Control Center select the database and then select configure.
-Under ‘performance’ search for ‘APPL_CTL_HEAP_SZ
-stop and restart the instance

Let me know if this helps.


Colin

Doug,

Are you using the default *JOBQ to build your package in? You can change the package build queue to one of your choice and multi-thread the *SRVPGM builds.

In the INI on the AS/400 [BSFN BUILD] add a line QName=yourqueue.

When we were on a smaller AS/400 we ran them 4 wide at priority 60 and we went from 12 hours to about 4, we are now on an 850 9 way (OK 12 with 3 turned off) and run 2 simultaneous builds 6 wide and it takes about 2 1/2 hours.

Tom Davidson

SQL Build

Full Package build in 2 hours and 21 minutes (Server:1 hour 10 minutes; Workstation: 1 hour and 11 minutes)

ERP 8.0
SP 22_B1
Dual Xeon Windows 2003 deployment server
Quad Xeon Windows 2003/SQL 2000 database
Dual Xeon Windows 2000 Build machine (Doubles as JAVA server).
All connected with gigabit Ethernet.

Our guys offshore start the build at 1:30am and have it deployed to the Terminal Servers and regenerate JAVA objects before anybody arrives at 6:00am.

Tom,

I have been using the default JOBQ but it is multithreaded (2). We have an 820 with 2 processors. I will sometimes manually reroute the builds to other JOBQ's and have 4 running. This will kickup the processor utilization, but the build doesn't seem to run much faster. As I mentioned, I will watch the other resources (memory and disk usage) at the same time. I just don't feel like I'm hammering my resources much and getting little for it.

Anything else you think I could look at?

Thanx much
Doug

Doug,

Run the job at a low priority and change the timeslice from 5000 to 1500, then who cares if you hammer your resources? As in everything else it is a trade-off. Only you can decide if the reduced build time is worth the effort and increase in CPU usage. Normally on the AS/400 if you are at 95% CPU or less, you see no real impact on the system (except greater through-put of course ). I would try setting up a separate SBS and routing your builds there, this gives you the most control of what/how much resources you want to give the builds. Feel free to play around with using he batch shared pool.

Just one man's opinion.

Tom Davidson

And a worth opinion it is

Thanx much