We have a BI4 installation with a decent amount of memory available (32Gb). I initially sized it using the configuration wizard in CMC as Medium (which created 7 APS on the single node). I also duplicated the Webi Processing Server which is the most significant use of the BI system, and increased the Java memory allocation for Tomcat.
In use the system tends to have a low number of concurrent users (10-15) but some of the reports are sizeable and take a while to refresh (5 minutes+ for some) and can be sluggish in general use (adjusting filters etc).
Actual server memory use stays below 16Gb though, so either we aren’t making the most of the memory, or we simply have too much. I’d like to explore some options for how I can tune the system to better use what we have available though and would appreciate some recommendations for further investigation.
As mentioned above the main use of the system is Webi reports, some Dashboards and minor use of Explorer.
And how many CPUs does your server have?
BusObj Explorer alone requires at least 4 CPUs and 4 or more GB RAM in addition to what SAP BI server already requires.
Tomcat should be configured to use 4 GB RAM for max Java heap size at least
Are you using SSL/httpS?
Have you adjusted Max Java heap size for your various APS’?
Have you looked at your server OS stats, e.g. Task manager etc. to measure load with respect to CPU, I/O, Network?
Which exact version/patch level is your SAP BI server running? Current is 4.1 with SP5.
How large are your Webi reports with respect to retrieved records and number of pages? And are you using JAVA applet? If so try using HTML instead.
I am not sure the duplication of Webi Processing server is of any use in your single node server scenario with that small number of concurrent users of less than 20.
Yeah we aren’t really using it in anger yet and the SAP shift from Explorer to Lumira is putting a dampener on future expansion of that too.
Thanks, I’ll check that. I did up but will verify what I put it up to.
No
APS Analysis is -Xms512m -Xmx2g -XX:MaxPermSize=256m
APS Auditing is -Xms512m -Xmx512m -XX:MaxPermSize=256m
APS Core is -Xms512m -Xmx1g -XX:MaxPermSize=256m
APS DataAccess -Xms512m -Xmx1536m -XX:MaxPermSize=256m
APS LCM is -Xms512m -Xmx768m -XX:MaxPermSize=256m
APS Search is -Xms512m -Xmx2g -XX:MaxPermSize=256m
APS Webi is -Xms512m -Xmx4g -XX:MaxPermSize=256m
Hard to judge with the variable nature but load tends to be very low in general.
BI4.1 SP2p6 though we have plans to go to BI4.1 SP5 soon in the new year.
I will gather some of this info for you. My primary concern is not that performance is bad, more that with the resources available I think it could be a lot better and we aren’t best using what we have. Most users are HTML, heavier users use the JAVA applet.
We experienced an issue when testing load when we went from BI3.1->BI4.1 and this was a solution to stop it impacting users. It’s more of a fail safe than a performance thing.
Since you are using VM ensure that the virtual resources such as CPUs and RAM are RESERVED, this is a strong recommendation by SAP!
For resource usage on your virtualized server the PEAK CPU usage is important, nothing like avg is of value. Also check that your tmp/temp directories are not on a “far away” SAN and is running on SSD, not old style hard disks. Otherwise, only a performance monitoring using VMsphere will tell you where the bottleneck is.
Of course large, complex Webi reports are never gonna be fast…
Also test disabling the Webi report cache under Webi Processing server to see if that increases responsiveness in your particular scenario.
Increase max JAVA Heap size for APS DataAccess (DSL Bridge) to 8 GB RAM.
Check your Platform Search settings, recommended: scheduled/no crawling and MetaData only.
Turn tracing off for all servers and turn off Auditing to test for responsiveness.
What data sources are you using? If no SAP BW or other OLAP get rid of APS Analysis (MDAS).
I still tend to say your server does not have enough CPUs; with your number of APS’ and Explorer running on top I would look at 10+ CPUs.
And do get on SP4 or SP5.
The DSL Bridge may not even be necessary, what type of universes are you reporting on ?
While I agree that SP4 or SP5 would be good, there are WebI calculation changes introduced in SP3 from memory, so you’ll need to check.
With the number of users you have, I don’t think your server CPU is the bottleneck. It should be very easy to tell if your VM is CPU bound, but if you’re not really using Explorer for example, then it’s not going to be consuming CPU.
There are some things that WebI isn’t great for, and if your report is taking 5 minutes just to grab the data, you must be pulling back a lot of rows.
Personally, I would grab the SQL that your Webi report is generating, and run it against your database so you know how long data retrieval is going to take. You then at least know the minimum time for a report. DBAs might be able to suggest some indexes etc that can speed that part up.
You say that the system is sluggish when you adjust filters, so it sounds like you have a large number of rows in your report. This is not WebI’s forte. You may need to look at things like wether cells have “autofit height” set, that cause the server to have to recalculate the number of pages etc.
Sometimes it’s better to look at re-writing your reports. Build a report that has summary data, and then drill through to another report that has the details for the particular ‘org unit/sales area/product line’ etc. That way you avoid having to pull back a million rows when the client really only needs to see a couple of thousand.
Yes I’m aware of this one but it’s something our WinOps team will fight tooth and nail not to do … it’s not how VM is meant to work! … ongoing battle.
Thanks will try that.
I tried scheduling the Platform search to begin with and couldn’t quite understand what was going on. You set a max time for it to run for and it seemed to always use all of that time what ever it was set for. In the end I figured it was actually completing and then starting to crawl for the rest of the time? Is that right? I have restricted it down to MetaData only already.
No SAP BW or OLAP - just various universes linking to a single big data warehouse (Relational DB using SQL Server).
I will set up some additional monitoring - though current usage is low. We just have SCOM for overall CPU usage currently and that stays fairly low - never over 30% in regular usage.
SP5 will go on first couple of weeks in the new year.
Thanks for all the help and have a good Christmas all. :).
Thanks. I work more on the back end side (data warehouse, servers, data services, admin and universes), there is a separate team who do the reports. Heavy use of the filter bar is something they’ve used traditionally on a couple of big reports. They have accepted it’s probably not the best approach and could do with being re-written though. That’s a useful link.
I cannot empasize enough, that this conclusion is in a technical white paper written by SAP COIL (co innovation lab) together with… take a guess… yes, VM !
And reserved does not mean that SAPBI will hug those resources no matter what, instead it will give back resources to the VM pool if not needed, but will demand and get it if load increases.
Nevertheless keep looking at the size and complexity of the involved Webi reports.
Is there a similar one including DataServices too? We went virtual with our DS servers a little while back and overnight job times went from very consistent to what seems more like a random number generator at times. I think there are other contention issues at play than simply processor and memory but we do miss our consistency.
I’ve got a BI4.2 SP3 cluster on two nodes; we are reporting on relational universes only. It was set up with a DSL Bridge APS, a WebI APS and a WebI Processing server on each node.
I’m thinking that we can eliminate one of the DSL Bridge Services - is there any reason why we should have one on each node?
(BOB member since 2009-05-12)
(BOB member since 2002-06-20)
(BOB member since 2009-05-12)
(BOB member since 2002-08-15)
(BOB member since 2002-06-20)
(BOB member since 2002-08-20)