Model 204
Part 1: In-Memory Data Equates to High Performance
By Jim Damon
Now that e-mail, e-commerce and e-business are firmly established as models for conducting nearly all business-to-business and business-to-customer transactions, the in-memory data solution is essential for solving the performance problems created by this staggering demand for data. Compounding the problem are the numerous processing layers -- networks, transmission speeds and protocols, browsers, PC operating systems, emulators -- separating the end user from the data.
Model 204 provides two important features that let you keep virtually all referenced data and active applications in memory, drastically reducing or, in some cases, almost eliminating database and CCATEMP I/O. When these features are enabled, many performance bottlenecks such as record locking, resource locking, and DASD and channel contention are mitigated and may even disappear entirely.
The in-memory data solution available in Model 204 guarantees that the data access portion of this equation can help you deliver data to your end users with subsecond response.
The Central Storage Solution
The key to this solution is the availability of real memory (central storage) backed by expanded storage, which has performance characteristics somewhere between central storage and high speed RAID devices. Together, these forms of memory, which are often under-exploited or sometimes allocated to noncritical applications, constitute the resource used by Model 204 to keep its working setó referenced database pages and active applications -- in memory. The steadily declining cost of memory and the trend toward installing more memory favors the in-memory solution. However, this article is not a "throw more hardware at the problem" approach; it is a discussion of managing the memory you have.
This solution recognizes that to examine, process, update, or query data, the data must be in memory. If the data is not in memory, you must retrieve it (I/O) from some external storage device. I/O represents a delay to an end user or multiple users, who are waiting for the same I/O, and puts them in a wait state. Keeping more data in memory uses more memory. However, more data in memory uses less channel capacity and reduces DASD activity. The in-memory approach shifts the use of machine resources from disks and channels to central storage with the intent of improving performance for business critical applications.
Getting to Know Your Disk Buffer Pool
In Model 204 in-memory data means keeping a large working set of database pages in an area commonly known as the disk buffer pool. You can achieve this by setting the CCAIN parameter, MAXBUF, to a value that accommodates a large working set.
Setting the MAXBUF parameter
The number of disk buffers required to achieve data in-memory varies from site to site. It could range from setting MAXBUF to 10,000 at smaller installations up to setting MAXBUF to 200,000 plus at larger installations. Given the current limitations of XA architecture, and the requirement of 6476 bytes per buffer -- calculated as (6184 plus 256 byte buffer control block plus 36 bytes for hash cells), setting MAXBUF to approximately 300,000 (1.9 Gigabytes) is close to the maximum number of buffers currently available on XA/ESA systems.
However, you cannot achieve large buffer pools unless REGION=0M is set on the EXEC statement for OS/390 systems, or large machine sizes are defined for VM systems, or large partitions for VSE. If this is not done, then the number of buffers requested, MAXBUF, may be less than the number actually allocated, NUMBUF.
Issue VIEW NUMBUF after the run comes up to confirm the number actually allocated. We currently have one customer running with NUMBUF equal to 99,000, one running with 75,000, several with 40,000 plus; and several with 20,000 plus.
Monitoring Paging Rate
After you allocate the desired number of buffers, monitor the system paging rate for the Model 204 Online, which is critical to ensuring good performance. Use an external performance monitor such as SDSF for OS/390; Omegamon or Real-Time Monitor for VM; and so on. Without sufficient central storage to support a large buffer pool, the paging rate for Model 204 may be high and performance will degrade. Good performance requires that the paging rate not exceed 2-3 pages per second in the Model 204 Online. However, a very high paging rate, in the range of 500-1000 pages per second to expanded storage, which is not reported by many monitors, can be tolerated without negative performance effects.
If the paging rate is a problem, you can reduce it in one of the following ways:
Your choice is determined by which applications are critical to your organization.
Tracking Your Adjustments
You can determine whether in-memory data affected performance by comparing before and after system final statistics printed at the end of CCAAUDIT. Or, you can use the MONITOR STATS command while the run is up to observe the statistics in real-time, both before and after the change to MAXBUF and NUMBUF.
The first question to ask is: were all allocated buffers actually used? For example, does the statistic FBMX equal NUMBUF? If yes, then MAXBUF was not set too high and you could allocate additional buffers in the next run.
Next, the truly central question in this exercise is: was physical database I/O -- statistics DKRD and DKWR -- reduced after processing roughly the same amount of work.
The easiest way to determine this is by using the following ratios: DKRD:SCREENS and CPU:SCREENS
For example, suppose your before statistics are:
DKRD SCREENS
10000 1000
and your after statistics are:
2000 1000
As this ratio decreases, both I/O and CPU per transaction are reduced and users should see improved performance.
The buffer pool is managed by a Least Recently Used (LRU) algorithm, which is designed to keep database pages in the disk buffer pool as long as possible. Once a page is read into the buffer pool, that page will remain in a buffer until:
1. It becomes the oldest, unreferenced (LRU) page and the buffer it occupies is needed for a different page or 2. The last user of the file, including APSY, closes the file.
As the number of buffers -- MAXBUF and NUMBUF -- increases, the likelihood that a page read in by User A, and now required by User B, is still in a buffer also increases.
In addition, I/O to CCATEMP, which is effectively Model 204's paging dataset, is reduced and continues to diminish as the number of buffers increases. Reducing CCATEMP I/O alone can provide a significant performance improvement. CCATEMP is one of the most active files in the Online, often accounting for 20 to 25 percent of all I/O.
Coming Attractions
In Part 2 I will discuss in-memory feature, which retains active applications in memory using the Memory Resident Request feature.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
