Triton Consulting

By James Gill

We were lucky enough to get an opportunity to spend a week in the IBM Boeblingen Labs in Germany, to get some hands on experience with DB2 9.8 – pureScale – or Data Sharing on mid-range. 

The platform that we were working with was a five node configuration – two coupling facilities (CFs) and three DB2 member nodes. This was all implemented in three partitioned pSeries p550 servers, with 1TB of disk supporting it. 

On z/OS, the performance and behaviour of the CFs in a Data Sharing Group (DSG) can have an enormous impact on the overall viability of the solution – both in terms of availability and performance. 

In DB2 for z/OS, the CF configuration works as a client-server model. Members in the DSG request actions from the CF, which manages the structures, as well as the client requests.

These requests are delivered to the CF by scheduling them through XES, which queues them for delivery to the CF over XCF. The CF receives the request and can potentially queue them depending on its current workload. The request is dispatched, the answer is resolved and the response is returned to the requester through the XCF transport and XES interface. 

The model is different with pureScale, where the CF is used as a remote data cache – the intelligence being retained in the group members. 

On DB2 pureScale, the CF structures are accessed using the Infiniband (IB) remote direct memory access (RDMA) protocol. This allows a requester on one box to directly interact with a preconfigured data area on another box. Further, the protocol and data access is all managed by the IB cards, without having to interrupt the CPUs to complete any of the operations. This is extremely efficient, especially when coupled with the low latency of IB. So whilst the CFs are presented as simple data areas, the performance of the member interactions is limited only by the capacity in the IB network and horsepower in the IB cards required to access the data areas.

CF implementation in DB2 pureScale has been achieved with three processes:

• ca-server
• ca-mgmnt-lwd
• ca-wdog

These are not currently covered in the DB2 pureScale documentation, but it seems reasonable that one owns the CF structures, one provides restart monitoring and the other provides operational information and management capabilities to the member nodes.

Assessing the performance of the CF is tricky, as the IB network performance is difficult to directly diagnose. As the network stack is not directly involved in the RDMA conversation, tools like netstat do not provide any insight. Further, it does not currently seem possible to detect queuing depths for RDMA requests in the CF IB card.

Having said that, there is a wealth of information available relating to the CF structures themselves and usage levels through enhancements to the db2pd tool. The following are example commands that we used to understand the impact of our workload on the CFs:

db2pd –cfinfo

db2pd –db sample –cfinfo gbp

db2pd –db sample –cfinfo lock

db2pd –db sample –cfinfo lockv

db2pd –db sample –cfinfo list

db2pd –db sample –cfinfo sca

db2pd –db sample –cfinfo 128 perf

We’re looking forwards to the documentation update so that some of the information produced will make more sense!

Note that a lot of the basic information returned by these commands is also available in the SYSIBMADM views implemented in DB2 pureScale. More on these in the following blogs.

We were very impressed by the performance and resilience of DB2 pureScale whilst working in the Labs. These are the main focus of the next two blogs.

This video highlights how easily and instantly you can scale your workloads by simply adding a member to the DB2 pureScale cluster. It also shows how quickly DB2 pureScale recovers in case of a member failure.

For more information on DB2 pureScale read our latest article and download the podcast.

Managing performance and cost has become a significantly more difficult job with capacity planners and performance analysts being asked to defer hardware and software upgrades due to squeezed budgets. Many large IT departments have also seen loss of staff due to redundancy and this has put added pressure on maintaining good application performance.

One of the most effective ways of reducing or containing mainframe costs is through better managing CPU consumption. By slowing down the growth of CPU usage, hardware and software upgrades can be deferred while often improving performance thereby allowing organisations to keep costs down and performance and profitability up.

MIPS Growth in the Mainframe Market
In a recent mainframe market study, IBM reported that the mainframe has seen a 20% compound annual growth rate in MIPS since 2003. Also, In Ovum’s “The state of the mainframe” research, they found that mainframe MIPS growth is averaging around 20 percent per year and large mainframe-centric enterprises have been consistently averaging 35% plus MIPS growth.

Whilst it is good news for businesses to see transactions on the rise, with usage based pricing for z/OS this increase in workload pushes up software costs and can also negatively impact application performance.

The effects of growing MIPS
Performance – Typically, any significant increase in the amount of CPU used by a given workload will result in an associated increase in transaction elapsed times. For performance-critical online workloads, that increase can translate directly into poorer critical business metrics such as customer satisfaction and retention.

Just throwing more MIPS at a poorly-performing DB2 workload does not always address the issue. A 2 hour response time may be reduced to 1.5 hours with more CPU time being available, but the problem might be due to a poor access path and some DBA attention could get it down to 5 seconds. This is especially true of application performance tuning, which is where the majority of performance issues tend to lie.

Cost – Although performance is a key issue for many organisations, the major diver for many IT teams is the need to reduce mainframe resource usage and thereby potentially defer hardware upgrades and reduce monthly MIPS costs. There is also human costs to consider: maintaining an underperforming system takes more time and resource for IT teams and adds pressure from the business teams who are calling for improved response times.

Can tuning do enough to reduce costs?
The majority of customers have significant potential for reducing resource consumption through tuning. This is especially true for those with older applications that haven’t been actively maintained for a while or who have lost some of their deep DB2 skills through retirement or redundancy.

By implementing key tuning procedures, ongoing software costs can be reduced and mainframe upgrades deferred. In addition, application performance will be enhanced and overall TCO reduced.

Check out the full article on IT-Director.com or download the white paper

The majprity of customers have significant potential for reducing resource consumption through tuning.  This is especially true for those with older applications that haven’t been actively maintained for a while or who have lost some of their deep DB2 skills through retirement or redundancy.

By implementing key tuning procedures, ongoing software costs can be reduced and mainframe upgrades deferred. In addition, application performance will be enhanced and overall TCO reduced.

Tuning Challenges
One of the major challenges in any environment, but particularly with client/server applications, is determining which component is responsible for poor response times, although the tools for this are improving. I often liken this to the classic board game of “Cluedo”; one has to logically and methodically eliminate potential culprits until you’re left with the guilty party! Another related challenge is “skills silos”, where a client has the individual skills necessary to resolve a particular issue but no single person has the whole picture and internal culture and/or politics prevent the individuals from communicating and collaborating effectively.

The growing trend towards DB2 workloads running on ERP applications such as SAP and Siebel is also bringing some very different challenges to more traditional workloads.

In recent years the Financial Services industry in particular has been hit hard by audit and compliance regulations. When adding audit trails to existing applications it is very easy to increase the path-length of some transactions by up to 30%. It is critical therefore that these changes are properly designed and implemented to minimise the performance impact.

Performance Culture
It is vital that organisations recognise the business value of designing applications for performance from the outset. The best way to ensure this happens is to instil a “Performance Culture” throughout the organisation. This includes ensuring the availability of good skills and expert advice from the beginning of the application development life cycle, formalised design reviews to validate anticipated performance against requirements and a proactive monitoring and tuning strategy once the application goes live.

The benefits of DB2 mainframe tuning can be felt across the entire business. From the CFO, who will see significant reduction in IT spend, through to the IT teams, who benefit from improved application performance and thus improved customer service, a thorough tuning exercise can indeed improve business performance.

http://www.triton.co.uk/DatabaseTuning.php

We’re delighted to let you know that Triton have joined the UKCMG – Computer Measurement Group.  This fantastic user group is based around sharing information and best practice on issues affecting the management, planning, performance and administration of computer systems – http://www.ukcmg.org.uk/index.html 

UKCMG on LinkedIn

Hope to see many of you there!