OS/2 Shareware BBS: 36 Tips/36-Tips.zip/osotperf.txt

Text File | 1997-03-24 | 19KB | 396 lines

OSOTPERF - OS/2 WARP PERFORMANCE, TUNING
09/12/96
=======================================================================
OS/2 Warp Performance, Tuning
=======================================================================
Please Read Entire Document for Full Explanation of Procedures
--------------------------------------------------------------
DESCRIPTION

Performance, tuning questions

RESOLUTION

Before covering OS/2 system tuning let's review the concept of threads
and how they are used in OS/2. Every program that you run on an OS/2
system will process as one or more threads. All programs, DOS, Windows,
and OS/2, use a minimum of one thread. Each thread executes at a given
priority. The priority is used by OS/2 to determine which thread gets
to run when more than one thread is ready to run. The highest-priority
thread that is ready to run will be the one dispatched by the system
and given time to run. It is given what is referred to as a "time
slice". This is a set period of time during which
a thread is allowed to run. After this time has expired, the
highest-priority thread that is ready to run will be given it's own
time slice in which to run. If the same thread still wanted to run, and
it was the highest-priority thread, it would receive another time slice
to run in.

OS/2 programs usually run at normal priority, which is 200. Under
program control, the program can change its priority to be server class
(300), or time-critical (800). It can also change its subclass priority
between 0 and 31. A thread that has a priority of 200 and a subclass of
15 has a higher effective priority than a thread with priority 200 and
subclass 0, and therefore runs first. All DOS and Windows applications
always run at priority 200. In OS/2 Warp, we have added the capability
to define the subclass priority for DOS and Windows applications. Care
should be taken when using this subclass priority since it may cause
other programs to run slower or generate errors in the case of
communication applications that do not get the subclass boost.

OS/2 Warp will give OS/2 threads a priority boost for specific types of
functions and states. A priority boost means that the priority of the
thread is changed for a given time slice to give it higher priority
than other threads. This allows these threads to process more quickly
and therefore improve their responsiveness to the user. Following is a
list of priority boosts that can be given to a thread. They appear in
descending order.

Disk I/O

When an interrupt is received stating that a disk operation has
completed, the thread that processes this state will receive a priority
boost for one time slice to process this interrupt. This applies to
threads whose process has foreground focus. Foreground focus means the
process that owns the window that is highlighted on the computer screen.

Starved

In the CONFIG.SYS file, there is a statement MAXWAIT=3. The number 3
specifies how many seconds a thread can be in the ready-to-run state
without having received time to run. If a thread had been waiting to
run for 3 seconds, or whatever value is specified in the MAXWAIT
statement, its priority would be raised to give it an opportunity to
run.

Keyboard

This is a boost in priority given to a thread when it is interacting
with the system keyboard.  Basically, it is for accepting typed in data.

Foreground

This is a priority boost given to all threads of the program that owns
the active window on the OS/2 screen (the one that is highlighted).

Windowed

Threads which have windows showing on the display will also receive a
priority boost when drawing or writing into that window.

When a thread is in more than one of these states, the system will
combine the states and give a priority based on the combined states.

For DOS and Windows applications, the Foreground, Windowed, and keyboard
 states do not apply. The routine that handles the mouse or keyboard
interrupt will receive a boost in priority to handle the interrupt, but
the application does not receive a priority boost. If the DOS Setting
INT_DURING_IO is specified, a second thread is used to handle the I/O
interrupt, and that thread is given an interrupt boost.

Idle class is the other priority class that exists in OS/2.  This
priority level runs only when nothing else in the system wants to run.
Threads in this class will not receive any of the state boosts. If DOS
and/or Windows applications are being run, then you should avoid the
use of threads that run in idle class because they may never run but
will take up system space.

CONFIG.SYS Statements

Now let's look at specific things in the CONFIG.SYS file that you can
change to affect the performance of your system.  First we cover those
statements that you should not modify unless you have a system which
has a special use, such as a process control system. An example would
be a system used to monitor a manufacturing machine or chemical
process, where timing and response time are critical factors.

PRIORITY_DISK_IO=YES

This allows the application that has screen focus to receive a priority
boost when its disk operation is complete. This applies to the first
time slice given to the thread after the disk operation is complete.
After the time slice, the state is reset for the thread and the
priority boost removed.

PRIORITY=ABSOLUTE

Problematic in that all threads with lesser priority will never run.

MEMMAN=SWAP,PROTECT

Allows OS/2 to swap program instructions and data to disk when more
memory is needed than is physically available in your computer. If you
do not specify SWAP, you will need enough physical memory in your
computer to hold all the program instructions and data that OS/2 and
your application needs to run. You do not pay a penalty by specifying
SWAP and then not needing to use it.

The PROTECT parameter allows Dynamic Link Libraries ( DLL) to allocate
protected memory. Protected memory is memory that is protected from
being accessed by unauthorized programs.

You can also specify a COMMIT parameter. This forces the system to
ensure that enough physical memory or swap file disk space is available
for a memory object when it is created. Normally, OS/2 commits physical
and disk memory when the page of memory is actually touched. Specifying
this parameter can significantly increase the amount of space your swap
file uses on disk. You would usually only specify COMMIT if you were
developing applications or systems and wanted to see what the maximum
amount of memory and disk space that could be required for your system.

