Logo
Back

◆ DBControl

DBControl is a dynamic memory management software product based on expert systems technology. It optimizes memory allocation on Unisys A Series computers running DMSII databases. DBControl users take full advantage of their existing memory configurations and benefit from optimum system throughput. It provides increased multi-tasking levels for both DMSII and non-DMSII jobs while reducing response times and thrashing.

DBControl has considerable monitoring facilities; database performance statistics can be stored to disk and viewed, in real-time, from any COMS or CANDE station. From such a station, the user can easily control and inspect all DBControl's runtime parameters allowing optimal tuning of DBControl and database memory performance.

How a Series Memory is Allocated

To fully understand how DBControl works, it is important to understand the process of A-Series memory allocation. A Series memory is divided into two distinct parts: overlayable memory and save core. The MCP manages overlayable memory using standard virtual memory techniques, paging memory segments to and from disk. The rate of paging is called the overlay rate.

Save core memory is overlayed by DMSII, paging buffers in and out; the result is that there are two totally separate overlay rates for machines running DMSII: an MCP overlay rate within overlayable memory and a DMSII overlay rate within save core memory.

The DMSII never frees memory unless an excessively high amount of memory is allocated. This is because DMSII generally tries to allocate at least one buffer per user per database structure. Since it is rare that a user will access all database structures at any point in time, DMSII tries to allocate far more memory per user than is actually needed. As a result, DMSII gradually consumes memory up to the level set by the Allowed Core parameter, and only releases memory when the DMSII task is brought down.


 

Memory Balancing and What it can do

If memory is not balanced, overall system throughput suffers. Allocating too much memory to DMSII and not enough to other jobs causes MCP's overlay rate to go up. Conversely, allocating too little memory to DMSII causes DMSII's overlay rate to go up. As either overlay rate increases, extra CPU cycles and disk I/Os are wasted just to manage the overlaying. Consequently, less resources are available for user applications, and the entire system runs slower than it could.

In contrast, having memory perfectly allocated among all jobs can yield substantial performance improvements. At this "Magic Memory Balance," no job has more memory than it needs; none has less. A maximum number of jobs run at one time, thrashing is minimized, and response times are kept low. METALOGIC, working to optimize MCP, found that this Magic Memory Balance was achieved when the DMSII overlay rate equalled the MCP overlay rate. The challenge was to find a practical way to make these rates match, for there are no parameters in MCP which directly alter overlay rates.

 

 Two Solutions that Do Not Meet the Challenge

Two commonly-used memory balancing techniques fail to achieve the "Magic Memory Balance":

 The True Memory Balancing Solution

The only really effective method of balancing memory is to adjust the DMSII Allowed Core setting dynamically, approximately every thirty seconds in order to compensate for demand. This way, memory balance is maintained continually. This solution is not humanly possible because an operator or systems programmer would have to evaluate DMSII and MCP overlay rates, run through a complex model to determine the ideal Allowed Core setting, and set the Allowed Core -- every thirty seconds, all day long. Alternatively, computer programs provide the speed to solve the problem but not the expert MCP tuning knowledge required to derive ideal Allowed Core settings.

 Multiple Database Balancing

DBControl can balance memory for any number of DMSII databases. Separate DBControl tasks are assigned to each database; each task works independently, but all are aware of the others' actions by monitoring the total system. High levels of database activity increase the possibility of having overall memory unbalanced. DBControl guarantees that all databases are using memory as efficiently as possible regardless of fluctuations in demand. Development shops can degrade system performance unintentionally by adjusting test database Allowed Core settings very low. The assumption is that a low setting will prevent the test database from slowing down production jobs. In reality, this low setting may actually worsen the problem. While the DMSII development task may use less memory, more overall system resources are consumed due to increased overlaying and throughput suffers. DBControl provides the optimum solution by allocating the perfect amount of memory to the test job relative to its demand and to that of the rest of the system. Figure 1 indicates how DBControl adjusts Allowed Core and Actual Core levels. As processing demands rise and fall throughout the day, DBControl automatically adjusts the system to ideal Allowed Core settings.

 System-wide Improvements

While DBControl adjusts the Allowed Core setting of DMSII tasks, throughput improvements are not limited to jobs which use DMSII. By dynamically levelling overlay rates, DMSII jobs will not consume too much or too little memory. The entire system does less overlaying, user tasks have more CPU cycles, and disk I/O contention is minimized. As a result, user applications have more resources, which helps overall system throughput.

  Intelligent Buffer Allocation Strategies

When DBControl is first run, it evaluates the DMSII database structure and, if needed, reconfigures the database buffer allocations for maximum efficiency. For instance, if read-ahead and/or write-ahead logic has not been accounted for in the original buffer allocation, DBControl resets the allocation to the optimum level. DBControl corrects for existing imbalances in DMSII buffer allocation.

 Special Benefits for LINC Users

LINC users must contend with DMSII Allowed Core settings that are determined by default when the DMSII databases are created. Regardless of size or activity level on a database, LINC sets all Allowed Core settings the same. Running DBControl adjusts memory allocation on LINC databases so that maximum system throughput is achieved. In some LINC shops, DBControl has saved enough memory to permit two additional LINC databases to run concurrently.

 Maximize Your System's Performance

Is it possible that 5% to 20% of your system's potential is now being wasted. During a recent benchmark conducted on a large Unisys A series, DBControl used just ten seconds of processor time for an entire week of memory balancing and improved overall system throughput by five percent. Also, DBControl's memory requirements are quite low, only 1,000 words per active DMSII database. Likewise, DBControl's CPU overhead is negligible compared to the resources saved.

 Statistics and Performance Tuning

DBControl has several controls allowing the user to optimize his database memory, especially ALLOWEDCORE, ensuring that database memory does not exceed or fall below predefined limits (CUMIN and CUMAX). Other parameters control sampling frequency (SAMPLES, INTERVAL, TIMEOUT), reporting and statistics functions (REPORT, STATISTICS) and may be easily accessed or changed for all databases under the control of DBControl, from any COMS or CANDE station.

The MONITOR facility allows the user to collect simple, but very important database performance information such as overlay rates (both database and system), numbers of FORCED and NORMAL overlays, transaction counts and current ALLOWEDCORE vs. actual core figures. This information, stored to disk, can be browsed on-line using MARC-like menu screeds or loaded directly into a PC/Mac spreadsheet to produce standard performance charts. Using this facility, the effects of DBControl on database performance and its optimization of memory at both the database level and system wide, can be quickly judged.