InterSystems Data Platforms and performance - Part 5 Monitoring with SNMP

In previous posts I have shown how it is possible to collect historical performance metrics using pButtons. I go to pButtons first because I know it is installed with every Data Platforms instance (Ensemble, Caché, …). However there are other ways to collect, process and display Caché performance metrics in real time either for simple monitoring or more importantly for much more sophisticated operational analytics and capacity planning.

This post will guide you through the process of sizing shared memory requirements for database applications running on InterSystems data platforms. It will cover key aspects such as global and routine buffers, gmheap, and locksize, providing you with a comprehensive understanding. Additionally, it will offer performance tips for configuring servers and virtualizing IRIS applications. Please note that when I refer to IRIS, I include all the data platforms (Ensemble, HealthShare, iKnow, Caché, and IRIS).

Presenter: Murray Oldfield
Task: Avoid bottlenecks caused by scaling up, before they become a problem
Approach: Discuss what operating system and InterSystems metrics you should look at and how to interpret them
 

Systems behave differently when database activity scales up. In the worst case, bottlenecks appear and users are impacted. This session shows you which operating system and InterSystems metrics you should be looking at and how to interpret them so you can head off bottlenecks before they impact users. This sessions also shows strategies for planning infrastructure taking into consideration InterSystems' data platforms requirements.

Content related to this session, including slides, video and additional learning content can be found here.

Presenter: Murray Oldfield
Task: Deploy applications based on InterSystems’ technology using VMware.
Approach: Provide a checklist of factors to consider, particularly when deploying a production database application that requires high availability
 

Are you ready to deploy your applications on a virtualized architecture? This talk will highlight what you need to plan and do when deploying applications built on ISC data platforms using VMware. Special focus on what you need to know when planning for highly available (HA) production database applications.

Content related to this session, including slides, video and additional learning content can be found here.

Previously I showed you how to run pButtons to start collecting performance metrics that we are looking at in this series of posts.

• Part 1 - Getting started on the Journey, collecting metrics
• Part 2 - Looking at the metrics we collected

##Update: May 2020.

Since this post was written several years ago, we have moved from Caché to IRIS. See the comments for an updated link to the documentation for pButtons (Caché) and SystemPerformance (IRIS). Also, a note on how to update your systems to the latest versions of the performance tools.

A short post for now to answer a question that came up. In post two of this series I included graphs of performance data extracted from pButtons. I was asked off-line if there is a quicker way than cut/paste to extract metrics for mgstat etc from a pButtons .html file for easy charting in Excel.

See: - Part 2 - Looking at the metrics we collected

pButtons compiles data it collects into a single html file to make it easier to send to WRC and review the collated data.

This week I am going to look at CPU, one of the primary hardware food groups :) A customer asked me to advise on the following scenario; Their production servers are approaching end of life and its time for a hardware refresh. They are also thinking of consolidating servers by virtualising and want to right-size capacity either bare-metal or virtualized. Today we will look at CPU, in later posts I will explain the approach for right-sizing other key food groups - memory and IO.

In the last post we scheduled 24-hour collections of performance metrics using pButtons. In this post we are going to be looking at a few of the key metrics that are being collected and how they relate to the underlying system hardware. We will also start to explore the relationship between Caché (or any of the InterSystems Data Platforms) metrics and system metrics. And how you can use these metrics to understand the daily beat rate of your systems and diagnose performance problems.

Your application is deployed and everything is running fine. Great, hi-five! Then out of the blue the phone starts to ring off the hook – it’s users complaining that the application is sometimes ‘slow’. But what does that mean? Sometimes? What tools do you have and what statistics should you be looking at to find and resolve this slowness? Is your system infrastructure up to the task of the user load? What infrastructure design questions should you have asked before you went into production? How can you capacity plan for new hardware with confidence and without over-spec'ing? How can you stop the phone ringing? How could you have stopped it ringing in the first place?

Ansible helped me solve the problem of quickly deploying Caché and application components for Data Platforms benchmarks. You can use the same tools and methodology for standing up your test labs, training systems, development or other environments. If you deploy applications at customer sites you could automate much of the deployment and ensure that system, Caché and your application are configured to your applications best practice standards.