The picture of the 5 different address spaces in dashes represent
how the memory is divided up in the server. We will focus only on
the 3 main pools: Virtual Memory Cache Pool (VM Pool), File System
Cache Pool (FS Pool), User Address Space (UAS).
Virtual Memory
Cache Pool and the File System Cache Pool:Look at
the size of both pools. In most cases, the VM Pool should be
bigger. 95% of NLM's allocate memory from the VM Pool. So this
normally should be the biggest pool of the 3 main pools.
Total LP
Pages:If this number is > 0, it means that the
VM Pool is borrowing cache from the FS Pool. This is a condition we
want to avoid, so as above, making the VM Pool the largest will
help to avoid this condition.
Largest
Segment:This number in the VM Pool will not be
available on a 6.0 server. This represents the largest contiguous
block of cache that each pool has. It is not necessarily the entire
amount of free space that this pool has, as will be explained a
little lower in this paragraph. The bigger the number, the better
it is for memory requests. If you notice that this segment size is
dropping down over the period of a few days, weeks, etc, and not
flat-lining, this a definite indication of memory being used on the
server, and possible fragmentation. If this dropping number is in
the VM Pool, consider increasing the VM Pool size. If this dropping
number is in the FS Pool, consider hard setting NSS for it's cache
settings. However, there is one caveat to this number. There is a
line that the VM Cache Pool tracks (not a line currently viewable
in SEG.NLM) called the "Lowest Available Logical Kernel Page" which
will move down if an NLM needs more memory from the VM Cache Pool,
and the memory request is larger than the currently available
largest segment. Basically, this line lives in the VM Cache Pool,
somewhere above the File Cache Maximum Size line. If the VM Cache
Pool cannot grant a request for memory, and if it can move this
line down within it's own pool, it will do so, and then grant the
memory request from the VM Cache. When this line drops below the
File Cache Maximum Size limit (which is the barrier between the VM
and FS Cache Pools), and the VM Cache Pool still cannot grant the
memory request, this is where borrowing occurs from the File System
Cache Pool. A representative number for this line in the VM Cache
Pool will be available in an updated version of SEG.NLM.
High Water
Mark:This number represents the highest amount of
used cache that the NLM's of that particular pool have reached.
Theoretically, this should be less than the total size of the pool.
If the server has been up for a while and this number does not grow
and there is a large discrepancy between the size of the pool and
the High Water Mark, you may want to consider giving this memory to
another pool. For example, if you had a 6.5 SP3 server that has
been up and running for 2 weeks, and the size of the UAS is 992 MB,
while the High Water Mark for that pool is only at 575 Mb, you can
give a good chunk of that 417 MB of unused cache to the VM Pool.
This is accomplished using the -u parameter with SERVER.EXE.
NOTE: The only 2 pools that you will want
to take memory from 99% of the time is the User Address Space and
FS Cache Pool.
Top 6 Memory
Consuming NLMs:This is helpful when we see that an
NLM or two is out of control in using memory. If NSS, then we can
hard set how much cache it is given. If DS.NLM, same thing. If
either of these NLM's are large, check to see if there are NSS or
DS Configuration files. If they do not exist, then See
KB 10091980
for both of these recommendations.
Total
Fragmented:This number is representative of the"FS Cache Fragmented" and "LS Cache Fragmented" numbers combined.
Basically, how much memory from both pools is fragmented. If this
number is growing, determine which pool is contributing to this
number the most. The "LS Cache Fragmented" number is coming from
the VM Pool. If both numbers are, then it needs to be determined
who is doing it. You can hard set the NSS cache, as I mentioned
above. That should stop the FS Cache Fragmented number from
increasing. If NSS is hard set, and this is increasing, check to
see if "Total LP Pages" is counting upwards.
The FILE CACHE MAXIMUM SIZE will move the line between
the FS Pool and the VM Pool up or down, depending on what you set
the number to. The server - u parameter will move the line between
the UAS and the VM Pool up or down, depending on what you set the
number to. The The FILE CACHE MAXIMUM SIZE parameter, and the
server -u setting in the AUTOEXEC.BAT are discussed more in depth
in
KB 10091980..
NOTE:Below are 2 methods for setting up the
server to automatically record and store multiple copies of
SEGSTATS.TXT on regular intervals of 15 minutes.
IMPROVED METHOD (6.x servers only):
With NetWare 6.x (due to conditional scripting commands (%if,
%env, etc)) you can setup a more comprehensive method to record
SEGSTATS. This method allows a more "hands off" approach when it
comes to monitoring the system. Feel free to use either method on
6.x. Use the OLD METHOD listed below for 5.x servers. Please follow
these steps:
1. Create a SAVESEG.NCF file and insert the following
information. Place this NCF file in your SYS:\SYSTEM directory:
seg writestats
%if !loaded tbx then cmd tbx /nl
%if loaded tbx then cmd cp sys:system\segstats.txt
sys:system\segstat\[env %hour]-[env %minute].txt
2. Edit your SYS:\ETC\CRONTAB file. Insert the following
information:
0,15,30,45 * * * * SAVESEG.NCF
3. Edit your SYS:\SYSTEM\AUTOEXEC.NCF file. Add the following
lines at the end of the file:
LOAD SEG
LOAD CRON
This will create SEGSTAT.TXT at 15 minute intervals and backup
them up to SYSTEM\SEGSTAT\(CurrentTime).txt. Backups will be
overwritten starting at midnight the next day, keeping 24 hours
worth of statistics available and eliminating the need to manually
load CRON after startup.
If you need more history, use other combinations of builtin
environment variables (type %env at the system console to see
what's available). For example, the following will keep backups for
a week before starting to overwrite (the weekday variable is
0=Sunday, 1=Monday, etc)
%if loaded toolbox then cmd cp sys:system\segstats.txt
sys:system\segstat\[env %weekday]_[env %hour]-[env %minute].txt
This information was obtained from https://www.novell.com/coolsolutions/tip/17033.html
OLD METHOD (and for 5.x):
(NOTE: This method will only retain 2 copies) If you would like
to have the system continually write SEGSTATS.TXT for you every 15
minutes (so if the server crashes you have a SEGSTATS written
within 15 minutes of the crash) then follow these steps:
1. In your SYS:\ETC\CRONTAB file add the following lines:
0,15,30,45 * * * * seg writestats
0,15,30,45 * * * * load tbx.nlm
1,16,31,46 * * * * cp sys:\system\segstats.txt
sys:\system\segstats.old
2,17,32,47 * * * * unload tbx.nlm
2. Load SEG at the server console and let it run (if it does not
continually run, then this wont work)
3. Load CRON
4. DO NOT LOAD CRON AUTOMATICALLY ON BOOTUP FOR THIS METHOD. If
the server crashes, then we have the needed files, but if you
automatically load CRON on bootup it will overwrite the SEGSTATS.*
files that will be of most use. Just load the NLM manually for now.
Loading SEG.NLM automatically on bootup is fine as it just appends
to the existing file (SEG.CSV).
Essentially, this will write a SEGSTATS.TXT file every 15
minutes and will also keep 1 backup file, SEGSTATS.OLD, that will
be 15 minutes older than the latest SEGSTATS.TXT. SEG.CSV is
constantly being written to while SEG.NLM is running. These files
are all stored in the SYS:\SYSTEM directory. YOU WILL NOTICE
TOOLBOX LOADING AND UNLOADING WHILE THIS CRONJOB IS RUNNING.
Toolbox (tbx.nlm) is used to copy SEGSTATS.TXT to .OLD every 15
minutes so there is a backup copy.
Formerly known as TID# 10097396