SAP Performance Optimization: Stop Guessing, Start Measuring

Arjun Mehta breaks down what you need to know

After 25 years on SAP systems, I can tell you that most performance problems are not caused by undersized hardware. They are caused by ignored sizing assumptions, memory parameters set once and forgotten, and monitoring that only starts after users complain. The SAP Press performance optimization guide covers the full landscape, but here is what actually matters for day-to-day practitioners.

The Real Story

Performance tuning is not a one-time project. It is an operational discipline. Too many teams follow a pattern: buy hardware based on a vendor presales deck, apply default installation parameters, then wait for trouble tickets. The system runs fine in the first month, then slows down as background jobs pile up and transaction profiles shift. By the time anyone looks at ST02, paging has already destroyed response times.

I have seen a production SAP ERP system with 128 GB RAM suffering severe paging because em/initial_size_MB was left at a default suited for a much smaller server. The hardware was fine. The configuration was not. That is the gap we need to close.

Sizing: Match Resources to Actual Workload, Not Slideware

The first mistake is treating sizing as a one-time mathematical exercise with a fixed number of users. SAP publishes Quick Sizer, and it is useful for greenfield estimates, but it cannot replace real workload profiling. Your peak hour may depend on month-end closing, EDI bursts, or custom ABAP programs that Quick Sizer has never seen.

A practical approach:

• Start with ST03N to extract transaction workload by hour, user, and dialog step.
• Use STAD or ST03N to identify response time distribution across dialog, background, and update tasks.
• Review CPU and memory utilization from ST06 over at least two full business cycles, not a single day.
• Compare actual peak users to the original sizing document. I regularly find 30–40% deviation.

For example, a consumer goods client sized their system for 1,200 named users. In production, only 600 logged in daily, but batch revenue recognition programs ran 18 hours a day. The sizing model never accounted for that. The result was not CPU saturation but lock contention and memory fragmentation. The hardware was not too small; the workload profile was wrong.

Memory Management: Stop the Paging Before It Starts

SAP memory is not one bucket. It is split across extended memory, heap memory, roll buffer, and paging buffer. When one area is misconfigured, the system compensates by using heap or paging, which hurts performance. This is where Basis teams need to be proactive.

Key parameters to examine in RZ11 or RZ10:

PHYS_MEMSIZE         = 65536   # total physical memory in MB
em/initial_size_MB   = 16384   # extended memory initial allocation
em/global_area_MB    = 4096    # global extended memory area

## References

- SAP Performance Optimization Guide | Book & E-Book
- [SAP AI Core Documentation](https://help.sap.com/docs/SAP_AI_CORE)
- SAP Community Hub

---

## References

- [SAP AI Core Documentation](https://help.sap.com/docs/SAP_AI_CORE)
- [SAP Community Hub](https://community.sap.com/)
- [SAP Performance Optimization Guide | Book & E-Book](https://www.sap-press.com/sap-performance-optimization-guide_4370/?srsltid=AfmBOooNgzR37RfrEftQ7z3pfUORGCGuhkMGA3IAxrCnmnmk3LHsWNhq)