Novell Home

GroupWise 6 Deployment Guide - Section 4

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 20 Dec 2001
 

<Table of Contents

Section 4: Optimizing Your System

Leveraging NetWare

To optimize server processing time, you can adjust NetWare settings such as cache, Read Ahead functions, and File and Record Locking.

The following settings improve performance on NetWare servers running the POA. Many of these options require memory. A good way to determine if you have sufficient memory is to monitor the LRU count and the Available Cache Buffers. If these numbers drop (LRU below 20 minutes and Cache Buffers below 40%), more memory is probably required.

  1. Directory Cache buffer Nonreferenced Delay = 30 sec (default = 5.5 sec)
    This setting determines how often the Directory Cache buffer is refreshed. Every refresh requires a new disk read and write to memory. By increasing the value to 30 seconds, the administrator decreases how often the refresh takes place. This setting decreases processor overhead and I/O traffic.

  2. Minimum Directory Cache Buffers = 2-3 per connection (default = 20)
    By increasing this value, the buffer is already established when the NetWare server is started. This reduces processor and I/O bottlenecks.

    Directory cache buffers are equivalent to the block size on disk (e.g. 64KB). So, to calculate the amount of memory used, multiply the number of directory cache buffers by the block size.

  3. Maximum Directory Cache Buffers = 4000 (default = 500)
    This setting protects the system from using too much memory for Directory Cache Buffers. The default does not give the system enough room to grow. Setting it at 4000 gives the system some leeway, but may require additional physical memory.

  4. Read Ahead Enabled (default = On)
    The Read Ahead feature significantly increases performance on NetWare servers running GroupWise. The Read Ahead feature predicts what files are required next and loads them in memory for immediate access.

  5. Read Ahead LRU sitting Time Threshold = 60 sec (default = 10 sec)
    When a request is made to read a portion of a block, NetWare's Read-Ahead feature optimizes the read operation by reading complete blocks.

    Although GroupWise benefits from the Read-Ahead feature, server memory is used when data is read into a cache. The Read Ahead LRU Sitting Time Threshold setting is the means for balancing out the server memory cost. The Read Ahead LRU Sitting Time Threshold looks at the least recently used (LRU) cache block and if it is less than 10 seconds old (the default setting), Read Ahead will be disabled.

    An LRU Sitting Time of less than 10 seconds indicates that the server is critically low on memory. An LRU Sitting Time of 60 seconds is still indicative of a low-memory condition, so 60 seconds should be the minimum setting for a GroupWise post office, with a higher threshold being used if you want to be more aggressive in disabling Read Ahead (up to about 5 minutes). Ideally, LRU on the server should be 20 minutes. If the LRU setting threshold is reached on a regular basis, additional memory should be added to the server.

  6. Maximum File Locks = 20,000 (default = 10,000)
    If there are a lot of users on a single GroupWise post office, it is wise to increase the maximum file locks.

  7. Maximum Record Locks = 100,000 (default = 20,000)
    GroupWise performs many record locks. If there are a lot of users on a single GroupWise post office, it is wise to allocate sufficient record locks.

  8. Minimum Service Process = 100 (default = 10)
    New service processes are dynamically created as they are needed. So, pre-allocating service processes requires less overhead than allocating them on the fly; however, there is a point of diminishing returns.

    A good way to determine the Minimum Service Process setting is to check the number of service processes that have been allocated on a server that has been running some time. Set the Minimum Service Process setting at the number of allocated service processes under normal usage. On the average, each service process requires approximately 16 KB.

  9. Maximum Service Process = 1000 (default = 40)
    In order prevent service processes from monopolizing your memory, you can set the maximum number of service processes that can be allocated on the server. If the number of service processes allocated under normal usage begins to approach the Maximum Service Process setting, increase the setting. Each service process requires approximately 16 KB.

  10. New Service Process Wait Time = .3 sec (default = 2.2 sec)
    This setting specifies how long the system waits to create new service processes if none are available. It is good practice to set the value low so your system can rapidly respond to increased server loads.

  11. Minimum Packet Receive Buffers = 2 -3 per user (default = 50)
    Any processed request uses a Packet Receive Buffer. This includes all NCP requests, SAPs, RIPs, TCP packets, etc. If the server is bombarded with requests and there are not enough packet receive buffers, the system becomes bottlenecked and starts dropping requests. If a request is dropped, the requester must re-send the request.

    Packet receive buffers are roughly the size of your packets (1518 bytes for Ethernet) plus 500 bytes. On a Token Ring network, packet receive buffers should take up to 4K or more.

  12. Maximum Packet Receive Buffers = 4000 (default = 100)
    This setting prevents the system from allocating too many packet receive buffers and monopolizing your server's memory.

  13. New Packet Receive Buffer Wait Time = .1 Sec (default = 1 sec)
    By reducing this value, the server will immediately spawn a new buffer without first waiting to see if one becomes available.

  14. TCP Defend Land Attack = Off (default = On)
    This feature protects the TCP/IP stack against LandAttacks. LandAttacks are packets sent to the server with the same source and destination. The packets get into a loop and can bring the server down. If the server in question has no access to the outside world, the chance of LandAttacks is extremely minimal. By turning this unneeded feature off, overhead is reduced and IP packets can be processed faster.

