How can we avoid unexpected costs for our MLC Software? Demand can sneak up on us, and that can push our expenses above our budget allocations. Only a watchful eye can prevent higher costs that flow from unexpected spikes in our AVWLC/MLC charges. It’s not the gradual organic growth that gets us into trouble, because businesses understand that workload goes up when sales go up. Rather, it’s the runaway transaction, the large batch job that should have waited for a lower-demand window, the test system that spiked while production was also running at peak workload. The secret is catching these unbudgeted demands and smoothing utilization before the Rolling 4-Hour Average (R4HA) becomes established above our budgetary target. Let’s consider how these challenges present themselves, and what we can do about it.
Here are three examples to consider, and they ways that they present themselves:
- Momentum: A sneaky surprise is a workload that builds momentum in a way that conforms to expected proportions, but at a higher rate. The expected pattern can make it harder to see that the peaks are higher than normal.
- Peaks and Valleys: Unexpected peaks and valleys can hide the fact that the R4HA is climbing. Operations can see the spike in workload, then its taper, perhaps a couple of times before the workload returns to normal. Meanwhile, the average across four hours keeps climbing, leading to a surprise high-water mark with a bill to match.
- Prod and Test: In Db2 Data Sharing, the great news is that Test and Production can be aggregated to provide a price advantage to the customer. With that option comes the necessity of keeping an eye on the aggregate workload. Often Test demand is monitored separately from Production. Kicking off a Performance Test or CI/CD during a peak Production period will give cause for regret when the price tag is presented for the aggregate workload.
How can we avoid a surprise in our workload and its corresponding cost? A classic monitor and alert approach can resolve this predicament. We need to:
- Establish an alert target that is below our budgetary aggregate MSU peak.
- Create a table to hold target MSU values, and another to hold R4HA MSU values at time intervals, perhaps 15 or 30 minutes.
- Write a procedure to interrogate the CVT to get its value, and then populate the MSU table with a row that has Time, CPU and R4HA.
- Schedule a job to compare the current R4HA against its alert value. Alert if it meets or exceeds that value. IT Operations and Business personnel will need to decide if the workload should continue, perhaps due to the happy circumstance of a large order, or be smoothed by postponing non-essential work. Making the Business a part of decision-making around the cost trade-offs for a critical workload really helps to build a partnership between IT and the Business.
Interested in learning more? Please see Session E04 from IDUG 2017 NA with the presentation by Damon Anderson & Michael Cotignola: There’s Gold in them there “peaks”. In addition, I’d like to recognize Steve Loesch and Bob Hill, who worked together with Damon Anderson to get this process coded and implemented.
About Bernie O’Connor
Bernie O’Connor is an IBM Champion and a Director of IT whose other roles included Application Developer, Development Manager, DBA, DBA Manager, Technical Architecture, BI/DW/Analytics, Pricing Analytics, Computer OPS, System Programmers and Admins, Web Services, M&A and Divestitures. Bernie is a member of the IDUG Speaker Hall of Fame, and served as IDUG North America Conference Chair (2005 – Denver), IDUG Board Member (2004-2009), and IDUG President (2007-2008). Bernie is active in the Midwest Db2 Users Group (mwdug.org), and with the Evanta CDO conference. Bernie’s industry experience includes Insurance, Banking, Publishing, Manufacturing and Distribution. Bernie taught at De Paul University, and Bernie serves as a Senior Tech Advisor for an Educational Software Startup.