How Dave Does It: GroupWise Consolidation - GroupWise Specific Server Settings
Novell Cool Solutions: Trench
By Dave Muldoon
Digg This -
Posted: 8 Jul 2003
This is the sixth article in this series regarding consolidating your GroupWise system. The first five articles reviewed consolidation project guidelines, potential impact to the end users, monitoring user moves for potential problems and potentially eliminating the WAN altogether. This article will give you some useful information that can be used for configuring a server that only runs GroupWise to perform at a very efficient rate.
One of the most important things you can do for GroupWise occurs well before your initial installation. The biggest decision you can make relates specifically to the hardware that is going to run your GroupWise system. There are a lot of vendors out there and choosing one could truly be considered the biggest decision in some circles. I don't want to get into vendor specifics, I'm going to try to stay somewhat generic when it comes to vendors (although those who know me already know my opinion on who's "not recommended").
As you're probably already aware, GroupWise is an extremely I/O intensive application. This needs to be considered during all of the decision making process, as cutting corners/cost now can directly impact your system performance over the long term. There are certain things that you can do when building or ordering a server that can increase your performance:
Disk: You want to make sure you have at least 50% free space on any volume you are planning on using for GroupWise. This reduces the travel range for the controller head thus, increasing the speed of your reads and writes. You should also consider upgrading a standard package server to faster drives, at least 10,000 RPM if not better. This combination will assist response time of data retrieval on your system.
Controller: You want to make sure that the controller in the server has a decent size cache, battery backup and has multiple channels. The combination of a decent controller and faster/less full drives will reduce the number of 820E errors during peak times, allow for faster maintenance and database access and increase the overall end user experience.
NIC: Obviously almost any NIC will do. I suggest sticking with the fastest throughput possible for your network. This is typically 100MB, but if you can afford a gigabit infrastructure you truly will have enough room to roam into uncharted territory. Regardless of the topology that you choose, make sure that the entire path from desk, switch and server is hard-coded for both line speed and duplex (100MB, Full Duplex if you can set this standard). This removes the negotiation that needs to be done for each packet along the way - improving response time.
Memory: This is another area where I don't recommend holding back the dollars. If you can afford too, max the box out, memory is cheap these days - compared to years back. You won't be disappointed with the money spent here.
Processor: This is a debate-able subject as well. I won't get into specifics of brand, but I would recommend getting started with two processors. Make sure they're fast. At this point the market really sells packaged servers that generally have GHz or better - stay in that range and you won't have to worry.
Quickly, to summarize these 5 items; by spending the money now, the server will actually have a longer life span and have less user impact, resulting in a total cost justification; less downtime and user problems over an extended period of time.
|Server Operating System Specific Settings|
All of these settings that I am recommending and providing "numbers" for are based on heavily used servers with a lot of users (running in online mode). Generally, I'm talking about 700+ users on a server, where at any given time there are 50% of the users logged in and generating well over 1200 application connections.
- Create volumes with 64K blocks. This takes advantage of the Read Ahead settings mentioned below.
- Set "Read Ahead Enabled = ON". This allows the server to take the remaining data in the existing block it has accessed and serve it into memory for faster access. This process assumes that the remaining data in the block will be requested "next in line".
- Set "Maximum Service Processes = 1000". This allows the server to have a high number of service processes, but they are not used unless needed. You can think of services processes as open lines at the checkout counter in a grocery store. Not each one has an attendant, but if the store gets busy, an attendant comes along and opens up a new line.
- Set the "Minimum Service Processes = 250". This gets you up and running quickly with available processes to handle client requests. Novell recommends having 2-3 service processes per user on the Post Office. This setting is set to accommodate 80-90 users at minimum. Based on the environment description of this article, there really shouldn't be a reason to go lower than this recommendation.
- Set the "New Service Processes Wait Time = 0.3". This allows a connection to wait .3 seconds before receiving a reply from the server. Obviously this is a short time as the default is actually higher than this for a standard installation. This will increase the response time of transmissions for end users.
- Set the New Packet Receive Buffer Wait Time = 0.1". This again correlates to a new connection request, keeping the time it takes for a server to allocate a new buffer for a client request down to a minimum.
- Set the "Read Ahead LRU Sitting Time Threshold = 60 Seconds". This setting will assist with memory management and correlates to the "read ahead" being turned on. You can consider this setting the head cashier in front of all of the lines, directing "traffic" in the front of the grocery store. The head cashier compares the lines and sees which is used least and directs requests to the appropriate place (disk or memory) to get you on your way as fast as possible.
- Set the "Maximum File Locks = 20,000". This accounts for the fact that GroupWise has many small files throughout the message store and as users request items, GroupWise is required to temporarily lock certain files for short periods of time. Keep in mind that this setting does reduce overall available system memory after this is implemented, so make sure you have enough memory (as mentioned above).
- Set the "Maximum Record Locks = 100,000". This setting relates to GroupWise and it's use of the file system that is very similar to the file locks (above). Although keep in mind, this is a different setting, and can utilize memory but it does not have the same impact in correlation to available memory as file locks.
- Set the "Directory Cache Buffer Non-Referenced Delay = 30 Seconds". Now here's one that just by reading it makes sense? right? Actually what this is, is the amount of time the system waits before writing current memory transactions to disk. Back to the store: you wouldn't want to checkout with a few items at a time right, repeating the process once you've gotten everything on your list right? Well, this setting keeps the server from having to write to disk what is contained in memory too often. If this process is done too often it becomes inefficient - with a half empty cart. As a rule of thumb; disk writes are much slower than memory writes.
- Set the Minimum Directory Cache Buffers = 2,500. This is directly related to memory. This setting specifies the number of disk reads/writes that are available upon startup.
- Set the Maximum Directory Cache Buffers = 10,000. This setting protects the server and message store by not allowing the Operating System to do too much in memory before committing the data to disk.
- Set the "Minimum Packet Receive Buffers = 2,500". Buffers equate to memory. This setting allocates enough memory for use connectivity on a relatively small Post Office (80-90 users).
- Set the "Maximum Packet Receive Buffers = 10,000". This is just a maximum, and will not be used unless needed.
- Set the "Maximum Concurrent Disk Cache Writes = 600". This setting allows a specific amount of data to be written simultaneously to the disk.
- Set the Maximum Concurrent Directory Cache Writes = 75". This is a setting relates to memory reads and writes.
- Set the "TCP Defend Land Attacks = Off". This process allows for faster TCP communication. The setting in the "on" state prevents looping packets, causing server communication issues and eventual "denial of service type activity". IT sounds lie something that should be turned off, but this does cause a lot of overhead in communication and that directly correlates to your end-user experience.
- Set SMP Enabled (NetWare 5 and above). This activates multi-processors.
- And finally here's a list of setting that assist with NCP. These setting assist with general communication errors, helping the Operating System keep things clean as they pertain to collisions and malformed packets.
Set display NCP bad component warnings = ON
Set reject NCP Packets with bad components = ON
Set display NCP Bad Packet length warning = ON
Set reject NCP Packets with bad lengths = ON
|Post Office Specific Settings|
Configure the agents via the link configuration tool. Generally in a dedicated WAN scenario all agents should be connected to each other via TCP/IP. This is the optimal scenario, but there may be some situations where you would want to configure traffic in a different manner.
Set the WPCSIN and WPCSOUT directories (and subdirectories) to purge immediate. This is done through Console One, at the volume object. You will need to select all of the subdirectories here, and it can be done through "properties of multiple objects".
Delivery Mode should be set to use application threshold.
|Post Office Agent Specific Settings|
Set the Automatic Database Recovery = ON. This is under the properties of the POA object and the Agent Settings tab. This allows GroupWise to automatically repair a damaged database without administrative actions taken.
Set Enable Caching = ON. This allows the POA to cache the databases in memory. This can assist with backups and overall performance as the POA doesn't have to go to disk for everything.
Set Enable SNMP = OFF. The core Operating System can handle SNMP queries, so this is not necessary for the POA.
Set the TCP Handler Thread = 50. NOTE: This setting assumes that you're running Post Offices with over 700 users, or a lesser number of users (generally over 500) that are very active. TCP handlers are used for communication for client access and domain to domain communication.
Turn on QuickFinder Indexing = 4 Hrs. This can impact performance for users in a positive manner as the indexes will be most up to date, without impacting disk requests on a more frequent basis. Plan this in conjunction with other scheduled events and maintenance processes.
Set the Maximum Application Connections = 4,000. This again is for Post Offices that have a high number of users. This setting will directly impact memory, each application connection reserves 8KB of memory.
Set the Maximum Physical Connections = 1,000. Generally the rule of thumb is one connection per user. I always estimate high on this setting as the 1 per user recommendation does not account for proxy and busy searching.
As a GroupWise specific server, you can configure the CPU Utilization = 85%. This assumes that GroupWise is the main purpose for this server and can take up more processor.
Delay Time = 100 Milliseconds. This is standard for GroupWise.
Access Mode set to Client/Server Access Only - this is IP application connections only. There may be times when a direct access is needed, but those times are few and far between and generally used in an offline manner.
Perform User Upkeep = ON. This setting is the amount of time past midnight, keep in mind this can impact any other scheduled event or settings, so plan this out ahead of time. This process advances tasks, syncs the system address book with the frequent contacts, and dumps items no longer needed in the account based on expiration.
|Post Office Maintenance Strategy (for M01 Servers)|
In order to keep the system running efficiently and cleanly for the users (less errors, corruption, etc.) you should plan periodic maintenance. In a heavily used system, I recommend something like the following.
- Run nightly Analyze and Fix Database on user database only (Structure, Index, Contents and Fix problems)
- Default Disk Check Event (200MB)
Generally on a weekend you can do more, if the office is closed. Take advantage of this by scheduling the following:
- Expire and Reduce Messages Trash Limit to 7 days
- Expire and Reduce Messages to 100 Days (InBox and OutBox)
- Analyze and Fix Databases on user and message databases (Structure, contents, index and fix problems)
|Domain Specific Settings|
- Set the MSLOCAL directory (and subdirectories) to purge immediate. This is done through Console One, at the volume object.
|Additional Information (added 8 Jul 2003)|
Based on recent experience with some of the new workstation operating systems on the market, NIC speed and duplex is handled differently and can impact end-user performance. With one particular OS, the packet negotiation traffic was seen to be quite chatty on the network and caused some serious degradation in almost every aspect of network resource services requested by the workstation. A simple change at the workstation to match what was already hard-coded at both the server and network side increased workstation performance tremendously. This was seen in simple things like file copy comparison, where the workstation was specifically set (speed and duplex) files are transferred instantly as compared to 10-15 seconds on those that were left up to the workstation.
As one of the readers mentioned; the server-side will negotiate during startup, this pertains to NetWare specifically, you may want to keep a close eye on some other Operating Systems that "double" as workstation and server operating systems. My recommendation of course is; why take the chance? Hard-code the entire path, it's relatively easy to do and can save you troubleshooting time and the additional time it takes to re-configure the environment.
This article should be used as an outline for GroupWise Tuning. There are a lot of other resources regarding tips and best practices for optimization, these are things that I've seen over the years that have a big impact on performance. As always, you need to examine your situation before implementing suggestions such as these. As I've stated before, all of my research and development was done to handle 800 users connected to a server from various points across a WAN, over links that range from 56 - T1 speeds.
Watch for more articles by Dave Muldoon, every couple of weeks, under the resources link on GroupWise Cool Solutions - http://www.novell.com/coolsolutions/gwmag/features/trenches/tr_how_dave_does_it_gw.html.