Tool should have the following functions:

Alerts - the ability to notify administrators and users when a "yellow light" threshold has been reached.
Set Thresholds - the users should have the ability to change threshold limitations based on the configuration of their particular system.
Able to display real-time performance on the display screen.
Show all views on one screen - users need the ability to compare their page fault rate with their disc I/Os, Memory CPU usage with total CPU usage, etc. without manipulating from screen to screen.
Create professional reports, graphs and summaries for use in board meetings.

(ALL THE ABOVE SHOULD BE CONFIGURABLE FOR AUTOMATIC PROCESSING.)

Data should be exportable to other programs such as a graphing tool and/or capacity planning tool.
Try to buy one product for all your platforms for ease of use.

First indicator of problems is when users complain of poor response times. Look at the following:

High Disc I/O’s or Percentage = can indicate too small of memory or too much data on one drive.

High Disc Queue Length = consider moving some data to other drives. This queue length number should be no greater than twice the number of drives in the stripe set.

High Page Faults/ Low Read Hits = can mean too small of memory. Page Faults should not be above the count of 10/sec.

Read Hits should not be below 95%

Cache Faults/sec = if this number keeps growing, there is a most likely an application bug that is causing problems.

High CPU Busy = (85 % and up) can also be a memory problem, or not enough CPU to handle your workload. However, this can also indicate a software "hog".

Long I/O Waits = most likely is due to a fragmented disc &/or database, or poor data locality (you may wish to load your largest DB evenly across the disc drives).

Swaps/Memory Manager Activity = memory data swaps are an indication of a shortage of memory. It causes more work for the CPU and invokes time-costly disc I/Os.

Impedes = All DBs have a locking strategy to keep two users from altering the same DB record at the same time, thus corrupting the data in that record. Some of these locking strategies are better than others. The larger the "chunk" of data it locks, the slower the users can access that information. Example: locking a single customer’s address is better than locking the entire table of all the customers’ address information.

Interactive Activity = Online users have more "think time" than batch jobs. Automate everything possible for best resource use.

Excessive overhead = (application code that is necessary for running the application but is not directly useful to the process) can rob CPU resources of time spent on process-useful activity. Watch CPU % before and after the application runs.

Large number of "run queue" or "CPU queue" = This indicates CPU resources that are too small for the workload it is being asked to process. If the administrator only sees a couple of peaks throughout the day, they can take some batch processes off that time slot and add it to a slower slot. Some online activity may be able to be automated into a batch job at a slower time. Online-user cooperation may also be helpful.

However, if the large queue number persists on a regular basis, it may be time to upgrade. (Don’t forget to upgrade memory and look at disc space at the same time so as not to expose a second bottleneck.)

Service Time = The faster the better. This is a total of CPU, Memory and Disc service times combined. If there is a problem here, dive deeper!

Context Switching = Switching CPU time from one application process to another is a tricky business. Giving one process too much time creates a CPU "hog" and slows down performance on other processes. But giving it too little time causes excessive switching which takes time in itself.

Failures Adapter/Dropped connections count - They could indicate a bad adapter. Watch for high and increasing.

Frame Bytes Re-Sent/sec. - indicates computer errors; data had to be sent more than one time. Again, look for increasing numbers.

Preemptive Multitasking - Operating system will interrupt the thread process after the designated time quantum. This is a sign of a "hog" process (or a process which takes more than its pre-set share of CPU resources). Go straight to the source, the programmer to solve this one.

 

PROCESSOR

Reduce the number of display colors

Reduce the display resolution

Use no wallpaper or use one with a lower bit depth and resolution

Replace 8 bit cards with 16 bit or 32 bit cards. NT uses more processor time with lower bit cards.

Replace 486 or Pentium processors with clock-doubler and clock-tripler replacements.Increase the size of the external cache.

Increase the physical memory with a SIMM board.

Configure the virtual memory to use multiple drives. (Remember, the disc controller must allow simultaneous reading and writing to multiple discs.)

Spread applications over several servers.

Use different drives for V-Memory as you do for NT system files (this hinders, however, recovery system of NT).

NT also supports multiprocessors.