TIMESLICE=X,Y

This statement is not found in the CONFIG.SYS file after you install
OS/2 but is sometimes recommended to be added. This was okay to add for
OS/2 2.0, 2.1 or 2.11 systems, but not for OS/2 Warp. In OS/2 Warp, we
dynamically modify a thread's time slice based on actions that have
occurred. For instance, if a thread took a page fault during its time
slice, we give it an extra time slice to process what is contained in
the faulted page. We also give applications doing disk I/O extra time
slices if the data they are reading is in the disk cache. When the
TIMESLICE= parameter is used, none of these actions will occur.
Instead, each thread will be given the minimum time slice of X, and its
time slice will not be allowed to go beyond value Y.

PRIORITY=DYNAMIC

If DYNAMIC is not specified, then each thread will only run at the
priority that has been assigned to it by the developer of the code.
None of the priority state boosts described earlier will be applied.

DEVICE=C:\OS2\BOOT\VDISK.SYS

This statement allocates a virtual disk in your computers physical
memory. It is used for quick access to often-used files and programs.
This was good for a DOS environment where the extra memory in your
computer was not used by DOS, but OS/2 uses this memory, and your
performance can be adversely affected if a VDISK is used. It is much
better to increase the size of the disk cache if you have unused
physical memory than it is to use VDISK.

Now let us look at statements in the CONFIG.SYS file which you should
change to help improve the performance of your OS/2 Warp system.

LIBPATH=

This tells the system where to find DLL files and printer device
drivers that OS/2 Warp and applications use. Place the directory names
in order of usage. The most accessed directory should be first, the
least used last. If possible, place the DLL used by a program in the
same directory as the working directory when the program is running.
Then, you do not need to add that directory to the LIBPATH statement.
Also, place all directories that are on a network at the end of your
LIBPATH statement in case the network goes down and they cannot be
accessed. When you try to access a network drive that is not active,
you will have to wait for an error time to occur before processing can
continue. This can be as much as 15 seconds or longer. See the
discussion of dynamic LIBPATH support later on in this document for
additional considerations when accessing network drives.

SET PATH=

PATH is used to specify where OS/2 Warp searches for executable program
files, such as .EXE, .COM, .CMD, and .BAT. Place the directories in
order of most used first, least used last. If programs will be executed
from an object on your desktop or folder, specify the path there and
not in the PATH statement. Only place directories in the PATH statement
for executable files that will be called from other programs, command
interpreters, or command line interfaces.

SET DPATH=

The same principle applies to DPATH as PATH and LIBPATH. For resources
that applications use, place the most used directories first and the
least used last. DPATH is used to define the search path for finding
data files.

BUFFERS=90

Buffers are physical memory used to support partial sector reads and
writes in a FAT (file allocation table) file system environment. They
are also used to cache FAT directory entries and for swap file disk
I/O. Because BUFFERS are used to cache FAT directory entries, this
number should not be reduced
below 60, unless you are not using the FAT file system on your disks.
Reducing this number will increase the number of disk reads that are
done to the FAT directory entries and therefore slow down your system.

MAXWAIT=3

This specifies the maximum amount of time that a thread will be in a
ready-to-run state without receiving a time slice to run in. After this
time expires, the thread will be given a boost in priority so it gets a
chance to run. Reducing this value to 2 may help in systems where there
are a lot of programs running, or multiple separate DOS/Windows
programs running. Reducing it to 1 on systems where there is swap
activity taking place can slow down the system.

DISKCACHE=D,LW,t,AC:

This is used to specify the amount of physical memory set aside to
cache data that is being read from or written to disk partitions that
are formatted for FAT. When OS/2 Warp sees "D" specified in the
DISKCACHE statement, it will allocate a disk cache size from 48K to
4MB, based on the amount of physical memory you have in your system. If
you have more than 8 MB in your system, D will cause 10% of your
system's physical memory to be used for the FAT disk cache. Instead of
specifying D in the DISKCACHE statement, you should change it to the
actual amount of disk cache space you require. If you have a system
where your programs do not do much disk I/O or where your memory is
being used up by your applications, you may want to set this value to
128. Also, reduce this value if you are using the DB/2 product or any
other product that provides its own disk data caching. If you have a
system that has lots of memory, then you can specify a number bigger
than 4MB. The maximum allowed is 14.4 MB.

The t parameter is not defined in the default CONFIG.SYS file. It
defines the cache threshold for records that go into the cache. The
default value is 4. This means that any record that is 4 sectors or
less will go into the cache, while those greater than 4 sectors will
not. If your disk cache size is 128K or larger, add this parameter to
the disk cache statement. If known, set this value to the largest
record size used. Otherwise, set the value to 32. The range can be from
2K ( 4 sectors) up to 64K. 32 is a good starting point and is big
enough to handle most applications and program executable files.