Fine Tuning the POA

The following settings for the Post Office Agent (POA) must be fine tuned according to your organization's performance and stability objectives.

  1. Enable Automatic Database Recovery = On (default = On)
    This setting enables the POA to detect database problems and, in most cases, fix them. In the long run, this setting improves performance because it prevents problems from becoming critical before they are detected and corrected. Novell recommends this option be left On.

  2. Enable Caching = On (default = On)
    Setting this option to On improves the performance of the POA. It allows the POA, at the software level, to handle caching of the databases it is working with. Novell recommends that this setting be set to On. However, if there are problems with database corruption, it is a good idea to turn this setting off until the source of the problem is located and fixed.

  3. TCP Handler Threads = 20 - 30 users per thread (default=6)
    This setting handles Client/Server requests. If users are less active, meaning they average 5 to 10 items sent and received a day, then 30 users per thread is sufficient. If users are more active, meaning they send and receive more than 30 items a day and perform Finds and busy searches, then 20 users per thread is recommended. This setting should be adjusted for each situation. Each thread allocated takes up memory and resources. Also keep in mind that by not allocating enough threads, the POA will have pending requests and users will experience slower performance.

  4. CPU Utilization = 85% (default=85%)

  5. Delay Time = 100 millisec (default=100 millisec)
    These two settings-CPA Utilization and Delay Time-go together and their defaults are the recommended settings. These settings are designed to keep the server in peak performance. If the server's processing load is too heavy, the POA delays the launch of new threads for 100 milliseconds. Doing this allows the server to continue processing the current requests and refrain from ignoring other responsibilities.

    The POA is designed to load balance its requests as the CPU Utilization threshold is approached, which makes the Client/Server threads the highest priority. When the CPU Utilization threshold is triggered, the POA will start to terminate other threads, such as GWCheck and QuickFinder, to free up resources for the client requests.

Fine Tuning the MTA

The following settings for the Message Transfer Agent (MTA) must be fine tuned according to your organization's performance and stability objectives. These settings also optimize POA performance.

  1. Flag all WPSCIN and WPCSOUT directories and subdirectories in the GroupWise system for Immediate purge. (These directories exist below each of the post office, domain, and gateway directories.)
  2. Each MTA has a MSLOCAL directory structure that should be flagged for Immediate Purge.

Setting the Immediate Purge flag helps keep the volumes clean from the many files that are written and deleted in these directory structures.

Moreover, if you are running sub-allocation on the volume, setting the Immediate Purge flag optimizes server utilization. When running sub-allocation on the volume, the WPSCIN and WPCSOUT directories should have at least 30% disk space available at all times. If the space is free but resides in purgeable blocks, server utilization is dramatically affected. By setting Immediate Purge on high traffic directories, the cleanup tasks are not left to the server's purgeable blocks algorithm.

Optimizing WebAccess

On single domain systems, a basic installation of GroupWise WebAccess may very well meet your needs. However, if your GroupWise system is large or spans multiple locations, you can optimize system performance by configuring multiple WebAccess Agents or by having multiple Web servers running the WebAccess Application.

Multiple WebAccess Agents

GroupWise WebAccess is designed to allow one installation of the WebAccess Application to support multiple WebAccess Agents, as shown in the following diagram.

Important! Each WebAccess Agent must have the same encryption keys.

There are various reasons why you might want to add additional WebAccess Agents, including:

  • Improving reliability: One WebAccess Agent may provide sufficient access and performance, but you want to protect against downtime that would occur if the WebAccess Agent became unavailable due to server failure or some other reason. Installing more than one WebAccess Agent enables you to set up failover support to make your system more reliable.

  • Improving performance: The WebAccess Agent is designed to be close to the GroupWise databases. It requires direct access to a domain database and either direct access to post office databases or TCP/IP access to the Post Office Agents. Therefore, you should ensure that the WebAccess Agent is on the same local area network as the domain and post offices it needs to access. For example, in most cases you would not want a WebAccess Agent in Los Angeles accessing a post office in London.

    For absolute best performance, the WebAccess Agent should be run on the same box as the post office. Dedicating a WebAccess Agent to each post office significantly improves performance. This is critical when you are consolidating post offices and you have a lot of users on the same post office.

  • Improving availability: By default, the WebAccess Agent has 12 threads assigned to process user requests which means that it can process only 12 requests at one time, regardless of the number of users logged in. If necessary, you can increase the number of threads allocated to the WebAccess Agent, but each thread requires additional server memory. If you reach a point where WebAccess is unavailable to users because thread utilization is at a peak and all server memory is being used, you may need to have several WebAccess Agents, installed on different network servers, servicing your post offices. For information about changing the number of allocated threads, see "Configuring the WebAccess Agent" in the GroupWise 6 Administration Guide.

Multiple WebAccess Applications

As with the WebAccess Agent, you can also install the WebAccess Application to multiple Web servers, as shown in the following diagram.

Important! Each WebAccess Application must have the same encryption keys.

Some reasons for wanting to use this type of configuration include:

  • Enabling WebAccess users on an intranet to access GroupWise through an internal Web server and WebAccess users on the Internet to access GroupWise through an exposed Web server.
  • Increasing Web server performance by balancing the workload among several Web servers, especially if you are using the Web server for other purposes in addition to GroupWise WebAccess.

If necessary, you can also use multiple WebAccess Agents in this configuration, as shown below.

Important! Each WebAccess Agent and Application must have the same encryption keys.

Optimizing GWIA

POP3, IMAP4, LDAP

To decrease the amount of overhead GWIA uses, turn off any unused protocols. For POP3 and IMAP4, use ConsoleOne to edit the GWIA properties. Deselect the POP3 or IMAP4 services in the POP3/IMAP4 Settings tab. For LDAP, deselect the LDAP service in the LDAP Settings tab.

If these services are used, adjust the number of threads allocated to the respective service. These numbers will depend on the number of expected concurrent connections for each service.

Any of the above changes require an Exit and Restart of GWIA to allow GWIA to re-read the changed values in the GWIA.CFG file.

SMTP Timeout Values

The following are the default timeout values and startup options for SMTP communication within the GWIA SMTP daemon process. Changes can be made directly in the GWIA.CFG file or through ConsoleOne under the SMTP/MIME Timeouts tab.

  • /te SMTP wait time for connection establishment (minutes, default 2)
  • /tg SMTP wait time for initial greeting (minutes, default 5)
  • /tc SMTP wait time for commands (minutes, default 5)
  • /tr SMTP wait for TCP read (minutes, default 5)
  • /td SMTP wait time for data (minutes, default 3)
  • /tt SMTP wait for connection termination (minutes, default 10)

The default values are high and will allow connections to remote SMTP hosts over a slow connection to complete; however, there may be times when all the available send threads are being used over slow connections so other outbound messages may not be delivered. By decreasing the value of these timeouts, messages over slow links may be deferred, allowing other messages in the send queue to occupy an available send thread.

GWIA Threads

The following are the GWIA.CFG startup options and default values for the number of SMTP and conversion threads.

  • /rd Number of SMTP receive threads (default 4)
  • /rt Number of inbound conversion threads (default 4)
  • /sd Number of SMTP send threads (default 2)
  • /st Number of outbound conversion threads (default 4)
  • Any changes made to these settings require a restart of GWIA.

SMTP Send/Receive Threads
SMTP traffic affects the number of threads available. You should monitor the active threads through the GWIA SMTP Service Statistics screen. To access the GWIA SMTP Service Statistics screen, press F10-Options and F9-stats from the GWIA screen. Pressing F9 repeatedly allows you to scroll through the SMTP, POP3, IMAP and LDAP Service Statistics Screens. On the SMTP Statistics screen you can monitor the number of current Send and Receive threads.

If the number of SMTP Send/Receive threads is frequently at the defined maximum, you need to increase the number of allocated threads. You can allocate as many threads as needed since memory is not allocated at GWIA startup, but as the threads are spawned. However, keep in mind that if too many threads are defined, GWIA may spawn enough threads that server performance is adversely affected.

Conversion Threads
Conversion threads convert GroupWise messages to SMTP format and back again. If you increase the number of SMTP send or receive threads, it is a good idea to also increase the number of corresponding conversion threads. Doing so ensures that there is not a bottleneck of messages waiting to be converted.

Note: The number of conversion threads does not have to correspond directly to the number of SMTP threads.

You can download the full .pdf version of this new Deployment Guide here: www.novell.com/info/collateral/docs/4621213.01/4621213.pdf

<previous

Table of Contents

next>


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

© 2014 Novell