Novell is now a part of Micro Focus

Tuning the NetWare Server

Novell Cool Solutions: Feature
By Blair Thomas, Jeff Hughes

Digg This - Slashdot This

Posted: 19 May 2000

If you are like most NetWare administrators, the idea of properly tuning and optimizing the NetWare system parameters is required for creating a stable network environment. But what are the most important system parameters, and what is needed to tune each server? This article will be a tutorial on how to tune and optimize your NetWare 4 servers.

When tuning the NetWare server to optimize performance, the first item you should check is the server's CPU Utilization. Obviously, the CPU Utilization is the most important system parameter that you can monitor to determine how the operating system is handling the workload of the users and applications. You can easily check the value of the CPU Utilization statistic for each NetWare server using the MONITOR.NLM main screen. The CPU Utilization statistic is updated once a second. Although, the CPU is usually the last place to look for a bottleneck on your server, the CPU Utilization statistic may indicate a problem with performance issues on other subsystems. Therefore, most of your tuning should be with the server's subsystems and not the CPU itself.

Next, check the total amount of server memory and cache statistics. The server's memory has the largest impact on the overall performance of the operating system then any other subsystem. For instances, server performance greatly increases when the appropriate numbers of file cache buffers are allocated. You can easily check to see how the file cache is performing by viewing the statistics using the Cache Utilization menu of MONITOR as shown in the figure.

Figure - File cache statistics are found in under the Cache Utilization menu in the MONITOR utility. The objective for the file cache buffers is to keep sufficient number of buffers to keep the cache hit ratios high.

File cache buffers are assigned from the memory that is left after the operating system is booted and the core functions and NLMs are loaded. We recommend that the cache-hit ratio for file caching statistics remains between 90 and 100%. As a rule of thumb, the 90% hit ratio is achievable (in a read-intensive environment) when the cache buffers are 75-80% of Total Server Work Memory. You should also make sure that the value of the "Long Term Cache Hits" ratio is up around 98-99%. This will ensure the greatest server performance. If the file cache statistics are not in these ranges you should strongly consider adding more server memory which will increase the number of file cache buffers.

The most important cache statistic you can use to measure cache efficiency is the LRU Sitting Time. This value indicates how long the oldest (or least recently used) cache buffer has been allocated. This means how long it takes for the entire amount of file cache buffers to roll completely over. This measurement is also known as the cache "churn rate" or "roll-over rate". Using the Cache Statistics menu of MONITOR, you can easily check the current value of the LRU Sitting Time. A large time value compared to the time the server has been up indicates that the server is not busy, or that you have ample server memory for file caching. An extremely small time value indicates that the entire file cache is being roll over and the server could be thrashing.

We have visited companies that have complained about servers with lots of users being extremely slow. Often the problem is that the LRU sitting time value is extremely short. For example, one customer we visited had a server that had 1,000 users on an e-mail server that had 64MB of total server memory that was running extremely slow. About 80% of the memory was dedicated to file cache. However, the LRU sitting time was less than 20 seconds. This means that the server was rolling over the entire file cache (more than 50MB) in less than 20 seconds. In contrast, other environments with large amounts of cache would have a LRU Sitting Time of several hours. This is good. A good rule of thumb is that your LRU sitting time should not go below 15 minutes. If your LRU value falls below 15 minutes it usually means that you do not have enough memory to create a large enough cache to service the user requests rapidly. It's time to take a look at adding more memory to your server if this value remains consistently below 15 minutes.

As an administrator, you will next want to pay special attention to the current number of packet receive buffers on your system, especially if your users are complaining of slow response time from the server. It is extremely important to monitor the value of the current packet receive buffers to see if the value is close to the maximum value. If this is the case, you should increase the maximum to account for the increased workload performed by the server. The current number of packet receive buffers that the operating system has allocated is viewed using the main screen of MONITOR.

A server maintains a minimum and maximum number of packet buffers that can be allocated in RAM in order to receive the incoming data. The server allocates receive buffers dynamically, based on the activity of the server. If the server runs out of packet receive buffers you will the No ECB Available Count increase as shown in the MONITOR utility. This indicates that packets are being dropped. If you see this count increasing you should increase the Maximum Packet Receive Buffers by increments of 10. The set parameter MAXIMUM PACKET RECEIVE BUFFERS = N, where N equals 50 to 2000 can be used to change the total number of buffer. The default is 100. We recommend that you have at least one packet receive buffer for each client that will be attached to your server. For example, a server supporting 500 users needs to allocate 500 packet receive buffers if necessary. In addition, you should account for 10 packet receive buffers for each LAN adapter installed in the server. Thus, we recommend that you use the following equation to calculate the proper value for the MAXIMUM PACKET RECEIVE BUFFERS: maximum = (1 * (# of connections)) + (10 * (# of LAN cards)).

Lastly, check the number of current service processes in use. New services processes are allocated by the operating system as needed. Once a service process is started it ever stops until the server is downed. As a system administrator, your job is to make sure that the server never runs of new service processes. You can view statistics on the current number of service processes in use and the maximum number set by using the MONITOR.NLM utility and viewing the "General Information" screen. Since viewing the screen, press the Tab key to see the lower half of the screen where the two service process statistics are shown.

NetWare 4 sets the default of service processes at 10 with a maximum of 1000. You should use the SET MINIMUM SERVICE PROCESSES and SET MAXIMUM SERVICE PROCESSES parameters to allow the operating system to create enough processes to manage the workload. These parameters are found in the "Miscellaneous" section of the server SET parameters. For example, in order to change the minimum number of service process that the server will have use the command SET MINIMUM SERVICE PROCESSES = N, where N can be 10 to 500. The best method for deciding what to set this parameter is to look at the current services processes display in MONITOR after the server has been running for several weeks. Take the number of current service processes and cut it in half and set the MINIMUM SERVICE PROCESSES to the result.

To ensure that the bottleneck generated due to sudden increase in workload is only temporary, you need to adjust the maximum number of service processes. You can adjust the maximum number of service process by changing the parameter SET MAXIMUM SERVICE PROCESSES = N, where N can be a value from 5 - 1000. The default is 50. NetWare has the capability to allocate up to 1000 service processes. Changing the maximum number of service processes is only necessary in a few circumstances. For example, if you are running 500-1000 users on a single server, you will want to increase this parameter. We recommend that if the number of users equals 1-250 set this parameter to 300. If the number of users is 251-500 set the parameter to 600. If number of users is greater than 500 set the parameter to 1000.

One of the most important jobs that you can perform when managing your NetWare servers is tuning and optimizing the performance. As part of your tuning and troubleshooting process you will want to look at the total amount of server memory, file cache buffers, communication buffers, and server processes. These system parameters have the most impact on the overall performance of each server.

Jeffrey F. Hughes and Blair W. Thomas are senior consultants at Novell. They have authored NetWare 4.11 and NDS books. For more design and implementation information contact

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates