Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
tao_shen
Associate
Associate
0 Kudos

The Growing Importance of Workload Management

The significance of effective workload management in SAP HANA-based systems is becoming more apparent. As businesses experience increases in volume and transactions, the complexity of workloads can rise, potentially leading to notable performance declines and issues with system stability. In this series, we aim to demystify the concept of workload. We will delve into HANA workload patterns and discuss strategies to enhance system performance.

Let's dive in!

 

What Constitutes Workload in the HANA Platform?

Put simply, workload refers to the system load generated by daily operations. The greater the number of tasks the system handles, the heavier the workload becomes. However, this does not imply that a well-sized system cannot manage an increased workload. It is crucial to discern between essential workloads that must be maintained and those that can be eliminated. For example, the load caused by an expensive SQL statement or an unnecessary maintenance job.

So, what do we classify as workload in the HANA platform? Is it merely a count of jobs, or a question of what the system can handle? Answering this is complex. Broadly, workload encompasses sets of requests with shared characteristics, such as request sources or query types. Workload indicators on the HANA platform might include CPU utilization, memory consumption, Disk I/O, network bandwidth, or statistics server readings. But what causes a CPU spike during normal business hours? Is it due to a missing secondary index on a table, or poor design of CDS views transferred to the production system without adequate testing? Understanding the nature of the workload is key to addressing performance issues effectively.

 

The Challenge

Even a well-sized and well-designed large HANA system, while capable of handling regular tasks as planned, may struggle to define a holistic workload pattern or assess the impact of expensive statements. This is compounded by unforeseen data growth and business expansion.

Furthermore, we live in a dynamic world, operate systems in dynamic way. This means that workloads are constantly evolving, unaffected by human intention or planning. In the real world, workloads may vary across different periods:

  • Regular Load: During normal business hours, the workload may be stable. However, costly queries and errors can be unpredictable challenges.
  • Event Load: During special events like holiday sales, workloads can temporarily spike, pushing the system to its limits.
  • Idles & Ops: Systems might experience less load during weekends, but this period can be utilized for non-critical batch jobs and maintenance.
  • Closures: During end-of-month, quarter, or year periods, a mix of regular and extraordinarily high workloads is expected. Preventing system outages during these times is crucial.

This complex mix can confuse both operational teams and end users, potentially leading to misguided decisions like adding new hardware instead of optimizing the current system. Effective planning for system expansion should be based on a thorough understanding of the workload and the elimination of inefficient elements, ensuring more accurate, reliable, and confident expansion expectations.

 

Workload Analysis for the HANA Platform in Multiple Dimensions

Let's delve into something practical. When analyzing workload on the HANA Platform, several critical aspects must be considered.

1. Understanding the Workload Pattern

The first step is to identify the system's workload pattern, which is more crucial than immediately tuning expensive statements. Imagine the system with poor performance as an adversary. To defeat it, you need to understand its structure - the number of jobs, the types of requests it handles, any application-side constraints, and the nature of its most resource-intensive queries. The clearer your understanding, the easier it will be to enhance performance.

HANA is a robust platform, but it can struggle under poorly designed jobs, inadequate configurations, or improper maintenance. By clearly defining the workload pattern and addressing each weak point, we can fully leverage HANA's capabilities.

After all, HANA is powerful!

2. Multi-Dimensional Analysis

To analyze and map HANA workload issues effectively, we employ different layers and pillars:

  • Fundamental Layer: This involves correcting workload-related configurations, including OS, HANA, and ABAP parameters. Proper settings here can prevent many issues unrelated to actual user activities.

  • Next Layer - Four Pillars:

    • CPU Utilization: This includes analyzing resource-intensive queries, concurrency, NUMA contention, missing indices etc.
    • Memory Consumption: Key areas are heap allocator sizes, table sizes, memory leaks, sizes of intermediate results, and again, expensive statements.
    • I/O, Network & Locks: Focus on the network latency, I/O bandwidth, blocked transactions and table locks. Basically, everything that could impact the performance of a successful execution of jobs.
    • HANA Internal Functions: Issues arising from internal functions like merge operations, replications, activities of the statistics server and compression etc.
  • Outermost Layer - Application Analysis: This is critical since limitations in HANA are only resource constraints and don't address root performance issues. Identifying key contributors to workload issues (unexpected user activities, poor job scheduling, critical business hours, unoptimized custom programs) is essential. Bridging gaps between functional teams and customer basis teams is vital for accurately pinpointing and resolving issues.

tao_shen_0-1707965627146.png

Capturing the Optimal Workload for Analysis in HANA Systems

While the SAP HANA system boasts the capability to retain historical monitoring data, it is subject to storage limitations, with the potential for older records to be overwritten in time. It's crucial, therefore, to strategically collect workload data that encompasses critical periods, such as month-end or year-end closing. Taking these factors into account, it is advisable to schedule workload analysis shortly after these peak times, ideally within one to two weeks following a month-end closing, to ensure the most relevant and impactful insights are obtained.

Workload Analysis in HANA: On-Premise vs. Cloud Environments

Does workload analysis differ between SAP HANA on-premise editions and various cloud products? The answer lies in the specific HANA Cloud environment being utilized, such as SAP S/4HANA Cloud Private Edition, SAP S/4HANA Cloud Public Edition, SAP Cloud Platform (SAP Business Technology Platform), or HEC (HANA Enterprise Cloud). While the fundamental principles of workload analysis and pattern recognition remain consistent across HANA on-premise and cloud versions, there are notable differences in the management of workloads.

In cloud environments, certain workload-related parameters may function uniquely (e.g. For HANA Cloud on BTP, please refer to SAP Note 3266082 - FAQ: SAP HANA Cloud - section 9. Which limitations exist for the SAP HANA Cloud?), and some settings available in on-premise systems might not be visible in the cloud. However, the core approach to workload analysis stays largely similar. The primary distinction lies in the teams responsible for system monitoring and maintenance – understanding how to analyze workload is beneficial across all HANA environments.

 

🙉🙈🙊

Workload Analysis for HANA Platform Series

This blog post is part of the 'Workload Analysis for HANA Platform Series'. In upcoming posts, we will delve into how to collect and interpret workload patterns on the HANA platform. Here's what you can look forward to in this series:

Stay tuned as we explore these aspects in detail, providing insights and strategies to optimize your HANA environment.