Long Full Package Builds

joy_fernandez

joy_fernandez

Well Known Member
4-17-01
Everyone:

We are still experiencing very long Full Package Builds and were wondering
just how long others are seeing.

We are WinNT SP6a, Oracle 8i, C++ Version 6.0 SP3, Xe SP15. Our Enterprise
Server is four 500 CPUs, with 2 gig of memory and plenty of continuous hard
drive space. Our Deployment Server is two 500 CPUs with 1 gig of memory and
over 20 gig of free space. Both are HP Servers.

We have been building our Full Client and Server Packages separately, but
are planning on testing a full build together. We are seeing times very
from 12 to 25 hours per package.

I would greatly appreciate hearing from you all. Thanks for your replies.

Joy Fernandez
JDE System Administrator
830-868-5035
[email protected]
 
Joy,

I have Deployment Server with 2 450Mhz CPUs, 512mb ram and over 20gb free.
Win2000
Enterprise Server 2 600Mhz CPUs, 512mb ram and over 10gb free. WinNT 4.0
SP6a, SQL 7
I'm running XE SP14.2, XU1, C++ 6 SP3.

I started a new FULL Client/Server package build yesterday about 1:30pm and
it finished successfully around 11:30pm.


Wade Wells
Principal Consultant
FutureNext Consulting
 
4-17-01
Sebastian:

We are on a deciated 100 MBps between the two servers with nothing else on
this pipe, but the Deployment and the Enterprise Servers. On the Enterprise
Server our page file is set to 2.6 GB and assigned to the D: drive with 3.2
gig free. The Deployment Server has a page file of 1 GB and assigned to the
E: drive with 3.67 gig free.

Joy
 
Joy,

We were having problems with long full package builds. A JDE Consultant
from the Toronto office suggested the following to us:

1. Try reinstalling the latest NIC driver. I've been at a client where
package builds were failing at random points, and simply reinstalling the
latest NIC driver fixed it.
2. If using it, WINS should be ok, but make sure it's working properly.
I've seen rebooting the WINS or name server fix things too. Or simply try
putting the server in the local hosts file.
3. Make sure the bind order is correct. This will cause problems. I've
seen package builds take days because IPX was ahead of TCP/IP in the bind
order.

We checked all this & it turned out that we had 2 NIC's on the Enterprise
Server, 1 active 1 inactive. The bind order was incorrect. It had the
inactive NIC first. Once we corrected this, our package builds dropped from
12-16 hours down to 4-5 hours.

Good luck,

Kimberley Bohn
QNX Software Systems Ltd., Canada
B73.3.2, NT, SQL7.0, SP11.3
WTS W2K
 
Joy,

did you turn on JDEDEBUG on the deployment-server? Sounds like this...
Regards
Herbert
On 17 Apr 2001, at 8:50, joy fernandez wrote:
 
My last full w/s build was 3 1/2 hours. Ent server is 2 x PIII/800 and Dep server is 1 x PIII/800. Both COMPAQ Proliant DL380s.

We had a problem early on with these servers and Xe whereby builds took an excessive time and apparently random errors would occur either with building a spec file index or a C compile. We finally correlated these errors with Rdr errors recorded in the NT logs.

"Fix" was to turn off Rdr caching in NT and our problems disappeared. Just another of those MS/JDE mysterys never satisfactorly explained.

Rod MacDougall

[email protected]
City of London, Ontario, Canada
Xe SP14.2
Intel/NT Oracle 8i
 
Hello,

Maybe a strange question but what is Rdr caching?

We also have some problems with the Full client Build so if we know what Rdr caching means then perhaps we can check that.


Richard Stam
CNC/System Administration
LIVE: B733.3 SP13, AS400 Enterprise Server on R4V4
Citrix <100 users (so far) and some NT/W2K Clients
 
Here is MS's definition of Rdr caching,
hope this helps

By default, when the Microsoft Windows NT redirector opens a file for read
or read/write access, the redirector utilizes the Windows NT system cache.
Therefore, when data is written to the file, it is written to the cache and
not immediately flushed to the redirector. The cache manager flushes the
data at a later time. If an unrecoverable network error occurs while the
data is being transferred to the remote server, it may cause the write
request to fail and the above application popup to occur.

RESOLUTION
WARNING: This procedure should first be tested in a non-critical environment
before being implemented into a production environment. In general, this
change slows down network I/O.

You can disable Network Redirector File Caching by performing the following
steps:

WARNING: Using Registry Editor incorrectly can cause serious problems that
may require you to reinstall your operating system. Microsoft cannot
guarantee that problems resulting from the incorrect use of Registry Editor
can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys and
Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete
Information in the Registry" and "Edit Registry Data" Help topics in
Regedt32.exe. Note that you should back up the registry before you edit it.
If you are running Windows NT or Windows 2000, you should also update your
Emergency Repair Disk (ERD).


Start Registry Editor (Regedt32.exe) and go to the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters


Click Add Value on the Edit menu.


Enter the following:

Value Name: UseWriteBehind
Data Type: REG_DWORD
Data: 0

1-
 
Richard

You'll get a pretty good idea of what Rdr (Network Redirector) file caching is about and how to turn it off by going to support.microsoft.com and looking up ArticleId Q163401.

I see no point in doing this, however, unless you are logging Rdr errors on your Deployment Server. As I recall we were getting Event 3012 errors - "An unexpected network error has occurred on the virtual circuit to ...".

(which naturally leads to the question about what MS considers an *expected* network error to be - but I digress)

FWIW we did the procedures (set both UseWriteBehind and UtilizeNTCaching to 0 => false) on our Deployment(not Enterprise) server. Presumably we incur some kind of performance penalty as a result (not noticeable) but the important thing is that our full workstation-only builds no longer get Rdr errors and complete in about 3 hours.

By the way, assuming you're using dual speed NICS on a fast Ethernet network - you do force them into 100 full rather than let them auto-detect don't you?

Rod Mac Dougall

[email protected]
City of London, Ontario, Canada
Xe SP14.2
Intel/NT Oracle 8i
 
Hi Joy,
You might want to check your virus scan on your servers. I have had several clients that have had performance problems while their virus checks are running on the servers. A good way to tell if this is your issue is to look at the task manager performance tab on the server when your jobs are running and if your are not seeing heavy CPU utilization try turning off your virus software. If your CPU utilization then increases significantly then you should see your build time fall.

Anything is possible.

Shane
 
Are you building this on the Deployment or on a client.
Make sure VIrus checker is turned off. I cut 12 hours off a clients build.
Intially it took 22 hours to build a full package. We are down to about 8-9
hours
NT -AS400 B7332 SP11.3
 
Back
Top