System and method for configuring a server computer for optimal performance for a particular server type5819030Abstract A technique for configuring a server computer using an optimizer program to achieve optimal performance of the server based on the server types supported by the server. Configuration may involve both calculating server configuration parameters and deciding where to place various files used by the server. In order to decide where to place files, the hardware and software characteristics of the server disk drives are analyzed, and a performance table is generated. The disk drive performance data is then input into a series of algorithms of varying complexity to determine the drives where database files should be stored. Information regarding server utilization, the number of host users and the number of users in the organization is received from an administrator. The administrator input is used to calculate configuration parameters. The optimizer program may automatically adjust a plurality of registry parameters, and may automatically move one or more database and log files to the appropriate disk drives. Alternately, the administrator may be prompted to authorize the changes. The optimizer program may also save the changed parameters and locations to a registry log file. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE I
______________________________________
Row MB of physical RAM
No. of base total buffers
______________________________________
0 16 or less 250
1 17-24 700
2 25-32 1000
3 33-48 2500
4 49-64 5000
5 65 and over **see below
______________________________________
Referring to Table I, the "Number of base total buffers" column indicates the initial number of total buffers allocated for use by both the MDB and DSA database engine components based on the amount of physical RAM in the server. However, several adjustments may be required in the amount of RAM actually available in order to arrive at the correct total number of buffers that should be assigned. For example, if the server is running on RISC hardware (For example, Alpha, MIPS, or PPC), 4 MB is subtracted from the amount of physical RAM because these architectures require more memory to operate effectively. The resulting number is then used as the amount of physical RAM in the machine from that point on. In addition, the amount of physical RAM is further reduced by 10% if the connector role is chosen and by 5%. if the server configuration includes one or more gateway connections. If both conditions are true, the result is inclusive, so 15% would be subtracted. These adjustments account for the increased resource requirements for these types of configurations. Consequently, before progressing with buffer tuning calculations, the amount of physical RAM specified by the administrator as being available in the computer (in kilobytes) is adjusted by the following equation: RAM.sub.K =RAM-(20.times.cUsers) The variable "cUsers" is the number of users the administrator has chosen to host on this server. The actual total number of buffers is then calculated as follows: ##EQU1## where "M" is the amount of RAM in kilobytes in the server (from Table I, first column and using the second number) and "Buf" is the number of base total buffers (column 2 of Table I). The subscripts "k and "k-1" denote the current row and previous row table values. For the case where 16 MB of RAM is available, and there is no previous row table value, then the base total buffers number from Table I is used as the actual total buffers. For example, a 64 MB machine hosting 250 users would use the following formula: RAM.sub.K =65536-(20.times.250)=60536 kB In this case, k=4, because 64 MB appears in row four in Table I above. Then, using the above equation for cBuf: ##EQU2## And this yields 4,236 buffers. If the server has 65 MB or more of RAM, the total number of buffers is calculated as follows: ##EQU3## In this formula, Buf.sub.n is the last entry of base total buffers in Table I above, which is always 5,000. For example, if a server contains 128 MB of RAM and hosts 250 users, the total number of buffers would be 14,313. This calculation takes RAM.sub.k into consideration, which is calculated according to the equation described above. Now that the total number of buffers has been determined, the percentage of buffers for use by the MDB and DSA database engines from this pool will be allocated. This number will vary depending on the server type, and may be calculated using an algorithm. The following Table II provides an example describing this relationship:
TABLE II
______________________________________
Percentage of buffers
Percentage of buffers
Type of Server
allocated to the MDB
allocated to the DSA
______________________________________
Private 80% 20%
Public Only
85% 15%
Backbone 20% 80%
Gateway 70% 30%
______________________________________
If any combination of these server types is chosen, then the resulting percentage is taken as the average of the server type values. For example, if the administrator chose Private, Public, and Gateway server types, the percentage of buffers assigned to the DSA database engine would be: ##EQU4## An additional 10% is added to this result if the administrator indicates that the server is a gateway configuration, or has the private server role included, and the number of organization users is 100,000 or more. This increase in allocated buffers accounts for the more intensive directory service utilization in larger organizations. However, the DSA is limited to a maximum number of buffers. Thus, if the calculated amount of DSA buffers exceeds a certain maximum value, the maximum value is used instead. The following Table III describes the maximum values used:
TABLE III
______________________________________
No. of Users in Organization
Maximum No. of DSA Buffers
______________________________________
up to 100 100
1,000 1000
10,000 10000
100,000 100000
More than 100,000 No Maximum
______________________________________
Any buffers not consumed because of this maximum are reassigned to the MDB database engine. This ensures the total number of buffers are always allocated. In summary, first the total number of required buffers to be used is determined, and then their allocation between the DSA and MDB database engines depends upon the server type and number of users in the organization. The MDB and DSA each include a registry parameter for setting the maximum number of session threads that will be created to service an incoming request. In addition, the MDB also includes a registry parameter for setting a minimum number of threads that exist at any time. FIG. 3A is a table 30 illustrating how these parameters are set based on the number of expected users on the server. In FIG. 3A, the DSA Maximum Threads column is set at 50 for all numbers of users to avoid problems encountered when this value is set too low. FIG. 3B is a table 32 listing the various MTA parameters and how they are set, which depends on whether the computer is a single server or a multi-server. FIG. 3C is a table 34 listing the various MDB and DSA parameters and their settings. The values for the MDB and DSA buffer parameters in FIG. 3C are calculated depending on the number of users and the role of the server, as described above. The values for the MDB minimum and maximum threads and the DSA maximum threads are shown in the table of FIG. 3A. After determining how the registry parameters should be tuned, the logical disk drives of the server are analyzed. The optimizer program determines how many disk drives are in the machine, their read and write performance characteristics and their capacity for storing files, as explained below. The DSA, MTA and MDB components shown in FIG. 1 utilize six separate sets of database engine files which may be located on various disk drives. In particular, the DSA utilizes a random-access database file and sequential log files. The MDB utilizes random-access public database file, random-access private database file, and sequential log files. Lastly, the MTA utilizes sequential log files. In order to improve the performance of the server, these files must reside on the best disk drives available. Each physical drive on the server is tested to ascertain its performance characteristics for random-access reading and writing of files for database transactions, and for sequential writing of files for logging activity. Consequently, two different disk algorithms are used. A random-access disk algorithm first creates a 4 megabyte (MB) test file, although the size of the file may be changed if desired. The test file is then used to perform 4 MB worth of random reading and writing of data to the disk drives. The location of the read and write is random, but is sector aligned and will not cause the file to be extended. That is, the last possible location for a read or write will be 4 MB minus the page size. If an error is encountered during a read or write operation, the operation is re-tried. During this test, the behavior of the database engine is imitated as closely as possible. Thus, the same database engine file flags and conventions are used to ensure accurate simulation of the drives for such files. Each logical drive is tested substantially simultaneously to ensure that physical drives having two or more logical partitions are not scored artificially high. It is not realistic to time each partition separately during testing because, during actual use by the server, the partitions on a physical drive would probably be in use at the same time. Such operation drastically reduces the performance of a partitioned disk drive. Therefore, performing the test simultaneously ensures that partitioned drives will be scored lower than other physical disk drives. The second disk algorithm tests sequential behavior when writing log files. Log files are written sequentially onto a disk, and are typically used to recover the server should some type of system crash occur. A 4 MB test file (the test file size may be modified) is created having the same flags used by the database engine. Data is written to the test file in the same manner as the database engine to ensure accurate simulation of use of the drives for such files. The test consists of starting a timer before the first write and then stopping the timer when all writes have succeeded. Each write is one page length and a total of 4 MB of writes are performed. All logical disks are tested substantially simultaneously using multiple threads, which permits the easy detection of disks partitioned with two logical drives on the same physical disk. After the random-access and sequential tests are completed, the average access times for writing and reading large amounts of data are used to generate a score in milliseconds for each disk drive that indicates how well it performed. Table IV, below, lists the score each of four drives in a server achieved after being tested by the random-access and sequential disk algorithms.
TABLE IV
______________________________________
Drive Random-Access
Sequential
______________________________________
C: 3000 5000
D: 7000 5100
E: 5500 8000
F: 6900 7700
______________________________________
When the drives in Table IV are considered in order to make decisions regarding where certain files should be stored, factors other than disk read and write speed will sometimes play a role. For example, drive C: has the best sequential access time and by far the best random-access time. However, if a particular set of log files should be stored on the best sequential drive, it makes sense to store them on drive D:, the second best sequential drive, rather than on drive C: because it would be more beneficial to use drive C: for a database file that requires the best random-access drive. Other disk drive considerations are discussed in detail below. Once the disk drives have been tested for performance times, they are then analyzed to determine which drives should be used to store the various server files. There are six sets of server files that must be placed on the disk drives: a Private Information Store (PRV) database file, a Public Information Store (PUB) database file, a Directory Service (DS) Database file, Information Store (IS) Log files, Directory Service Log files and Message Transfer Agent (MTA) Log files. It is preferable to utilize random-access disk drives for the database files, and separate sequential disk drives for the log files, but this may not always be possible. FIG. 4A is a flowchart illustrating the steps involved to assign the DS log files, the IS log files, the PUB database file and the PRV database file to the disk drives. These files are assigned before assigning the MTA log files and the DS database file. In step 100, if the server has only one drive then in step 101 all of the database and log files are assigned to that drive. If the server has more than one drive, then in step 102 the largest (L) and smallest (S) drives are identified. Next, in step 104, the difference between the largest and smallest drives is determined, and if it is greater than 20% of the largest drive then in step 106 the Public Store database files (PUB) and the Private Store database files (PRV) are assigned to the largest drive. Next, in step 108, if the computer has less than 64 MB of RAM and only one drive with a pagefile on it, in step 110 the best sequential drive is chosen, without considering the pagefile drive, and the Directory Service Log (DS Log) and Information Store Log (IS Log) files are assigned to that best sequential drive. The best sequential disk drive has the best sequential access timing score (lowest time), and meets all of the following criteria. First, the drive must not have been excluded from consideration by the administrator or because it is too full. Second, a set of files has not already been assigned to it. Lastly, the best sequential disk drive does not contain a pagefile, or does but otherwise scored better than other drives that also contain pagefiles. A second best sequential disk drive meets the same criteria, but the first choice is discarded in favor of the second choice. Again referring to FIG. 4A, in step 108 if the server computer has more than 64 MB of RAM, then in step 112, the best sequential disk drive other than the pagefile drive is chosen, and the Directory Service (DS) Logs and Information Store (IS) Logs are assigned to that best sequential drive. Referring now to step 104 of FIG. 4A, if the difference between the largest disk drive and smallest disk drive is less than 20% of the largest drive, then in step 114 it is determined if the amount of RAM is greater than or equal to 64 MB. If so, in step 116, the biggest difference between the two best random-access drive times and two best sequential drive times are calculated. If the difference between the two best sequential times is greater than or equal to the difference between the two best random-access times then the sequential test is deemed to have the biggest difference in performance time. Otherwise the random-access test has the biggest difference in performance time. Thus, in step 118, if the result is that the random-access tests showed the larger difference in timings of the various drives, then the Public Store (PUB) and Private Store (PRV) database files should be assigned first to the best random drive. Thus, in step 120 the best random-access disk drive, other than the pagefile drive, is chosen and the Private and Public Store files are assigned to that drive. The best random-access disk drive has the best random-access timing score (lowest time), and meets all of the following criteria. First, the drive has not been excluded from consideration by the administrator or because it is too full. Second, a set of files has not been already assigned to it. Lastly, the best random-access disk drive does not contain a pagefile, or does but otherwise scored better than other random-access drives having pagefiles. A second best random-access disk drive meets the same criteria but the first choice is discarded in favor of the second choice. Again referring to FIG. 4A, in step 122, the DS and IS Log files are assigned to the best sequential disk drive, other than the drive containing the pagefile. If, in step 118, the sequential test showed the biggest difference, then the DS and IS log files should be assigned to the best sequential drive first. Thus, in step 124, the DS and IS Log files are assigned to the best sequential disk drive, other than the drive containing the pagefile. Then, in step 126 the private store (PRV) and public store (PUB) files are assigned to the best random-access drive, other than the drive containing the pagefile. (Note that files are assigned in a different order in steps 124 and 126 than in steps 120 and 122). However, if in step 114, the amount of RAM is less than 64 MB, then in step 128, a decision is made whether or not to pick a random-access drive first. The random-access drives are picked first if only one of the tested disk drives contains a pagefile. If that is not true, then a random-access time difference between the best and second best random-access tests is calculated without considering the pagefile, and a sequential time difference between the best and second best sequential tests is calculated without considering the pagefile. If the random-access time difference is greater than or equal to the sequential time difference, then the random-access drives are chosen first. If not, the sequential drives are chosen first. If the best random-access drive should be chosen first, then in step 130 the Private Store and Public Store files are assigned to that drive. Next, in step 132, the DS and IS Log files are assigned to the best sequential drive. However, if in step 128 the answer is "NO", then it is better to assign the sequential access files first. Thus, in step 134, the DS Log and IS Log files are assigned to the best sequential drive, ignoring the pagefile drive. Then, in step 136, the Private and Public Store files are assigned to the best random-access drive, ignoring the pagefile drive. After the four sets of files discussed above have been assigned to disk drives, the MTA log files and DS database file are assigned. Ideally, each of the files will be put on their own drives to avoid having to read or write two or more database files or log files to the same drive at the same time. FIG. 4B is a flowchart illustrating the steps used to assign the MTA log files and DS database file. In step 150, it is determined whether or not there are any drives left in the server without any file assignments. If not, in step 152 the MTA log files and DS database file are assigned to the same drive as the Information Store database file. Next, in step 154, the server is checked to see if an internet mail connector has been specified. If so, in step 156, all files associated with the internet mail connector are moved to the same drive as the MTA log files. Referring again to step 150 in FIG. 4B, if at least one drive without file assignments is available the routine moves to step 158 which asks if only one drive is left. If so, in step 160 the MTA log files and DS database file are assigned to that drive. The routine then again progresses to step 154 and to step 156 if an internet mail connector was specified. However, in step 158 if more than one drive is present, then in step 162 the DS database file is assigned to the best remaining random-access drive, and in step 164 the MTA log files are assigned to the best remaining sequential drive. Again, after the assignments in steps 162 and 164, the routine progresses to step 154 and to step 156 if an internet mail connector was specified. It should be noted that some files that already exist on a particular disk drive may not be moved, even though a slight performance enhancement could be achieved by moving them to a faster drive. There are two reasons for operating in this manner. First, it has been observed that it is sometimes costly to move database files, and thus that such changes should occur only if there is a significant performance improvement. Second, some administrators will frequently rerun the optimizer program whenever minor changes occur to recalculate server parameters, and it is beneficial in such circumstances to prevent database files from continually being moved between drives in order to achieve only minor performance improvements. After all of the parameters and file locations have been determined, the optimizer program may prompt the user for authorization to store the data files in the recommended drives, and to authorize changing the server parameters. Alternately, files could be moved and parameters changed automatically without requesting authorization. FIG. 5A is an example of a display presented to the administrator after the optimizer program has analyzed the disk drives. The display lists where the various files currently reside and provides recommendations for moving the files to improve server performance. The results reflect the hardware configuration of the server as well as the role the server will play in the client/server organization. The administrator may then hit the "Yes" key to verify that the files should be assigned and moved to the suggested drives, or indicate that she wishes to manually reassign the drives. Alternately, the administrator may cancel all of the proposed changes in favor of continuing with the configuration that existed before the optimizer program executed. If the suggested changes are accepted, the optimizer program moves the files and updates the server parameters. If a set of files cannot be moved because of insufficient disk space or other file errors, the performance optimizer will move the rest of the files and alert the system administrator, as shown in the example warning message display of FIG. 5B. Regarding FIG. 5B, the administrator may manually assign the MTA log files to a drive other than drive C:, or re-run the optimizer program with the instruction to exclude drive C: from consideration. In addition to moving the files to the recommended drives and loading the new server parameters, the optimizer program may save file location data and parameter change data into a server registry. A performance optimizer log file may also be created to keep track of all of the changes made to the server, and to report problems. Each time the optimizer program is run for this server the latest log entries are appended to this file. After the changed parameters are loaded and the files moved to their drives, all of the server services are restarted and will now be running in their optimal configurations. The performance optimizer program incorporates the experience and knowledge of a team of experts who developed and understand the server software. The optimizer program thus addresses the issues that affect the performance of the server, and is a tool that an administrator can use to easily configure the server. Other embodiments of the invention are within the following claims. For example, fewer than all of the disk drives resident on a server may be tested as part of the optimization. The optimization may achieve less than optimal performance.
|
Same subclass Same class Consider this |
||||||||||