MEMORY - Give it less to remember

Reduce the number of display colors

Reduce the display resolution

Use no wallpaper or use one with a lower bit depth and resolution

Use a separate volume set, or better yet, a separate hard drive for swap space. Why? -- page 323 of Installation and Configuration Handbook.

Don’t mix chips. Gives unpredictable results. Stay with same size and manufacturer.

Use as many 32 bit programs as possible. 16 bit programs must be run through a translator (virtual machine) to run. If you have enough memory, you can also set each 16 bit application to run on its own memory space. This way, if one crashes, the others are not effected. Again, there is a cost to this; each application has to open its own virtual machine. This means there is duplication of pages in memory.

Split the paging file across several of the fastest drives.

Reduce memory requirements by disabling unnecessary features of both the O/S and applications.

DISC

Check page fault rate. The problem may actually be a memory bottleneck.

Keep partitions over 200M for FAT file systems and over 400M for NTFS systems (they were not designed to run on anything less).

Use stripe sets (unless you need the fault tolerance or higher security). This means that users can read from or write to files simultaneously. This works especially well if you have SCSI drives and the drive controller for these discs can handle simultaneous I/O processing. (HOWEVER, system and boot partitions cannot be part of a stripe set. Another effect of this system is that the CPU does not have to look through as much extraneous data to honor the request. (If there is only a choice of having all the dataset on one SCSI or on several EIDE drives plus the one SCSI, keep it all on the SCSI drive. - - There is a better chance of SLOWER performance on the slower drives than there is FASTER performance.)

When possible, use SCSI drives over EIDE or IDE drives. (This will help cache time as well.)

Set the Pagefile.sys large enough to accommodate growth and/or split it over the FASTER drives (IT WILL BE ACCESSED A LOT!). But do NOT split the file over different volume sets on the same drive. This will cause a degradation in performance and will cause excess wear on the drives.

Use a defragmenting tool - It is possible to defragment disks without a tool, however, it can be just as tedious as defragmenting an MPE system without one.

NETWORK

Tune the server to sacrifice memory for speed. (Network application\Control panel\Services tab\Server\Properties).

For a failing adapter, swap the adapter with another (this can only be a hardware fix).

For better network through-put, consider adding more memory (I realize this, too, is a hardware fix.)

Install only the network protocols you use. Unused protocols can use memory and take CPU time away from the one used.

If more than one protocol is used, bind them together. (See Ch-8 NT Administrator’s Bible.)

If you have mixed adapter speeds, consider upgrading the slower adapters. Performance slows when a fast adapter sends data to a slow one. (Here we go with more hardware solutions!)

NT uses some ambient CPU resources every second or two for System operation and pinging of network machinces. This can be seen as a regular saw-tooth pattern on a Perfmon graph.

NT makes great use of drive space by using it as virtual memory so the more drive capacity you can get, the better. But this also has a memory-to-disc paging cost. Paging activity costs more CPU resources and time than having more memory.

Disc file compression on NT was created more with performance in mind rather than maximum compression. If you chose to compress files, do it on the smaller, or less-used files. Uncompressing data every time you access it is resource intensive. DO NOT COMPRESS SYSTEM FILES OR EXECUTABLES.

Compression rules: FAT does not support compression

When copying from NTFS to FAT, the file is automatically decompressed.

When copying from FAT to NTFS, the file takes on the compressed attributes of the file it is replacing or the compressed folder it is being copied to.

Use NT to augment your current DOS/Windows 3.1, Novell, or Unix operating systems give these advantages:

• Fast, 32 bit networking drivers
• Gives domain logon authentication
• Gives easy-to-use administration tools
• Improved security
• Gives MS Mail Workgroup Client and Schedule+ software

Windows NT Server 4.0 Administrator’s Bible
by Robert Cowart and Kenneth Gregg
IDG Books

Windows NT 4.0 Installation and Configuration Handbook
by Jim Boyce
Que Corporation

Taming the HP 3000
by Robert A. Lund
Performance Press Publishing

Taming Unix
by Robert A. Lund
Performance Press

Inside Windows NT
by Helen Custer
Microsoft Press