Novell 3.12: Insufficient memory when mounting new volume
Jan V.
a Pentium 166 with 96 mb ram
Until now I've used a 3.2 Gb IDE harddisk, but I'm running out of space.
Right now I have 3 volumes.
So now I've mounted a 6.4 Gb IDE harddisk and its working fine. I can create
new volumes on the new drive, but when I try to mount them, I get the
message "Insufficient memory avaible to mount volume"
Just for a test I tried to mount 256 Mb ram and Novell has found them
(REGISTER MEMORY ....), but the message is the same.
Does anybody have a solution ???
Jan Vennike
Dave Lunn
I suspect that you really don't have the memory in use by Netware.
When you go to the Console and type memory what comes back?
96 meg should be plenty for the disk you are trying to support. If it shows
less than 96 wwhen you type memory at the console then you probably have a
memory manager loaded in config.sys (remove it). or you have booted with W9x
DOS (Use DOS 3.3->Novell DOS 7
--
Dave Lunn
NSCV Sysop
http://support.novell.com
Jan V. <j...@miljodata.dk> wrote in message
news:ePpa8.1808$qE4....@prv-forum2.provo.novell.com...
Jan V.
nearly empty.
And Monitor shows all 256 mb.
But I found somethind I will try, next time I can down the server (in the
morning)
Try to register memory before I load ISADISK. Then I have to load ISADISK in
AUTOEXEC.NCF, since you can't register memory in STARTUP.NCF. To reach
AUTOEXEC.NCF before I load ISADISK, I will have to put AUTOEXEC.NCF in the
same directory as STARTUP.NCF. It was a solution I found somewhere out
there.
I'll be back with a report, succes or not
Jan Vennike
"Dave Lunn" <dl...@NOSPAMusgo.net> skrev i en meddelelse
news:dxua8.1992$qE4....@prv-forum2.provo.novell.com...
Dave Lunn
If your machine is reporting the memory now registering memory will not make
a difference.
You should be using IDE.DSK with either of those drives. ISADISK.DSK is not
for over 528 meg. It would be better to patch this server up to date and
use IDEATA.HAM drivers.
I don't think that ISADISK.DSK drivers are the cause of a memory problem,
but you might well be running into mounting problems being misreported
because you are using the wrong drivers.
You can safely go to the console and do load edit and specify
c:\server.312\startup.ncf and change the driver to IDE.DSK. The port and
IRQ will remain the same.
Were this my machine I would do this now, and then kick the users off for
five minutes and reboot. You have a serious situation which may result in
the disk not putting info where you and it think it is putting it.
If you can mount the new volumes and memory reports OK you are good to go
without concern for address problems on the disks. I would still strongly
urge you to patch the machine to date and use the IDEATA.HAM drivers for the
disks though.
Dave Kearns-NSCV
server sees all RAM, you should be fine. If not, make sure you are
patched up to date (see
http://support.novell.com/filefinder/147/index.html). Then re-boot
again. If you still can't see all of the RAM, let us know...
--
Dave Kearns
Novell Support Connection Volunteer
Felton Green (SysOp)
Sounds like you're behind on updates.
Use IDE.exe drivers (you can get it from the download area)
Run the lib312d.exe update and then try it again. You may wind up applying a
bunch of patches.
--
Felton Green (SysOp)
Novell Support Connection
Brainshare is coming!
March 17 - 22, 2002
Salt Lake City, Utah
The Salt Palace Convention Center
The worlds finest networking convention is coming
Barry Schnur
>
Barry Schnur
Novell Support Connection Sysop
Please post replies ONLY via the Newsgroup
Felton Green (SysOp)
there. %%^ )
--
Felton Green (SysOp)
Novell Technical Forums Support
Brainshare is coming!
March 17-22, 2002
Barry Schnur
NWPAUP1A.EXE during the install, if you jump through some hoops.
Felton Green (SysOp)
Don't know since I've not tried it that way. What I did was to download ALL
of the updates and break them down to C: drive, sys and the ones that
require an install. Then I broke out the SYS vol and zipped them to the C:
drive. What it amounts to is a bootable CD with dos 6.22, netware.312,
server.312, \32enh and driver directory...
Boot with CD, sys and then xcopy the contents to the drive. Launch
server.exe [which is not on the CD BTW] and I'm off and running. I can
build a server in 45 minutes tops...
or I can use ServerMagic... %^ )
Barry Schnur
2940U2W with the boot drive running off of this controller.
Dave Lunn
remember just what now.
With the 4.10 patches which are more or less the same I can take a server
from base install through 410pt8 in about twenty minutes now. I will get
you a CD next burn. I screwed up the 410pt8 patch on the last one.
Felton Green (SysOp)
now...
Felton Green (SysOp)
like the isa drivers can't handle it....
Barry Schnur
>like the isa drivers can't handle it....
Exactly. Also, I get a tad nervous with a driver shift from ISADSK.DSK or
IDE.DSK to IDEATA.HAM *after* a drive has set up in NetWare.
Barry Schnur
My read is replace the adaptec drivers with the IDEATA drivers.
Steps that change here would be 6, 15, 16, 19.
Installing the AHA-2940U2W as the Primary Host Adapter and NetWare 3.12 for
the first time.
1. Create the DOS partition and/or install DOS from the Setup diskette.
2. If installing from an IDE based CD-ROM, install the CDROM DOS drivers.
3. Reboot your system
4. Start the NetWare 3.12 installation from the CD.
(i.e., D:\netware.312\english\install [or whatever letter MSCDEX
assigns to your CD-ROM])
5. After NetWare installs the DOS portion of the software, DOWN and
EXIT to DOS from the server prompt.
6. Copy the AIC78U2.HAM and AIC78U2.DDI from the 7800 Family Manager
Set Lite NetWare directory to the C:\server.312 directory.
7. Obtain the NWPA_UP.EXE patch from the Novell Web site
http://developer.novell.com/devres/sas/certinfo.htm
8. Change directory to c:\server.312, and copy the patch file
NWPA_UP.EXE to the directory.
9. Execute NWPA_UP.EXE (note: this will create another file,
312PTD.EXE. Answer 'Y' to the prompt to overwrite CDROM.NLM.)
10. Execute 312PTD.EXE.
11. Create the directory c:\server.312\CDSAVE
12. Copy CDROM.NLM to c:\server.312\CDSAVE
13. Update the server with the following command
c:\server.312\312PTD\native\loader\lswap<space>c:\server.312\
312PTD\native\loader\loader.exe<space>c:\server.312\server.exe
14. Type Server from the prompt. Type the server name and IPX address
15. From the console prompt
load c:\server.312\312PTD\native\start\npapatch
load mmattrfx
load nbi31x
load c:\server.312\AIC78U2
16. Note the slot number detected for the AIC78U2W adapter. This will
be added to the Startup.ncf load AIC78U2 statement to automate driver
load using the parameter SLOT=x (x is the detected slot number).
17. Load Install. Create the NetWare partition, SYS volume, and mount
the volume. Complete the installation of the System and Public Files.
18. Create the Autoexec.NCF file. Add the following lines and save
load after311
search add 1 c:\server.312\cdsave
load cdrom
19. Create the Startup.NCF file. Edit the AIC78U2 command line to add
the slot=x parameter. Delete the MEM and INT parameters inserted
by Novell.
20. Load, from the command line, the following
load c:\server.312\312PTD\patch312
21. Install the patches from the c:\server.312\312PTD directory when
prompted for a path.
22. DOWN and EXIT the server
23. Run Server.EXE
24. Installation of the AHA-2940U2W for NetWare 3.12 is complete.
Note: If you have problems with memory registration issues and are
unable to mount the system volume, please refer to the document
Above16.txt at ftp://ftp.adaptec.com/pub/BBS/netware/above16.txt.
Jan V.
"Dave Lunn" <dl...@NOSPAMusgo.net> skrev i en meddelelse
Well, my method worked.
But will IDEATA.HAM help the performance ??? What I need right now is to get
some more performance out out this small server.
Jan Vennike
Dave Lunn
A couple of things.
If you have the two IDE drives on the same channel your performance will be
no better than the slowest at best. The 3.2 gig is probably a PIO 4 so it
should match the 6.4 gig.
Second, 96 meg shouldn't be insufficient nor drag performance down, even
with additional name spaces loaded. *Unless* you are moving a *very* large
amount of data back and forth and printing a lot of big jobs. In which case
you need to move to a decent SCSI setup pronto. In fact, that you have been
running exclusively out of a 3.2 gig drive up to now tells me this cannot
possibly be the case unless you haves a really screwy situation. With 256
Meg RAM this machine ought to be feeding the WSs almost exclusively out of
cache in almost any situation and certainly so if you're more like a normal
office.
That brings us to the third point. If you have poor performance and *do
not* have a 10base2 (coax) network, then it almost certainly is from the
ISADISK.DSK driver being used in that configuration. I have tried a couple
of times to use ISADISK.DSK with a 6.4 gig drive. It flat out wouldn't work
and I couldn't partition the drive. If you have somehow got that driver
working with you may very well be seeing horrible disk performance because
the addressing is all hosed. This should be taken as a sign that you are at
risk of losing your data if it is the case. Under no circumstances should
you be using ISADISK.dsk drivers with those drives, whether it looks like it
works or not. IDE.DSK will work. IDEATA.HAM is what you want. There
should be no performance difference between IDE.DSK and IDEATA.HAM
If you are using coax, then switch it to Cat5 and get a pair of small
switches to feed the server and your performance problems will be history.
Jan V.
"Dave Lunn" <dl...@NOSPAMusgo.net> skrev i en meddelelse
I will try the IDEATA.HAM.
Thanks
Jan Vennike
Felton Green (SysOp)
This solution covers the various areas to optimize your server's
performance. It also looks into areas of pro-active preventive maintenance
on your server and how to achieve the best results. These actions taken
also prevent the possibility of server abends and crashes.
The following areas are covered:
1. MONITOR.NLM and Utilization
2. Operating System Patches and Other NLM updates
3. NDS and DS.NLM
4. Service Processes
5. Upgrade Low Priority Threads
6. LRU Sitting Time
7. Physical Packet Receive Buffers
8. Packet Burst
9. Cache Buffers
10. Dirty Cache Buffers and Current Disk Requests
11. Host Bus Adapters, Mirroring and Duplexing
12. Directory Caching
13. Block Suballocation
14. Disk Block Size
15. Hotfix and Redirected Blocks
16. Suballocation and the Number of Free Blocks and Disk Space for Each
Volume
17. File Compression
18. File Decompression
19. Read After Write Verification
20. Garbage Collection
21. Read/Write Fault Emulation and Invalid Pointers
22. Interrupt Allocation and Configuration
23. Set Reserved Buffers Below 16 Meg
24. AppleTalk
25. Printing
1. MONITOR.NLM and Utilization
The Monitor utilization is not an entirely accurate number. 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. Don't panic when utilization goes to 100 percent for a few
seconds and bounces down. This is normal for all 4.10 servers.
2. Operating System Patches and Other NLM updates
Apply the patches from BOTH 410PTx.EXE and 410ITx.EXE. These patches fix
problems that resulted in high utilization and other issues. These patches
also fix a variety of additional problems. Loading all of the patches will
reduce your chances of having future problems.
For IntranetWare or NetWare 4.11, use the support packs by the file name
IWSPx.EXE. For NetWare 5, use the NW% support packs by the file name
NW5SPx.EXE. Support packs contains not only OS patches but all the
necessary updates and enhancements to the server NLMs. (Current version, at
the last update of this TID, of NW410 patches is 410PT8B.EXE and Service
Pack is IWSP6.EXE.
OS patches fixes issues with the SERVER.NLM or LOADER.EXE. There are also
other fixes in new updates to NLMs released (e.g. CLIB.NLM) which resolves
other issues, that can pertain to high utilization. The new updates also
adds enhancements to the current versions. It is advised to always apply
the latest updates to your server as well.
Please refer to support.novell.com web page for the latest patches and
updates. It is recommended to apply all the latest patches and updates
specified in the minimum patch list found in
<@@http://support.novell.com/misc/PATLST.HTM,
http://support.novell.com/misc/patlst.htm@@>.
Also, apply the latest LAN and Disk drivers from your hardware vendor.
3. NDS and DS.NLM
Use the Latest DS Versions, current version are DS.NLM 5.15 for NW410,
DS.NLM 6.10 for NW411, DS.NLM 7.47 for NW5.X Recman Database and DS.NLM
8.59 for NDS. See for NDS8 Performance Issues: Document ID:10023867 NDS 8
Performance is poor. Cache Problem.
Efficient tree design, partitioning and replication is essential to avoid
utilization problems. The size, type and number of partition replicas can
cause utilization problems if not managed properly. Check also the total
number of NDS objects residing in the partitions of that server. DS needs
to keep synchronization among all servers in the replica ring. The more
replicas there are of any partition, the more traffic will be on the wire.
Novell recommends having at least three replicas of each partition in the
tree. This provides fault tolerance and allows for DS recovery if a
database were to become corrupt.
4. Service Processes
Service processes are threads of execution that act as hosts to incoming
service requests. NetWare 4.X is capable of allocating up to 1000 service
processes. Set maximum service processes to 2-3 per connection. It is
recommended to set the Maximum Service Processes to 1000 (the maximum
number allowed). If the server does not require an additional service
process, it will not allocate. You can also set new service process wait
time to 0.3 (default is 2.2).
Refer to <@@http://support.novell.com/cgi-
bin/search/PATLSTFIND.CGI?2941108, HIGHUTL1.EXE@@> for more info on Service
Processes and also on how to immediately increase the number of service
processes to your desired value.
5. Upgrade Low Priority Threads
Verify that SET UPGRADE LOW PRIORITY THREADS is set to OFF. If it is ON it
will contribute to any utilization problems the server may be having. This
parameter does not apply in NW5 servers.
6. LRU Sitting Time
NetWare's file caching subsystem is a pool or collection of 4 KB memory
pages. After loading the OS, system NLMs, and application NLMs, NetWare
initializes all remaining memory as the file cache pool. At the beginning
of the list is the "list head," where new cache buffers are inserted into
the list. The end of the list is the "list tail," where old cache buffers
are removed from the list. Each cache buffer in the list is linked to the
next cache buffer, and each one includes a time stamp indicating the time
the cache buffer was inserted into the list head.
When the server receives a disk I/O request for data that is not currently
in cache (a cache "miss"), the data is read from the disk and written into
one or more cache buffers that are removed from the list tail. Each newly
filled cache buffer is time-stamped with the current time and linked into
the list head. A newly filled cache buffer is designated as the most-
recently-used (MRU) cache buffer because it has resided in cache for the
least amount of time.
A cache "hit" a frequent event in NetWare environments occurs when a disk
request received by the server can be serviced directly out of cache,
rather than from disk. In this case, after the request is serviced the
cache buffer containing the requested data is removed from the list, time-
stamped with the current time, and relinked into the list head. In this
manner, MRU cache buffers congregate at the head of the list. This
characteristic of the list is important to understand, because you want
your MRU cache buffers to remain cached in anticipation of repeated use and
repeated cache hits.
At some point in this process, the file cache pool becomes full of recently
used data. This is where the least-recently-used (LRU) cache buffer comes
into play. LRU cache buffers are buffers that were originally filled from
the disk, but haven't been reused as frequently as the MRU cache buffers at
the list head. Due to the relinking of MRU cache buffers into the list
head, LRU cache buffers congregate at the list tail. When new cache buffers
are needed for data requested from disk, NetWare removes the necessary
number of LRU cache buffers from the list tail, fills them with newly
requested data, time-stamps them with the current time, and relinks them
into the list head.
The resulting NetWare file cache subsystem gives preference to repeatedly
used data and holds onto less frequently used data only as long as the
memory isn't needed for repeatedly used data.
When tuning file cache, then, the ideal scenario is one in which every
repeated use of recently accessed data can be serviced out of cache. This
is accomplished by sizing server memory so that the resulting file cache
pool is large enough to retain all repeatedly used data.
The LRU Sitting Time statistic is calculated by taking the difference
between the current time and the time stamp of the LRU cache block at the
tail of the cache list. LRU Sitting Time measures the length of time it is
taking for an MRU cache buffer at the list head to make its way down to the
list tail, where it becomes the LRU cache buffer. One might refer to this
measurement as the cache "churn rate" because, whether from cache hits or
misses, every cache buffer in the list is being reused within that period
of time. Check that the LRU Sitting Time does not go below 15 minutes. If
it drops below 15 min, you may need to add more memory.
7. Physical Packet Receive Buffers
Receive buffers are used to store incoming packets from each of the
networks attached to a NetWare server. The Maximum Physical Receive Packet
Size should be set according to the kind of network it is on. In most
cases, this is 1524 bytes for Ethernet segments (NOTE: this may cause a
problem with some Intel based LAN cards. Please check with the manufacturer
or the documentation that came with the card), 4540 bytes for Token-Rings
and FDDI and 618 bytes for Arcnet and LocalTalk. These values are taken
from the "Novell BorderManager Installation and Setup" manual, the chapter
on "Installing Novell BorderManager", page 9. Certain products installed
have specific requirements in which you will need to refer to your manuals
for instructions.
A good rule of thumb for the minimum packet receive buffers setting is
approximately 2-3 receive buffer for each connection and maximum packet
receive buffers to 4000 (or any higher value).
Also, check the No ECB (Event control block) Available Count information in
the LAN/WAN Information option in MONITOR.NLM. These messages indicate that
the server was unable to acquire sufficient packet receive buffers, usually
called event control blocks (ECBs). Running out of ECBs is not a fatal
condition. Servers that run for several days where high loads occur in
peaks might exceed the set maximum number of ECBs, causing the system to
generate ECB system messages. If these situations are caused by occasional
peaks in the memory demand, you should probably maintain your current
maximum ECB allocation and allow the message to be generated at those
times. On the other hand, if your server memory load is very high and you
receive frequent ECB allocation errors, you should probably set your
maximum ECB allocation higher. Use the following SET command in the
AUTOEXEC.NCF file: SET MAXIMUM PACKET RECEIVE BUFFERS = number
Note that the memory allocated for ECBs cannot be used for other purposes.
The minimum number of buffers available for the server can also be set in
the STARTUP.NCF file with the following command: SET MINIMUM PACKET RECEIVE
BUFFERS = number.
If the current Packet Receive Buffers rises above the minimum set level
after the server has been up for a period of time, set the minimum Packet
Receive Buffers to the current level.
8. Packet Burst
Novell support has seen high utilization problems caused by packet burst
from both NetWare and Microsoft requester clients. Most of these problems
have been solved with an OS patch or a new requester. Load the 410 OS
patches and get the new FIO.VLM which fixes the problem with the Novell
requester. The file is VLMFX3.EXE on the Internet. (Current version of VLM
is 1.21)
Troubleshooting:
Novell technical support has a module called PBRSTOFF.NLM that will disable
Packet Burst from the server. The module needs to be loaded when the server
comes up. Only connections that are established after the module is loaded
will have packet burst disabled. This will isolate utilization problems
related to packet burst.
9. Cache Buffers
When the server boots, all free memory is assigned to file caching. As
demand increases for other resources (e.g. directory cache buffers), the
number of available file cache buffers decreases. The operating system does
not immediately allocate new resources when a request is received. It waits
a specified amount of time to see if existing resources become available to
service the demand. If resources become available, no new resources are
allocated. If they do not become available within the time limit, new
resources are allocated. The time limit ensures that sudden, infrequent
peaks of server activity do not permanently allocate unneeded resources.
The following parameters are dynamically configured by the operating
system.
Directory cache buffers
Disk elevator size
File locks
Kernel processes
Kernel semaphores
Maximum number of open files
Memory for NLMs
Router/server advertising
Routing buffers
Service processes
TTS transactions
Turbo FAT index tables.
As a rough guideline, if the amount of cache buffers (checked from
MONITOR.NLM, Resource utilization) drops below 40%, more memory should be
added to the file server. This percentage rule has been commonly used for
many years when the average system had 16MB to 32MB, and most systems
nowadays have more cache buffers (in terms of percentage) available. An
example is that 40% of 32MB is 12 MB, while 40% of 1024MB is 409 MB.
In most cases, impact to performance can be seen when the amount of cache
buffers drops below 40%. The percentage value is calculated from having
total cache buffers divided by the original cache buffers. The total cache
buffers and original cache buffers can be found at the General Information
screen of the MONITOR.NLM. Please refer to the March 1997 AppNotes on
Optimizing IntranetWare Server Memory.
A brief note on fine tuning:
As resource (e.g. memory) on every server is limited (until more memory is
added), the whole task of fine tuning a server is to find a balance between
the limited resource with the server response to the workstation. Take an
example of a server with only 64MB of memory. If I allocate more cache for
directory cache buffers and packet receive buffers, this will reduce the
amount of total cache buffers used for file caching. By over allocating the
amount of other resources that consume memory would reduce the amount of
memory for file caching, and hence slowing down the server rather than
speeding it up. For this example, a balance of an adequate amount of
directory cache buffers and packet receive buffers, giving enough total
cache buffers for file caching, would give a better server performance than
if there is insufficient directory cache buffers or too many directory
cache buffers (taking into consideration the current limited resource on
the server).
10. Dirty Cache Buffers and Current Disk Requests
If the Dirty Cache Buffers and Current Disk Requests (as seen from the
MONITOR screen) is high, it means that the number or dirty cache waiting to
be written to disk, and the number of pending disk requests (reading from
disk) is high.
You can set the Maximum Concurrent Directory Cache Writes (default of 10),
the Maximum Concurrent Disk Cache Writes above the default value (default
of 50). You can also set the Dirty Disk Cache Delay Time to a value below
the default (default of 3.3 Sec).
You can adjust the settings till the values of dirty cache buffers and
current disk requests goes to 0 periodically. The values should go in
bursts and return to 0. If after making adjustments and the dirty cache
buffers and current disk requests are still high, it would mean that your
disks cannot handle the load. It would then be advisable to either change
to faster disks or to split the server load up. Often times, the disk is
one of the common bottlenecks.
You may like to start with the following settings and fine tune
subsequently:
SET Maximum Concurrent Disk Cache Writes = 500
SET Dirty Disk Cache Delay Time = 0.5
SET Maximum Concurrent Directory Cache Writes = 100
11. Host Bus Adapters, Mirroring and Duplexing
While configuring multiple devices, it is advisable to put slow devices on
a different channel or host bus adapter from the fast devices. Slow devices
are like tape drives and CDROMs. Fast devices are like disk drives.
Also, always use hardware mirroring, duplexing or and form of RAID as
compared to software mirroring, duplexing or RAID. Software mirroring,
duplexing and RAID are slower than hardware mirroring, duplexing and RAID.
The speed of a server depends of various factors like the CPU, amount of
memory and the access speed of a harddisk. A sluggish access of a server
could be attributed to the harddisk. Check the "Dirty Cache Buffers" and
"Current Disk Requests" on the Monitor console to see if the harddisk can
handle the load of the access.
12. Directory Caching
Cache memory allocates memory for the hash table, the FAT, the Turbo FAT,
suballocation tables, the directory cache, a temporary data storage area
for files and NLM files, and available memory for other functions. The FAT
and DET are written into the servers memory. The area holding directory
entries is called the directory cache. The server can find a files address
from the directory cache much faster than retrieving the information from
disk.
Set minimum directory cache buffers to 2-3 per connection and maximum
directory cache buffers to 4000. You can also set directory cache
allocation wait time to 0.5 (default is 2.2). If the current Directory
Cache Buffers rises above the minimum set level after the server has been
up for a period of time, set the minimum Directory Cache Buffers to the
current level
NSS (Novell Storage Services), however, does not use Directory Cache
Buffers. For heavy access on an NSS volume may incur some performance
issues. NSS has it's own caching and parameters to be set during the
loading of the NSS modules. The following are parameters which tunes the
performance of NSS:
a. cachebalance
b. fileflushtimer
c. bufferflushtimer
d. closedfilecachesize
e. allocahead
"Cachebalance" controls how much memory is available for NSS to use
for cache. The default for SP2 is just 10%, so increasing it to 80% or 90%
puts us on a more level playing field with the legacy file system, which
gets 100% (unless NSS is loaded, in which case legacy gets the remainder -
90% if NSS is using default). This percentage should be set to the
percentage of total volume space taken from NSS volumes (i.e. 10GB FAT and
90GB NSS would be /cachebalance-90).
Increasing "fileflushtimer" and "bufferflushtimer" from their
defaults helps the caching up to a certain point, but if increased too much
causes a "throttling" problem with writing out the metadata. This is
somewhat dependent on processor speed and disk speed, so you could try
playing with them for your system. If NSS performance is really bad, 75
might be too high and you could try 50. If performance is just subpar, you
could try increasing them a little.
"Closedfilecachesize" dictates how many closed files are kept in
cache.
"Allocahead" is used to allocate extra blocks ahead of time in
anticipation of new files being larger than the 4k block size, which helps
performance with larger files but hurts performance with small files. Since
we know most of the files will be small, we turn off allocahead.
To activate these parameters, you can issue the following command
at the startup of NSS, or place it in the AUTOEXEC.NCF file:
nss /cachebalance=80 /fileflushtimer=75 /bufferflushtimer=75
/closedfilecachesize=8192 /allocahead=0
13. Block Suballocation
Suballocation is implemented in NetWare 4.X to overcome the problem of
wasted disk space due to under-allocated disk blocks (as described above).
Suballocation allows multiple file endings to share a disk block. The unit
of allocation within a suballocated block is a single sector (512 bytes).
That means that as many as 128 file ends can occupy one 64KB block. Using
suballocation, the maximum loss of data space per file is 511 bytes. This
would occur when a file had one more byte than could be allocated to a full
512-byte sector. Hence, suballocation nearly eliminates the penalty of
using larger disk allocation units and allows much larger disk channel
transactions.
From a performance standpoint, suballocation enhances the performance of
write operations within the OS by allowing the ends of multiple files to be
consolidated within a single write operation. Of course, this minor
improvement will often be counterbalanced by the increased overhead of
managing the suballocation process. The major win is the optimization of
the disk channel and cache around the 64KB disk allocation unit.
As imaging, multimedia, and other workloads involving streaming data become
more prevalent, the 64KB block size will become invaluable. We recommend
that everyone use the 64KB disk block size for greater efficiency,
elimination of wasted space, and to take advantage of read-ahead.
It is very important to load the patches when suballocation is enabled.
Suballocation does not have any SET parameters to adjust. Everything is
done automatically. It is very important to monitor the disk space to avoid
suballocation problems. Novell Engineering recommends keeping 10-20 percent
of the volume space free to avoid suballocation problems.
Suballocation uses free blocks to perform its function. When free blocks
are low suballocation could go into "aggressive" mode, lock the volume and
cause high utilization. Maintaining more than 1000 free blocks will avoid
this problem in most cases. If there are not at least 1000 free blocks on
the volume, run a PURGE /ALL from the root of the volume. This will free
the "freeable limbo blocks" and move them back to "free blocks."
14. Disk Block Size
Based on our performance testing, we recommend a 64KB block size for all
volumes. The larger 64KB allocation unit allows NetWare to use the disk
channel more efficiently by reading and writing more data at once. This
results in faster access to mass storage devices and improved response
times for network users. If you are using RAID5 disks, set the block size
equal to the stripe depth of the RAID5 disks.
15. Hotfix Blocks
Load SERVMAN, choose Storage Information, highlight the Netware Partitions
in the server. Make sure that there are no "Used Hotfix blocks" shown.
Also, you can "Load MONITOR", choose "Disk Information", choose the device,
hit <ENTER> and press the <TAB> key. You will see information on Redirected
Blocks. "Used Hotfix blocks" and "Redirected Blocks" show that there are
bad sectors on the server harddisk. You should prepare to change the
harddisks of the server.
16. Suballocation and the Number of Free Blocks and Disk Space for Each
Volume
It is also important to keep more than 1000 "free blocks" and at least 10%
to 20% free disk space on each volume with suballocation enabled.
Suballocation uses these free blocks to free up additional disk space. To
be warned on the number of free blocks available, you can set the Volume
Low Warning Threshold and the Volume Low Warning Reset Threshold to 1024.
High utilization issues can be caused by the lack of disk space.
Suballocation is a low-priority thread. This means that under normal
conditions, it only runs when the processor has nothing else to do and is
idle. This condition of suballocation is a "non-aggressive" mode. When disk
space is low, less than 10% available, suballocation can go into
"aggressive" mode. Suballocation is bumped up to a regular priority thread
and can take control of the volume semaphore until is has cleaned up and
freed up as much space as possible. This locking of the volume semaphore
causes other processes, who are trying to use the volume, to wait until the
semaphore is released. In large installations, the results in an increase
of Packet Receive Buffers and File Service Processes. When the Packet
Receive Buffers max out, the server will start dropping connections and
users are not able to login. When suballocation completes it's cleanup, the
semaphore will be released and the processes on the queue will be serviced.
This will result in a utilization drop and the server will return to normal
operation.
The lack of free blocks is different from a lack of disk space. When files
are deleted, they are kept in a "deleted" state. This means the file
actually exists but is not viewable to the user and does not show up in
volume statistics as used space. The number of free blocks is determined by
Free Blocks = [Total Blocks - (Blocks In Use by Files + Blocks In Use by
Deleted Files)]
Hence, you can have 50% of the disk available, but there are no free
blocks. These blocks are use by deleted files. If free blocks are low, run
a PURGE /ALL from the root of the volume to free the "freeable limbo
blocks" and move them to the "free blocks" pool. To avoid doing this often,
set the P (PURGE) attribute on directories that create a large amount of
temporary files. The P attribute does not flow down the file system. This
needs to be taken into consideration when setting the P attribute. Also,
setting IMMEDIATE PURGE OF DELETED FILES = ON at the server console will
avoid the Purgeable files taking all the "free blocks".
17. File Compression
It is essential to have the OS patches loaded when using compression.
Compression takes CPU cycles to compress and decompress files. The default
set parameters for compression take this into consideration. Compression is
designed to take place after midnight when most servers have little or no
traffic. Also, the DAYS UNTOUCHED BEFORE COMPRESSION set parameter is
designed to make sure frequently used files are not compressed. Any
adjustments to the default compression SET parameters may severely impact
the server's performance.
Users with disk restrictions may try to flag their home directory to IC
(immediate compress) to save disk space. Flagging directories to IC will
affect server performance. Normally, compression is a low priority thread,
which means it only compresses files when the server is idle. When the IC
flag is set, compression is bumped up to a regular priority and will not
wait for idle time.
Setting DELETED FILES COMPRESSION OPTION = 2 will cause the immediate
compression of files that have been deleted. This will cause high
utilization because the processor is immediately compressing files upon
their deletion.
Troubleshooting:
Eliminate compression as a possible problem by setting ENABLE FILE
COMPRESSION=OFF. This will cause files to be queued for compression but the
files will not be compressed. However, accessing compressed files causes
them to be decompressed. This will eliminate compression as the cause of
high utilization.
To view the amount of compression/decompression that is going on in the
server, do the following:
set compress screen = on
Hence, it is advisable to SET Days Untouched Before Compression to 30 days,
and SET Minimum Compression Percentage Gain to 20.
18. File Decompression
Decompression takes up CPU cycles as well. If you are running a volume near
full and compression enabled, files will be compressed and never committed
decompresses due to failure of allocating enough space on the disk to hold
the decompressed version.
This can be caused by "Minimum File Delete Wait Time" being set to a large
value, and thus not allowing any deleted files to be reclaimed for space to
commit a compressed file. The full volume situation is usually indicated by
the "Compressed files are not being committed" alert on the server console.
This message can be fixed by setting "Decompress Percent Disk Space Free To
Allow Commit" to a number less than the current one. However, you must
still remember that there must be enough space on the volume to allow for
decompressed version of the file to be committed in order for that file to
be committed decompressed.
As a file is decompressed, it does consume CPU cycles but it will
relinquish control to allow other threads and NCPs to be serviced. A
Pentium processor (60Hz) can decompress on average 1 MB a second.
19. Read After Write Verification
Read-after-write verification is an important means of protecting the data
on your system. Normally, you should not disable it. However, if your disks
are mirrored and reliable, you may choose to disable read-after-write
verification because disabling almost doubles the speed of disk writes.
Warning:
Turning off read-after-write verification may increase the risk of data
corruption on the servers hard disk. You should use the following procedure
only if your disks are mirrored and reliable, and you understand the risk.
20. Garbage Collection
The GARBAGE COLLECTION process is like a disk defragmenter for the
operating systems memory pool that is always running.
The purpose of the GARBAGE COLLECTION process of the operating system is to
reclaim used memory nodes for a new memory scheme. Garbage collection is
critical for situations where NLMs allocate small memory areas for
initialization purposes then allocate larger nodes to perform the rest of
its operation. Unless this smaller node memory is reallocated after the
program initialization frees itself from this area, the memory will become
fragmented and unusable. Therefore, the memory pool can become depleted
over time.
The operating systems internal routine that handles garbage collection
sorts all the nodes from the linked lists of an NLM and collapses them into
larger pieces. The larger pieces are linked to the appropriate list head.
If the garbage collection routine frees an entire 4 KB page, that memory is
returned to cache. This internal routine can be set or interrupted and runs
in the background.
Garbage Collection can be forced by a user through MONITOR. In NW4.11 under
Memory Utilization, any of the system modules loaded can be selected. After
it is selected, a user may press <F3> to collect garbage on that specific
module or press <F5> to collect garbage on the entire system. For NW5,
under Virtual Memory, Address Spaces, you can free address space memory
with <F4>.
Users whose systems are running low on memory or developers who are
optimizing their NLMs may need to adjust these parameters. If a NLM
allocates and deallocates large blocks of memory throughout the life of the
NLM, set the number of frees lower than the default. If a NLM does a lot of
memory allocations and frees, set the number of frees higher than the
default. If a NLM allocates and deallocates the same chunk of memory more
than once, set the minimum free memory to a value higher than the size of
the chunk.
Be aware that the Garbage Collection SET parameters are global; that is,
they will affect all NLM garbage collection. For this reason, great care
should be given in changing the default parameters. An adjustment for one
NLM to improve its performance may adversely affect another NLM. Novell
recommends leaving these parameters at their default unless a NLM requires
a specific change.
21. Read/Write Fault Emulation and Invalid Pointers
If NetWare detects a condition that threatens the integrity of its internal
data (such as an invalid parameter being passed in a function call, or
certain hardware errors), it abruptly halts the active process and displays
an "abend" message on the screen. ("Abend" is a computer science term
signifying an ABnormal END of program.)
The primary reason for abends in NetWare is to ensure the stability and
integrity of the internal operating system data. For example, if the
operating system detected invalid pointers to cache buffers and yet
continued to run, data would soon become unusable or corrupted. Thus an
abend is NetWare's way of protecting itself and users against the
unpredictable effects of data corruption.
NetWare 4 takes advantage of Intels segmentation and paging architecture.
Each page of memory can be flagged present or not present, read-protected,
write-protected, readable, or writable.
Exceptions caused by segmentation and paging problems are handled
differently than interrupts. Normally, the contents of the program counter
(EIP register) are saved when an exception or interrupt is generated.
However, exceptions resulting from segmentation and paging give the
operating system the opportunity to fix the page fault by restoring the
contents of some of the processor registers to their state before
interpretation of the instruction began. NetWare 4 provides SET parameters
to enable and disable page fault emulation, giving you the choice between
continuing program execution or abending.
On NW 4.x servers, the memory parameters "Allow Invalid Pointers", "Read
Fault Emulation" and "Write Fault Emulation" needs to be set to OFF before
analyzing a coredump or troubleshooting utilization or abending issues.
22. Interrupt Allocation and Configuration
Interrupts have priorities. The following is the order of interrupts from
the highest priority to the lowest priority - 0, 1, 8, (2/9), 10, 11, 12,
13, 14, 15, 3, 4, 5, 6, 7. Interrupt 0 is used for the system timer and 1
for the Keyboard Data Ready.
For SFTIII server, you have to configure the MSL card on the highest
interrupt, followed by the disk and the LAN card in that order.
"Edge triggered" interrupts may not be shared with another device but level
triggered interrupts may be shared with another device. When using "level
triggered" interrupts, only share the interrupt with exact types of
devices, e.g. 2 NE3200.LAN or 2 AHA2940 HBA devices. Do not share
interrupts with non-identical devices.
23. Set Reserved Buffers Below 16 Meg
This parameter specifies the number of file cache buffers reserved for
device drivers that can't access memory above the 16 MB. Memory address
conflicts can occur when you have more than 16MB of memory in a server and
the disk adapter uses 16- or 24-bit DMA or busmaster DMA. Hence, SET
Reserved Buffers Below 16 Meg = 200 in STARTUP.NCF.
24. AppleTalk
There was also a problem with the ATXPR.NLM causing high utilization. The
file 41MAC1.EXE contains the new version of ATXPR.NLM. The file 41MAC1.EXE
is found in the NOVLIB area LIB6. Use any newer update file when found.
(Current version for NW410 is MACPT3D.EXE)
25. Printing
Having a large amount of printers on a server can affect network
performance. This number depends on the type of printing that is being
done. Printing CAD/CAM designs take much more processor time than text
documents. It is recommended, if you are concerned about utilization
problems, that you set your print devices to do the processing instead of
the server. This will slow down printer output but will relieve the
utilization on the file server.
Reference Literature:
Novell Research
May 1993 - NetWare 4.0 Performance Tuning and Optimization: Part 1
June 1993 - NetWare 4.0 Performance Tuning and Optimization: Part 2
October 1993 - NetWare 4.x Performance Tuning and Optimization: Part 3
February 1995 - Resolving Critical Server Issues
March 1995 - Server Memory
April 1995 - MONITOR.NLM
June 1995 - Abend Recovery Techniques for NetWare 3 and 4 Server
November 1995 - Server Memory
March 1997 - IntranetWare Server Automated Abend Recovery
March 1997 - Optimizing IntranetWare Server Memory
TIDs:
TID14270 - NetWare 4.0 Memory Allocation - Part 1 of 2
TID14271 - NetWare 4.0 Memory Allocation - Part 2 of 2
TID1005436 - High Utilization and Suballocation
TID1005736 - Compression and High Utilization
TID1007561 - NetWare OS Patches
TID1005963 - Troubleshooting NetWare 4.1 High Utilization
TID1202046 - NetWare 3.x and 4.x Directory Entry Limits
TID2905856 - Additional Notes for High Utilization
TID2906943 - PC INTERRUPTS
TID10017179 - Suggestions for Troubleshooting Abend
TID10011977 - General Basic Requirements for SFT III
TID10024783 - 8259 Interrupts and NetWare
TID10057988 - High Utilization on 4.x/5.x Servers
Novell Press:
Novell's Guide to Resolving Critical Server Issues by Rich Jensen and Brad
Dayley
Others:
High Utilization by Rich Jardine, Product Support Engineer, NetWare OS
Support, Novell Inc. (28 Sep 95)
Suballocation by Rich Jardine, Product Support Engineer, NetWare OS
Support, Novell Inc. (1 Feb 96)
Compression by Kyle Unice, Novell Software Engineer (1 Feb 96)
FYI.P.12444 - What Does the Garbage Collection SET Parameter Do?
November 1993 - NetNotes
File Downloads:
HIGHUTL1.EXE - Troubleshooting High Utilization for NW4
TABND2A.EXE - Diagnostic programs / utilities to troubleshoot Abends
CONFG9.EXE - CONFIG.NLM and CONFGNUT.NLM to collect server configuration
CFGRD6B.EXE - The Config Reader, Internet Edition! (version 2.67)
Note: Kindly access the Novell Support Connection web site
(http://support.novell.com or http://support.novell.com.au) for all the
latest patches, fixes and file updates. You will also find a knowledge base
which accesses the latest Novell Technical Information Database (TID) to
help you be in-touch with the latest issues so that you can pro-actively
manage your servers and the network..