H
huangbaili
Unregistered / Unconfirmed
GUEST, unregistred user!
You can test for a cosmetic problem by loading, or unloading any NLM. This will
cause processor information in monitor to be recalculated. Remember also, that
monitor is reporting once a second something that is happening in the
nanosecond range. Some server processes call a NetWare function called
CyieldWithDelay or CyieldUntilIdle. If there is a thread spinning on one of
these functions, the server will appear to have high utilization. Utilization
will then
be inaccurate.do
n’t panic when utilization goes to 100% for a few
seconds and bouncesdo
wn. This is normal for all 4.1x servers. Obviously
monitor is only reporting a snapshot of the utilization at some instant in time.
The NetWare OS is nonpreemptive for performance reasons. Because it is
nonpreemptive the NetWare OS relies on NLM writers to correctly yield the
processor at the appropriate times. This means that a poorly written NLM can
have disastrous effects on server utilization. You should never put an unproven
NLM on a production system.
If you are running NetWare 4.0, 4.01, or 4.02, move to NetWare 4.10 or 4.11.
Reason? Most of the fixesdo
ne for high utilization have been implemented for
NetWare 4.10 and 4.11 only. All development for previous versions of NetWare 4
has stopped;
NetWare 4.10 and 4.11 are the only 4.x Operating Systems where
Novell continues development. There are patches for the other versions of the
OS, but they are not as current anddo
not have the resources dedicated to
them at Novell like NetWare 4.10 and 4.11do
. If you cannot upgrade from
NetWare 4.0x, ask Novell Technical Services for the patches specifically for
the operating system, and follow this guide;
your solution may still be in
thisdo
cument.
Be sure that LAN and disk drivers are the current available from the hardware
vendor. Many vendors have found problems with their lan and disk drivers and
will periodically update these drivers. It is important to be at the latest
version of these drivers unless asked to back rev by technical support.
At the server console, type speed There have been cases where a system board
will drop the processor speed after boot up. A typical speed reading might be:
486/66 @ 1800, Pentium 90 @ 3300, and Pentium Pro 200 @16,500. A speed rating
drastically lower then
the expected value may indicate some sort of
configuration or BIOS problem, and can be a significant contributor to high
utilization. The NetWare OSdo
es not have a setting that affects the processor
speed.
7. When utilization problems occur, eliminate as many variables as possible.
Remove non-essential products until the server is in a vanilla state. This will
help determine if there is a problem with a loaded module. This is like
troubleshooting an abend, i.e., take the server to a stable platform, and then
add back nlm’s until it becomes unstable.
This is an important step OFTEN overlooked (sometimes because it is so time
consuming, and production servers oftendo
not accord this type of flexibility
in troubleshooting). Basically this step in the troubleshooting process is
trying to determine if a piece of software is causing the high utilization.
So, unload EVERY piece of software on the server. Usually customers will start
with the non-essential pieces of software;
non-essential means that the server
and the users can function without this piece of software being loaded.
Examples of software items to unload would be: ManageWise, virus scanners,
server metering nlm’s, backup solutions, UPS software, Compaq Insight Manager,
etc. Many nlm’s will autoload other nlm’s at the server, and so by merely
unloading a specific nlm, thatdo
es not completely remove the program from
memory. If possible, rem out the loading of the nlm’s in the autoexec.ncf file,
and then
restart the server. This will ensure a vanilla environment to work
with.
After the non-essential nlm’s are unloaded, and if the utilization remains,
schedule time to unload the other nlm’s that are more essential to the
operation;
i.e., NetWare Connect, NetWare/IP and anything else
that could not
be unloaded before because of the production status of the server.
The idea here is that if the high utilization is based upon software, it will
be found by comparing the state of the server with the software loaded and
without the software loaded.
8. Go to monitor | Processor Utilization | <F3> and see if there is any one
process that is hogging the CPU. It is possible to have 2-3 contributors to
high utilization, but usually only one, and sometimes two. FYI: AES stands for
asynchronous event scheduler.
If after pressing <F3> a single process can be seen that is hogging the CPU,
and it is a known NLM for a program running on the server, remove it (unload
it from the server console). For instance, if program XYZ is running and module
xyz.nlm shows 75% of the processor utilization, unload it. This should
IMMEDIATELY help the situation on the server. If the utilization stilldo
es
not drop afterwards, and there is no module in processor utilization that shows
a high amount of load on the processor, the server will probably need to be
bounced and the xyz.nlm module not loaded for a testing period of time. This
may happen because the server is trying to catch up with cork-to-do in its
queue. So wait for a little while first, and then
do
wn the server if nothing
else
works. There have been situations where unloading the offending module(s)
has caused the server to abend, so be prepared for this eventuality. For
NetWare 4.10 an abend means a complete stop on the server. For NetWare 4.11,
depending on the type of abend, the server may still be useable. If you are
running NetWare4.10, and the server abends trying to unload a module go into
the debugger and try to put this offending?thread to sleep. If you cando
this,
then
the server can probably be broughtdo
wn safely without having to power
down. See Extra Troubleshooting Tips #7 at the end of thisdo
cument for help
with the NetWare debugger.
If the server is running, butdo
es not allow access to the console so the
administrator can typedo
wn get a copy of Fconsole (this is a NetWare 3.x
utility). Fconsole will allow a remote connection to the server todo
wn it.
If you need to get this utility, it is in Tabnd2a.exe on the internet
(http://support.novell.com).
Many high utilization issues deal specifically with NCP Requests taking the
majority of the processor load. This is noticed on the processor utilization
screen (in monitor). NCP stands for NetWare Core Protocol. This is the
communication protocol between applications and the server. It is NetWare.
You cannot turn off NCP packets, nor would you want to. All file and print
requests are carried via NCP. If NCP is your problem, any number of problems
could exist on the server. These problems are all talked about here in this
do
cument. There is not A single fix for NCP Requests taking the majority of
the processor load. This statistic is just the outward appearance of a problem
on the server that must be found through troubleshooting. NCP problems have
been seen in a number of areas, of few of which are: lan problems, DS problems,
and client 3rd party software problems.
9. Too few service processes or too few packet receive buffers available will
almost always cause high utilization. Server resources can be divided into Lan,
Disk and Processor resources. Lan and Disk resources are the number of buffers
available, while Processor resources are the number of Service Processes
available. As a network packet arrives or a disk read or write isdo
ne, there
should be a buffer available for the data. If there is a buffer available,
there should be a Service Process available to deal with it. Running out of
any one of these for more than a brief period will cause high utilization and
will delay response from the server for the users. Novell suggests that the
parameters below be set as indicated to help prevent utilization problems.
If youdo
not have the ram todo
this, you will know immediately after
restarting the server. Your cache buffers will drop below 40%.
Here’s an explanation of the above set parameters:
Minimum directory cache buffers: The number needs to be high enough that
directory searches can bedo
ne quickly, but no higher than necessary because
these buffers cannot be reallocated for file caching once they are allocated
for directory caching. We suggest that 2 to 3 per connection is a good rule.
Maximum directory cache buffers: This parameter keeps the system from
allocating too many directory cache buffers so that memory is available for
other server processes. Increase this limit if the server responds slowly to
directory searches. Decrease this limit if too much memory is being allocated
for directory searching.
Directory cache allocation wait time: During this time, all requests for a new
directory cache buffer are ignored. If the wait time is too low, peak usage
requests cause more resources than necessary to be allocated to directory
caching. If the wait time is too high, the system is very slow in allocating
the directory cache buffers necessary to service the usual number of directory
requests. If directory searches seem slow even after the server has been
running for 15 minutes, you may want to decrease this parameter.
Minimum packet receive buffers: This parameters should be set at 2 to 3 times
the amount of connections the servers has (users, servers, printers, etc.).
The operating system will allocate this number immediately upon booting.
Maximum packet receive buffers: This set parameter performs the same type of
task that maximum directory cache buffersdo
es, except that it is for packet
receive buffers. Packet receive buffers are used to transfer a packet from an
ECB (lan packet) to a service process.
New packet receive buffer wait time: This parameter specifies how long the
operating system will wait after receiving a request for a packet receive
buffer before granting a new buffer. This parameter prevents the system from
granting too many buffers during a sudden peak in usage.
Minimum service processes: Specifies the minimum number of service processes
the operating system can create without having to wait for the time specified
by the New Service Process Wait Time parameter.
Maximum service processes: Specifies the maximum number of service processes
that the operating system can create. Increasing this number helps only if more
than 20 requests are being delayed simultaneously for a disk I/O to be
completed.
New service process wait time: Specifies how long the system should wait to
make an allocation when it receives a request for another service process.
If the settings on these parametersdo
not make sense, baseline the server and
see where the directory cache buffers, packet receive buffers, and service
processes are look on the main screen in Monitor.nlm. These numbers will be
your minimums. Set your maximums accordingly (i.e., higher than the minimums).
If the maximums for these parameters are reached, the server will experience
high utilization because it cannot allocate resources to handle user requests
for service. The suggestion would then
be to set the maximums far enough above
the minimums so that thisdo
esn’t happen. After changing these settings, the
server must be rebooted for some of the minimums to take effect.
10. On large systems servicing over 1000 users there have been cases where
file service processes (FSPs) were not being allocated fast enough by the
server, resulting in 100% utilization. Novell has released an NLM to
preallocate file service processes when the server is first booted so that
this particular problem is solved. This nlm is called WORKTHRD.NLM. There is a
separate version of this nlm for NetWare 4.10 and NetWare 4.11. In other words,
the 4.10 version of the nlm will not work with NetWare 4.11, and vice-versa.
Both of these files are included in the highutl1.exe file in the
self-extracting file called wrkthd.exe. After extracting this file, there
will be two new directories created (410 and 411) with a workthrd.nlm in each
directory. Copy the nlm to the c:/nwserver directory (or whatever directory
server.exe is located in).
NetWare 4.10 use: Place the following command in the startup.ncf file
immediately AFTER the loading of the patches:
LOAD C:/NWSERVER/WORKTHRD.NLM <# of service processes to pre-allocate ... 500
is a good no.> SET MAXIMUM SERVICE PROCESSES = < MAX NUMBER>
NetWare 4.11 use: Place the following command in the startup.ncf file
immediately AFTER the loading of the patches:
PMLOAD C:/NWSERVER/WORKTHRD.NLM <# of service processes to pre-allocate ...
500 is a good no.> SET MAXIMUM SERVICE PROCESSES = <MAX NUMBER>
The MAX NUMBER is the maximum number of service processes you wish to allow.
Workthrd.nlm preallocates service processes up to the maximum of 1000. Set the
minimum file service processes to the same number that workthrd.nlm
pre-allocates. On a 4.10 server if 410PT3 or later is not applied, the maximum
number of service processes will be 100. NetWare 4.11 comes standard with
1000 maximum service processes.
Each File Service Process that is pre-allocated will consume 16 K of memory.
do
ing the math, 1000 FSPs will then
consume 16 MB of memory. Be careful about
pre-allocating FSPs if memory is tight.
11. Set upgrade low priority threads=OFF This is off by default in
NetWare 4.1x, make sure it hasn’t changed. There are some 3rd party
applications that run on NetWare servers that request you set this parameter
to on. Be careful.
This one set parameter can be responsible for high utilization on a server.
The reason for this is because by setting this to on, ALL low priority
threads then
have the same light to the processor as every other normal
priority thread. This means that compression, sub-allocation, and any other
low priority thread will battle your users for CPU cycles whereas normally,
they would wait until there is a free cycle. Normal priority threads should
not have to wait for a normally low priority thread to finish processing, i.e.,
do
not set this parameter to on unless you know exactly what ramifications it
will cause.
Sometimes a server will report: an nlm has been loaded thatdo
es not allow low
priority threads to run. Low priority threads are used for compression, ... etc.
Set upgrade low priority threads = ON or unload the nlm. If an NLM has a
thread that is rescheduling frequently, this will cause this message to occur.
If this message continues to appear on the server console, a process is not
releasing the CPU for an extended period of time. This can be an indicator of
a high utilization situation. The problem with this message is that it never
displays the actual nlm that is causing the problem on the server. To fix this
use the set parameter “set display relinquish control alerts = on” If a
module uses the processor for more than 0.4 seconds without relinquishing
control to other processes, the following types of messages occur:
<process name> Process did not relinquish control frequently.
Module: <module name>
Code offset in module: <memory address>
This will identify the module that is hogging the CPU so that it can be
unloaded and further troubleshooting steps can be taken.
Sometimes this message is seen when the server is first brought up, and
sometimes after ds.nlm is loaded. If this error runs repeatedly on the screen,
or if you suspect DS database corruption,do
the following:
1.
Bring the server up with “server –ndb” or “server –ndb” in the case of
SFTIII.
2.
Run DSREPAIR. In a ONE SERVER environment, choose the unattended full repair
option. If there are multiple 4.x servers, choose: Advanced Options
menu / Repair local DS database and mark everything NO except
“check local references” This assumes you have an updated ds.nlm version.
If youdo
not, you will not see “check local references” leave the defaults,
and run the repair .
3.
After running the repair, save the database and reboot the server, this time
without any startup parameters.
cause processor information in monitor to be recalculated. Remember also, that
monitor is reporting once a second something that is happening in the
nanosecond range. Some server processes call a NetWare function called
CyieldWithDelay or CyieldUntilIdle. If there is a thread spinning on one of
these functions, the server will appear to have high utilization. Utilization
will then
be inaccurate.do
n’t panic when utilization goes to 100% for a few
seconds and bouncesdo
wn. This is normal for all 4.1x servers. Obviously
monitor is only reporting a snapshot of the utilization at some instant in time.
The NetWare OS is nonpreemptive for performance reasons. Because it is
nonpreemptive the NetWare OS relies on NLM writers to correctly yield the
processor at the appropriate times. This means that a poorly written NLM can
have disastrous effects on server utilization. You should never put an unproven
NLM on a production system.
If you are running NetWare 4.0, 4.01, or 4.02, move to NetWare 4.10 or 4.11.
Reason? Most of the fixesdo
ne for high utilization have been implemented for
NetWare 4.10 and 4.11 only. All development for previous versions of NetWare 4
has stopped;
NetWare 4.10 and 4.11 are the only 4.x Operating Systems where
Novell continues development. There are patches for the other versions of the
OS, but they are not as current anddo
not have the resources dedicated to
them at Novell like NetWare 4.10 and 4.11do
. If you cannot upgrade from
NetWare 4.0x, ask Novell Technical Services for the patches specifically for
the operating system, and follow this guide;
your solution may still be in
thisdo
cument.
Be sure that LAN and disk drivers are the current available from the hardware
vendor. Many vendors have found problems with their lan and disk drivers and
will periodically update these drivers. It is important to be at the latest
version of these drivers unless asked to back rev by technical support.
At the server console, type speed There have been cases where a system board
will drop the processor speed after boot up. A typical speed reading might be:
486/66 @ 1800, Pentium 90 @ 3300, and Pentium Pro 200 @16,500. A speed rating
drastically lower then
the expected value may indicate some sort of
configuration or BIOS problem, and can be a significant contributor to high
utilization. The NetWare OSdo
es not have a setting that affects the processor
speed.
7. When utilization problems occur, eliminate as many variables as possible.
Remove non-essential products until the server is in a vanilla state. This will
help determine if there is a problem with a loaded module. This is like
troubleshooting an abend, i.e., take the server to a stable platform, and then
add back nlm’s until it becomes unstable.
This is an important step OFTEN overlooked (sometimes because it is so time
consuming, and production servers oftendo
not accord this type of flexibility
in troubleshooting). Basically this step in the troubleshooting process is
trying to determine if a piece of software is causing the high utilization.
So, unload EVERY piece of software on the server. Usually customers will start
with the non-essential pieces of software;
non-essential means that the server
and the users can function without this piece of software being loaded.
Examples of software items to unload would be: ManageWise, virus scanners,
server metering nlm’s, backup solutions, UPS software, Compaq Insight Manager,
etc. Many nlm’s will autoload other nlm’s at the server, and so by merely
unloading a specific nlm, thatdo
es not completely remove the program from
memory. If possible, rem out the loading of the nlm’s in the autoexec.ncf file,
and then
restart the server. This will ensure a vanilla environment to work
with.
After the non-essential nlm’s are unloaded, and if the utilization remains,
schedule time to unload the other nlm’s that are more essential to the
operation;
i.e., NetWare Connect, NetWare/IP and anything else
that could not
be unloaded before because of the production status of the server.
The idea here is that if the high utilization is based upon software, it will
be found by comparing the state of the server with the software loaded and
without the software loaded.
8. Go to monitor | Processor Utilization | <F3> and see if there is any one
process that is hogging the CPU. It is possible to have 2-3 contributors to
high utilization, but usually only one, and sometimes two. FYI: AES stands for
asynchronous event scheduler.
If after pressing <F3> a single process can be seen that is hogging the CPU,
and it is a known NLM for a program running on the server, remove it (unload
it from the server console). For instance, if program XYZ is running and module
xyz.nlm shows 75% of the processor utilization, unload it. This should
IMMEDIATELY help the situation on the server. If the utilization stilldo
es
not drop afterwards, and there is no module in processor utilization that shows
a high amount of load on the processor, the server will probably need to be
bounced and the xyz.nlm module not loaded for a testing period of time. This
may happen because the server is trying to catch up with cork-to-do in its
queue. So wait for a little while first, and then
do
wn the server if nothing
else
works. There have been situations where unloading the offending module(s)
has caused the server to abend, so be prepared for this eventuality. For
NetWare 4.10 an abend means a complete stop on the server. For NetWare 4.11,
depending on the type of abend, the server may still be useable. If you are
running NetWare4.10, and the server abends trying to unload a module go into
the debugger and try to put this offending?thread to sleep. If you cando
this,
then
the server can probably be broughtdo
wn safely without having to power
down. See Extra Troubleshooting Tips #7 at the end of thisdo
cument for help
with the NetWare debugger.
If the server is running, butdo
es not allow access to the console so the
administrator can typedo
wn get a copy of Fconsole (this is a NetWare 3.x
utility). Fconsole will allow a remote connection to the server todo
wn it.
If you need to get this utility, it is in Tabnd2a.exe on the internet
(http://support.novell.com).
Many high utilization issues deal specifically with NCP Requests taking the
majority of the processor load. This is noticed on the processor utilization
screen (in monitor). NCP stands for NetWare Core Protocol. This is the
communication protocol between applications and the server. It is NetWare.
You cannot turn off NCP packets, nor would you want to. All file and print
requests are carried via NCP. If NCP is your problem, any number of problems
could exist on the server. These problems are all talked about here in this
do
cument. There is not A single fix for NCP Requests taking the majority of
the processor load. This statistic is just the outward appearance of a problem
on the server that must be found through troubleshooting. NCP problems have
been seen in a number of areas, of few of which are: lan problems, DS problems,
and client 3rd party software problems.
9. Too few service processes or too few packet receive buffers available will
almost always cause high utilization. Server resources can be divided into Lan,
Disk and Processor resources. Lan and Disk resources are the number of buffers
available, while Processor resources are the number of Service Processes
available. As a network packet arrives or a disk read or write isdo
ne, there
should be a buffer available for the data. If there is a buffer available,
there should be a Service Process available to deal with it. Running out of
any one of these for more than a brief period will cause high utilization and
will delay response from the server for the users. Novell suggests that the
parameters below be set as indicated to help prevent utilization problems.
If youdo
not have the ram todo
this, you will know immediately after
restarting the server. Your cache buffers will drop below 40%.
Here’s an explanation of the above set parameters:
Minimum directory cache buffers: The number needs to be high enough that
directory searches can bedo
ne quickly, but no higher than necessary because
these buffers cannot be reallocated for file caching once they are allocated
for directory caching. We suggest that 2 to 3 per connection is a good rule.
Maximum directory cache buffers: This parameter keeps the system from
allocating too many directory cache buffers so that memory is available for
other server processes. Increase this limit if the server responds slowly to
directory searches. Decrease this limit if too much memory is being allocated
for directory searching.
Directory cache allocation wait time: During this time, all requests for a new
directory cache buffer are ignored. If the wait time is too low, peak usage
requests cause more resources than necessary to be allocated to directory
caching. If the wait time is too high, the system is very slow in allocating
the directory cache buffers necessary to service the usual number of directory
requests. If directory searches seem slow even after the server has been
running for 15 minutes, you may want to decrease this parameter.
Minimum packet receive buffers: This parameters should be set at 2 to 3 times
the amount of connections the servers has (users, servers, printers, etc.).
The operating system will allocate this number immediately upon booting.
Maximum packet receive buffers: This set parameter performs the same type of
task that maximum directory cache buffersdo
es, except that it is for packet
receive buffers. Packet receive buffers are used to transfer a packet from an
ECB (lan packet) to a service process.
New packet receive buffer wait time: This parameter specifies how long the
operating system will wait after receiving a request for a packet receive
buffer before granting a new buffer. This parameter prevents the system from
granting too many buffers during a sudden peak in usage.
Minimum service processes: Specifies the minimum number of service processes
the operating system can create without having to wait for the time specified
by the New Service Process Wait Time parameter.
Maximum service processes: Specifies the maximum number of service processes
that the operating system can create. Increasing this number helps only if more
than 20 requests are being delayed simultaneously for a disk I/O to be
completed.
New service process wait time: Specifies how long the system should wait to
make an allocation when it receives a request for another service process.
If the settings on these parametersdo
not make sense, baseline the server and
see where the directory cache buffers, packet receive buffers, and service
processes are look on the main screen in Monitor.nlm. These numbers will be
your minimums. Set your maximums accordingly (i.e., higher than the minimums).
If the maximums for these parameters are reached, the server will experience
high utilization because it cannot allocate resources to handle user requests
for service. The suggestion would then
be to set the maximums far enough above
the minimums so that thisdo
esn’t happen. After changing these settings, the
server must be rebooted for some of the minimums to take effect.
10. On large systems servicing over 1000 users there have been cases where
file service processes (FSPs) were not being allocated fast enough by the
server, resulting in 100% utilization. Novell has released an NLM to
preallocate file service processes when the server is first booted so that
this particular problem is solved. This nlm is called WORKTHRD.NLM. There is a
separate version of this nlm for NetWare 4.10 and NetWare 4.11. In other words,
the 4.10 version of the nlm will not work with NetWare 4.11, and vice-versa.
Both of these files are included in the highutl1.exe file in the
self-extracting file called wrkthd.exe. After extracting this file, there
will be two new directories created (410 and 411) with a workthrd.nlm in each
directory. Copy the nlm to the c:/nwserver directory (or whatever directory
server.exe is located in).
NetWare 4.10 use: Place the following command in the startup.ncf file
immediately AFTER the loading of the patches:
LOAD C:/NWSERVER/WORKTHRD.NLM <# of service processes to pre-allocate ... 500
is a good no.> SET MAXIMUM SERVICE PROCESSES = < MAX NUMBER>
NetWare 4.11 use: Place the following command in the startup.ncf file
immediately AFTER the loading of the patches:
PMLOAD C:/NWSERVER/WORKTHRD.NLM <# of service processes to pre-allocate ...
500 is a good no.> SET MAXIMUM SERVICE PROCESSES = <MAX NUMBER>
The MAX NUMBER is the maximum number of service processes you wish to allow.
Workthrd.nlm preallocates service processes up to the maximum of 1000. Set the
minimum file service processes to the same number that workthrd.nlm
pre-allocates. On a 4.10 server if 410PT3 or later is not applied, the maximum
number of service processes will be 100. NetWare 4.11 comes standard with
1000 maximum service processes.
Each File Service Process that is pre-allocated will consume 16 K of memory.
do
ing the math, 1000 FSPs will then
consume 16 MB of memory. Be careful about
pre-allocating FSPs if memory is tight.
11. Set upgrade low priority threads=OFF This is off by default in
NetWare 4.1x, make sure it hasn’t changed. There are some 3rd party
applications that run on NetWare servers that request you set this parameter
to on. Be careful.
This one set parameter can be responsible for high utilization on a server.
The reason for this is because by setting this to on, ALL low priority
threads then
have the same light to the processor as every other normal
priority thread. This means that compression, sub-allocation, and any other
low priority thread will battle your users for CPU cycles whereas normally,
they would wait until there is a free cycle. Normal priority threads should
not have to wait for a normally low priority thread to finish processing, i.e.,
do
not set this parameter to on unless you know exactly what ramifications it
will cause.
Sometimes a server will report: an nlm has been loaded thatdo
es not allow low
priority threads to run. Low priority threads are used for compression, ... etc.
Set upgrade low priority threads = ON or unload the nlm. If an NLM has a
thread that is rescheduling frequently, this will cause this message to occur.
If this message continues to appear on the server console, a process is not
releasing the CPU for an extended period of time. This can be an indicator of
a high utilization situation. The problem with this message is that it never
displays the actual nlm that is causing the problem on the server. To fix this
use the set parameter “set display relinquish control alerts = on” If a
module uses the processor for more than 0.4 seconds without relinquishing
control to other processes, the following types of messages occur:
<process name> Process did not relinquish control frequently.
Module: <module name>
Code offset in module: <memory address>
This will identify the module that is hogging the CPU so that it can be
unloaded and further troubleshooting steps can be taken.
Sometimes this message is seen when the server is first brought up, and
sometimes after ds.nlm is loaded. If this error runs repeatedly on the screen,
or if you suspect DS database corruption,do
the following:
1.
Bring the server up with “server –ndb” or “server –ndb” in the case of
SFTIII.
2.
Run DSREPAIR. In a ONE SERVER environment, choose the unattended full repair
option. If there are multiple 4.x servers, choose: Advanced Options
menu / Repair local DS database and mark everything NO except
“check local references” This assumes you have an updated ds.nlm version.
If youdo
not, you will not see “check local references” leave the defaults,
and run the repair .
3.
After running the repair, save the database and reboot the server, this time
without any startup parameters.
]