PAS-C01 · Question #140
Business users are reporting timeouts during periods of peak query activity on an enterprise SAP HANA data mart. An SAP system administrator has discovered that at peak volume, the CPU utilization inc
The correct answer is B. Migrate the SAP HANA database to an EC2 High Memory instance with a larger number of E. Change to a supported compute optimized instance type for SAP HANA.. The bottleneck is clearly CPU - not memory (only ~57% of RAM is used) and not I/O (wait times are unchanged). Extensive tuning has already been attempted. The solution must address CPU capacity. Why B (Migrate to EC2 High Memory instance with more vCPUs) is correct: AWS High Memo
Question
Business users are reporting timeouts during periods of peak query activity on an enterprise SAP HANA data mart. An SAP system administrator has discovered that at peak volume, the CPU utilization increases rapidly to 100% for extended periods on the x1.32xlarge Amazon EC2 instance where the database is installed. However, the SAP HANA database is occupying only 1,120 GiB of the available 1,952 GiB on the instance. I/O wait times are not increasing. Extensive query tuning and system tuning have not resolved this performance problem. Which solutions should the SAP system administrator use to improve the performance? (Choose two.)
Options
- AReduce the global_allocation_limit parameter to 1,120 GiB.
- BMigrate the SAP HANA database to an EC2 High Memory instance with a larger number of
- CMove to a scale-out architecture for SAP HANA with at least three x1. 16xlarge instances.
- DModify the Amazon Elastic Block Store (Amazon EBS) volume type from General Purpose to
- EChange to a supported compute optimized instance type for SAP HANA.
How the community answered
(28 responses)- A25% (7)
- B57% (16)
- C11% (3)
- D7% (2)
Explanation
The bottleneck is clearly CPU - not memory (only ~57% of RAM is used) and not I/O (wait times are unchanged). Extensive tuning has already been attempted. The solution must address CPU capacity.
Why B (Migrate to EC2 High Memory instance with more vCPUs) is correct: AWS High Memory instances (e.g., u-6tb1, u-9tb1, u-12tb1) are SAP HANA certified and offer significantly more vCPUs than the x1.32xlarge (which has 128 vCPUs). Moving to a High Memory instance with a higher vCPU count directly increases parallel query processing capacity, relieving the CPU saturation at peak load.
Why E (Change to a supported compute-optimized instance type for SAP HANA) is correct: Certain SAP HANA-certified instances are optimized for CPU performance rather than maximum memory, such as the x2iezn, which features high-frequency Intel Xeon Scalable processors. Since the database only uses 1,120 GiB, the system does not need the full 1,952 GiB of the x1.32xlarge. Moving to a compute-optimized, SAP-certified instance provides better CPU throughput for the actual workload footprint.
Why the others are wrong:
- A (Reduce global_allocation_limit to 1,120 GiB): This restricts HANA's memory ceiling but does nothing for CPU. It would have zero positive effect on CPU saturation and could actually cause memory pressure if usage grows.
- C (Scale-out with three x1.16xlarge): While scale-out distributes load, the existing workload (1,120 GiB) fits comfortably on a single node. A scale-out architecture adds significant operational complexity and cost, and is not the right first step when a larger single-node instance solves the problem.
- D (Change EBS volume type to Provisioned IOPS): I/O wait times are explicitly not increasing. This change addresses a storage bottleneck that does not exist in this scenario.
Topics
Community Discussion
No community discussion yet for this question.