Today's SAP environments are complex and dynamic. Virtualization of SAP instances and supporting infrastructure introduces new dependencies that make the management of SAP performance and user experience even more difficult, costly, and time consuming.
Some of the toughest SAP service performance problems are the ones where users call the helpdesk and complain that "SAP is slow". SAP administrators often struggle to determine and quickly repair the root-cause of the problem - Is it the SAP server, the virtualization layer, transaction server, the network, storage or the desktop? Meanwhile, critical business processes are impacted, costing your company a lot of money and hurting the reputation of IT operations.
Join SAP performance experts Andre Kemp (Globalwave Consulting) and Srinivas Ramanathan (eG Innovations) and find out how to:
- Solve the toughest SAP performance issues and dramatically enhance user experience, SAP performance, and service uptime
- Achieve real-time, in-depth visibility of the entire SAP environment and easily diagnose every layer of every tier (including the network tier, the web frontend applications, backend databases, storage, and even the virtualization platform)
- Overcome diagnosis complexity and advance to rapid, pre-emptive problem solving
- Empower your SAP helpdesk to do more, simplify troubleshooting and reduce the burden on scarce SAP experts
- Reduce cost through higher uptime, scalability and improved resource utilization
http://www.eginnovations.com
20. SAP/VMware Integration
SAP
Virt counters
saposcol
VMware Tools
Guest SDK API
Guest OS
ESXi
VMware Admin (vCenter)
ESX Active mem usage
ESX swap counters
etc
SAP Integration to
vSphere (SAP Note
1409604 / 1102124)
SAP Admin (txn ST02,OS07N,RZ20)
Extended memory usage
Heap usage
ESX Active mem usage of guest (via API)
shows 1 VMShows 1 JVM on this VM for ease of illustrationNow the key to understanding the JVM structure I show the various memory segments are laid out and what you can tune. This will help you to size the memory requirement. In the diagram shown we have:Then there is the Java Stack, -Xss value, default may vary between JVMs mostly it is 512K, and typically I see it being tuned down 128-192K. Each allocated Java Thread will use up “-Xss” worth of memory that is not part of the Java Heap, i.e. it does not get deducted from the available –Xmx value instead it is allocated natively and hence the memory is provided by the OS.Hence if you have N number of concurrent threads, Nthreads * -Xss is the memory burden on the Guest OS.NOTE I haven't said anything about NIO Direct buffers, for those you will have to rely on your load testing to see what the utilization is.1 VM and 1 JVM for simplicityThe JVM memory regions are made of the JVM Heap which is governed/bounded by [CLICK] –Xmx (Max Heap) and [CLICK] –Xms (initial Heap)In addition to these you have the Perm Gen, this is where Class level information is kept, typical this is a small area, but it can be 256m-512m at times.NOTE: Within the Heap area…Also –Xmn new generation vs tenured, these are segments within the heap, web/large number of temporary object creations favor large 30%+ -Xmn.Not something that really unique to JVM on vSphere, but much more to do with how your Java application behaves