Ref: 06430025
Title: Steps to Take to Alleviate "Sleeping Server" Symptoms
Date:  5/30/91

Copyright 3Com Corporation, 1991.  All rights reserved.


There have been several reports of "sleeping server" symptoms with 3+Open
version 1.1, 1.1e, and 1.1f.  The symptoms indicate a server which had
been previously functioning has ceased to respond to existing sessions
or requests for new sessions, although the LCD indicates the server is
still active.  These symptoms may appear suddenly, or gradually with a
noticable slowdown preceding the failure.

There are many possible causes for these symptoms, including any one or
a combination of tuning problems, memory constraints, disk space
constraints, and non-current software.  What follows is a step-by-step
guide for preliminary troubleshooting of sleeping server issues.  Most
sleeping server problems reported to Technical Support are solved at
this level.

1.   Verify the version of software.  The server and workstations
must be running 3+Open version 1.1f.  This maintenance update is
available free of charge by calling 1-800-NET-3COM.  It comes with
a Release Guide and a Network Tuning Guide.  The software and Release
Guide includes all fixes and information from the previous 1.1e release
as well as new fixes and information.

2.  Tune the server.  Since the release of 3+Open there have been several
iterations of tuning instructions in the manuals, release notes, technical
reference guide, and technical articles.  As of 5/30/91, our most current
tuning information is contained in the 3+Open 1.1f Network Tuning Guide
(available with the 1.1f Maintenance Update) to be used in conjunction with
the 3+Open 1.1f Network Tuning Guide Errata (available on Ask3Com in the
DOCS library, filename ERRATA.ZIP).  The information in this guide along
with the errata supercedes all prior tuning guidelines published by
3Com.  It is critical to use these values when tuning the server.

3.  If using NBP, upgrade the NBP.OS2 and NBP.EXE files to 1.1Y, which is
a newer release than that provided in 1.1f.  This is available on Ask3Com
in the DRIVERS library, filename NBP11Y.ZIP.  Both workstations and servers
must be upgraded.  The version of NBP provided in 1.1f has known problems
that may cause "sleeping" symptoms.

4.  Check for available disk space on the c: partition.  Dynamic files such
as print jobs in the spooler and the OS/2 swap file can consume a large
amount of disk space.  If 3+Open runs out of space on the C partition it
will crash.  Also, by default the OS/2 SWAP file, LanManager spool files,
USERDIRS sharname, DOSAPPS, FAMAPPS, and OS2APPS sharenames are all pathed
to the C partition. If the C partition is 32 MB or less they should be
moved to other locations on the server as follows:

*  Move the SWAP file by changing the SWAPPATH parameter in
CONFIG.SYS to a partition other than C.

*  Move the LanManager spool files by XCOPYING the \3OPEN\SERVER\LANMAN\SPOOL
directory to a partition other than C and updating the SPOOLDIR parameter
in LANMAN.INI to reflect the change.  Verify the file permissions for the
new directory structure through the NetAdmin interface.

*  XCOPY the contents of the C:\3OPEN\USERS directory to another partition,
delete the USERDIRS sharname, and recreate the sharename to reflect the
new path.   Verify the file permissions for the new directory structure
through the NetAdmin interface.  Remove the contents of the C:\3OPEN\USERS
directory.  Update the USERPATH parameter of the LANMAN.INI file to
reflect the path change.

*  XCOPY the C:\APPS directory to another partition, delete the DOSAPPS,
OS2APPS, and FAMAPPS sharenames, and recreate the sharenames to reflect
the new path.  Verify the file permissions for the new directory structure
through the NetAdmin interface.  Remove the contents of the C:\APPS
directory.

Note:  It is best to upgrade to 1.1f before taking this step, as the 1.1f
installation program will look for these directories on the C partition.


5.  Make sure there is plenty of RAM on the server, and that the server
is using SWAP, MOVE for the MEMMAN parameter in CONFIG.SYS.  Below are
several recommendations needed to calculate the amount of RAM required
on a 3+Open server:

*  Allocate 5 MB for OS/2 and the "core" file/print service.

*  If Presentation Manager is used, add 1 MB.

*  If the server will be used as a concurrent workstation, add 2 MB.

*  Add 1 MB for each 3+Open Name, Mail, Start, and Internet service that
will be active.

*  Add .5 MB for each 3+Open Locator, Netlogon, Netrun, and LAN Vision
service that will be active.

*  If 3+Open Backup will be used, check whether memory swapping and
moving are enabled, and the expected times that backups/restores will be
performed.  If swapping and moving are enabled and backups/restores are
not expected to occur during normal use of the server, add no additional
memory for it.  Otherwise, add another 1 MB for 3+Open Backup service.

*  Add the size of the disk cache.  (This is probably the single most
important parameter that affects server performance.)  In 3Com's testing,
4 MB seems to be the optimal size; larger caches do not tend to improve
server performance.

*  Set the server's LANMAN.INI parameter NUMBIGBUF= to twice the number
of OS/2 clients expected to be simultaneously doing large file transfers
to and from the server. In most situations, eight should be a good upper
limit for this parameter.  For every bigbuf allocated, add 64 KB to the
total memory required in the server, above.

*  Set the server's LANMAN.INI parameter NUMREQBUF= to at least the number
of physical clients (both DOS and OS/2) that the server will simultaneously
support.

*  Monitor the server's error log for instances of "Out of Resource"
messages.  It is not unusual or terribly bad for one or two of these to
appear infrequently.  The server will dynamically allocate more buffers
as it needs them.  If these errors appear frequently, begin increasing
the LANMAN.INI parameters in very small increments (1 or 2 at a time
for NUMBIGBUF, 2 to 5 at a time for NUMREQBUF).


The steps outlined above alleviate the vast majority of sleeping server
cases reported to Technical Support.  Taking these steps before placing
a call to Technical Support could save you valuable time.
