opensap bifour1 week 1 unit 4 presentation bism

Week 1 Unit 4: BI Sizing -Methodology

2013 SAP AG. All rights reserved. 2Public

BI is I/O Intensive I/O can be more difficult to measure than

CPU and Memory Aggregation of millions of rows more

costly than streaming transactions Balance constant load vs. peak load

BI designed to use all systemresources

Resource Greedy for optimalperformance

No reason to restrict resourceconsumption on per system basis

Throttling outside servers can be donewith vLANs and Storage Tiering

SAP Business Intelligence Considerations


Strategies for Deploying SAP BI

Map out the deployment CMS database is the key to overall

performance and scalability of BIPlatform

Use a dedicated CMS DB, on its ownhardware, to ensure performance

Monitor individual server tiers to identifybottlenecks

Start small and scale out Increase load in 50-200 user steps,

adding services as needed Immediately jumping to 1000 users (or

more) makes root cause analysisimpossible

Test, Analyze Results, Repeat


Evolution of SAP BI 4.x Architecture

BI 4.x is 64-bit XI 3.1 was designed for the entire suite

to fit within a 32-bit architecture BI 4.x is not artificially limited for

resources and is capable of stretchingout to take advantage of modernhardware

BI 4.x is architecturally inclusive XI 3.1 was a collection of apps with their

own connectivity stacks BI 4.x shares a common Semantic Layer

for data connectivity BI 4.x is a first-class and highly

integrated SAP client for BI


Homogeneous vs. Heterogeneous

Scale Up Scaling up has limits but modern hardware

is too powerful to host only singleprocesses

5 instances of Web Intelligence on amachine might make sense but watch outfor bottlenecks such as Disk I/O

If you schedule Crystal Reports mostly atnight, CR Job/Processing servers may co-exist with Web Intelligence

Scale Out Virtualization enables easier scale out as

there is little/no incremental hardware cost

Design principles for scaling out are nodifferent from other enterprise software

When scaling out you may not needservers with vast system resources aseach server will handle part of the overallload


Role of External Systems

Poorly provisioned databases haveinvisible effects

CMS DB latencies have cascadingeffects

I/O bottlenecks have severeimpacts

Starving a BI system for I/O willguarantee poor performance

A slow file server hosting the FRS canalso impact performance

Patch SAP BW systems Incremental performance gains can be

significant Poorly performing WebI documents can

often be traced back to a lack of BWpatches


Understanding the Management / Intelligence Tiers

CMS 400 500 Heavy Users

per instance Add CMS every 500

active concurrent users Best practice is not to

have 2 CMS on thesame physical systemin order to enable faulttolerance and effectiveload balancing

FRS FRS performance

dependent on Disk I/O Input FRS should be

kept close toProcessing Servers asbest practice

Setting Instance Limitsis essential for optimalOutput FRSperformance

RepositoryDatabases System & Audit DB

should be kept close toCMS

If monitoring is enabled,the trend DB shouldalso be kept close

Best practice is not tochoose all servers formonitoring as it cannegatively impactperformance


Sizing Virtual Environments Best Practices

Use strict CPU Reservations for each VM on everyhost

Leverage Memory Reservations to ensure allocatedmemory is always available

Do not use shares, limits, affinity, or other artificialmechanisms to divide VM resources on the host

To avoid excessive swapping, Size VMs large enoughto accommodate very I/O intensive BI workloads.

Use more, smaller sized VMs rather than a few verylarge VM (>16 CPU)


Processing architecture Do you have enough CPU power? Go beyond SAPS Are you set to properly scale your systems out? Are your processes properly distributed across nodes?

Evaluate I/O requirements Consider reporting databases, inter-node communication, I/O links, etc.. CMS DB properly provisioned to ensure low latency/high throughput? DB vendor specific, not part of SAP BI documentation

Memory do you really have enough? Nature of application means spikey and dynamic memory allocations

Building Better BI Systems

Always think about system design and read the manualsDefault systems are just that the default, not optimal


Goal: focus on reliability and consistency, then performance: Reliability: ensure the system is highly available including fault tolerance, etc. Consistency: ensure acceptable performance at heavy loads Performance: move from acceptable to enjoyable experience

Approach: Start with a clean/proven system Capture vital statistics Gradually scale up # of users Analyze tests using the collected metrics Make changes and iterate

Testing & Tuning SAP BI


Aim for 60-65% average CPU utilization That enables peaks to 80-90% w/o setting off data center alerts for high utilization Systems peaking at 100% will impact user sessions

Emphasizes how important it is to scale slowly so you know what to add! What service in that APS is needing more headroom? Whats a better use of your resources, another WEBI service or an additional MDAS?

CMS-specific: CMS are usually on their own machines add additional CMS hosts at 65% utilization Dont get carried away but the old myth of a 2-4 CMS limit is gone as of BI 4.0 SP4

When to Scale

There is no hard and fast rule for scale out, but common practice of 80%utilization is completely inappropriate for bursty, I/O heavy applications like

BI


Be generous with RAM Java allocates memory in heaps which can quickly grab large amounts of RAM Java garbage collection happens more frequently under memory pressure Heavy memory pressure can cause swapping at the OS level

Look at max usage, not average usage: In virtualized scenarios VMware may report low active memory and your infrastructure

team may overcommit memory (which some consider a best practice)

Make sure your infrastructure team understands how BI is different: Most do not understand BI isnt like MS Exchange or a database, BI is bursty!

What about memory?

Business Intelligence is one of the very few applications that does NOThave the performance profile of a typical enterprise application

Thank you

Contact information:

[email protected]


2013 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation orwarranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Groupproducts and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothingherein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG inGermany and other countries.Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

2013 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation orwarranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Groupproducts and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothingherein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG inGermany and other countries.Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

opensap bifour1 week 1 unit 4 presentation bism

Documents

bi system

sap ag

sap bi map

publicevolution of sap

x architecture bi

public bi

peak load bi

bi sizing methodology