The LW parameter activates the Lazy Write or write behind feature. This
allows the application to get control back before the data is actually
written to disk. A separate thread will write the data from the cache
to the disk when necessary or opportune to do so. You should always use
this option, and code your applications to open files with a cache
bypass option if disk data security is imperative.

The AC:  parameter is used to specify which FAT directories should be
checked at system boot time to see if they were left in an
unpredictable state when the system was last powered off. This usually
occurs when the power is lost to your machine and you had not done a
Shutdown or Ctrl-Alt-Del key sequence prior to losing power. The disk
directories specified here will have CHKDSK run against them to clean
up any lost files or abandoned clusters.

SWAPPATH=d,r,s

SWAPPATH specifies where code and data pages are swapped to on disk
when more physical memory is needed than is available in your system.
The d parameter represents the path where your SWAPPER.DAT file is
located. For systems which have multiple partitions or multiple disks,
this should be placed on the most used directory of the least used
disk. Also, try to physically locate the swap file on the disk based on
its usage. If you are doing a lot of swap activity, place the swap file
at the start of the disk. If is it rarely used, place it at the end.

The s parameter specifies the size that the swap file is initialized to
when you start your OS/2 Warp system. Make this large enough so that it
does not have to grow in size while you are running your programs. You
should perform your normal computer functions and look at the size of
the swap file when you have the most activity. Then set the value of
the s parameter to this size in the CONFIG.SYS file.  If you are using
the FAT file system, IPL your system under DOS, delete the SWAPPER.DAT
file, defragment the disk partition where the swap file will be
located, and then IPL your OS/2 system. This should keep your swap file
from getting fragmented.

The r parameter specifies the amount of free space that must be in the
swap file's drive. The default for this value is adequate and only
needs to be changed if you want to be warned earlier about a possible
out-of-memory situation.

THREADS=

THREADS defines how many threads the system will be able to use. One
page of resident memory is need for approximately every 32 threads that
are defined. This memory will be allocated at the time the system is
started. As a minimum, you will need 80 threads to support the base
OS/2 Warp system and 3 or 4 OS/2, DOS or Windows applications. The
system will support up to 64000 threads, but typically you will not
have enough memory in your system to support more than 300 to 500
threads. 18 threads are required for LAN Server 4.0, and 12 for
Personal Communications/3270. You will need an additional 2 threads for
each Personal Communications/3270 session that is started.

To calculate the number of threads that you will need in your system,
use the formula 54+(2xN)+10 where N is the number of programs that you
will run together. If the program requires more than 2 threads, add in
the additional threads. This will insure that you have enough threads
in most cases.

To determine how many threads you are using at any given time, run the
PSTAT command from an OS/2 command line. This will show all of the
processes that are running on your system, as well as how many threads
each process is using. The output is quite long, so you may want to
redirect it to file.

Additional considerations

You should only install the devices drivers that your programs actually
need to run. Do not install extra communication, printer, video or
device drivers if they will not be used. Below is a list of device
drivers and virtual device drivers that are normally found in
CONFIG.SYS and that may not be needed.
(Virtual device drivers are used to support DOS and Windows
applications and usually have a V at the beginning of their name.)

VEMM.SYS

Used to support Expanded Memory use in DOS and Windows programs.

VXMS.SYS

Supports Extended Memory in DOS and Windows applications.

VDPMI.SYS

Supports the DPMI memory access and is required to support all Windows
applications.

VW32S.SYS

Supplies support for the WIN32S Windows APIs. Not needed for Windows
programs that do not use WIN32S APIs.

IBMxFLPY.ADD (where x is either 1 or 2)

1 is used for family 1 machines and 2 is for MCA (Micro-Channel
Architecture )
machines. You do not need both.

XDFLOPPY.FLT

This is required for reading diskettes which are written using the XDF
(Extended Disk Format) format. These are usually OS/2 and PCDOS 7
installation, printer, and video driver diskettes and possibly CSD
diskettes. The OS/2 Warp Install and Disk 1 diskettes do not use the
XDF format.

COM.SYS and VCOM.SYS

Only required if you will be doing serial or async communications.

If you use the selectable CONFIG.SYS option in the Archive and Recovery
feature of OS/2 Warp, it is possible to create multiple CONFIG.SYS
files which will contain different device drivers based on your needs.
For example, you could create one CONFIG.SYS file that is used for
maintenance and installation. This one would include XDFLOPPY.FLT and
both IBMxFLPY.ADD drivers, plus additional threads. Another CONFIG.SYS
used for normal processing could have these device drivers removed and
a lower number of threads. When maintenance has to be applied to the
system, or some additional new products installed, you
could restart the machine with the Archive and Recovery Choices menu
active and select the proper CONFIG.SYS to be used. An extension of
this would be to archive the CONFIG.SYS and the OS/2 INI files and
select those to apply maintenance.



______________________________________________________________________
IBM disclaims all warranties, whether express or implied, including
without limitation, warranties of fitness and merchantability with
respect to the information in this document. By furnishing this
document, IBM grants no licenses to any related patents or copyrights.
Copyright (c) 1994, 1995 IBM Corporation. Any trademarks and product
or brand names referenced in this document are the property of their
respective owners. Consult your product manuals for complete trademark
information.