I got real problems with performance in BI Launch PAD. For instance, my reports were opening very long time, navigation in BI Launch Pad was awful. Business Users begat to claim.
At the end I fixed this problem. And I got very useful and helpful recipe for this problem.
Let's start.
1. Of course, we should start from updating SAP BO. Last available version is SAP BO SP2. Just took last one.
2. Let's modify the Tomcat setting, because by default they have low value.
Mark "Run Scripts/binaries" and enter credentials for OS.
Or you can schedule it via your OS. For instance use crontab in Linux:
0 23 * * 7 /opt/bo4dev/sqllib/bin/runstats.sh >/dev/null 2&>1
For instance Shell Script for Linux:
Than schedule this sh by cron.
In summary, performance of BO was increased dramatically.
At the end I fixed this problem. And I got very useful and helpful recipe for this problem.
Let's start.
1. Of course, we should start from updating SAP BO. Last available version is SAP BO SP2. Just took last one.
2. Let's modify the Tomcat setting, because by default they have low value.
o JavaHeapSize (-Xmx) from 2G to 4G
o MaxThreads from default (200) to 900
2.1 JavaHeapSize we should modify:
cd <bo inst folder>/sap_bobj/tomcat/bin
nano setenv.sh
2.2 MaxThreads we would modify:
cd /data/bo4dev/sap_bobj/tomcat/conf
nano server.xml
3. Cleaning of old installed patches and service packs from BO. What does it mean?
cd <bo inst folder>/sap_bobj/tomcat/bin
nano setenv.sh
# set the JAVA_OPTS for tomcat
JAVA_OPTS="-d64 -Dbobj.enterprise.home=${BOBJEDIR}enterprise_xi40 -Djava.awt.headless=true -Djava.net.preferIPv4Stack=false -Xmx4g -XX:MaxPermSize=384m -XX:+HeapDumpOnOutOfMemoryError -Xloggc:/data/bo4dev/sap_bobj/tomcat/logs/tomcat.gc.log -XX:+PrintGCDetails -XX:+UseParallelOldGC"
2.2 MaxThreads we would modify:
cd /data/bo4dev/sap_bobj/tomcat/conf
nano server.xml
Define a non-SSL HTTP/1.1 Connector on port 9090
-->
<Connector port="9090" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="900" URIEncoding="UTF-8"/>
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="9090" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
3. Cleaning of old installed patches and service packs from BO. What does it mean?
Just go to <bo inst folder> and run ./modifyOrRemoveProducts.sh (for Linux):
It is clear that i have many various installation on my server. But it is important to delete old installation!
Now you see, that i deleted old one:
4. Cleaning of logging directory, in <bo inst folder>/sap_bobj/logging
o Deleting Trace-Files
o Deleting Logs old than 30 days
5. Tuning APS, for start we can use CMC Wizard.
6. APS properties for tracing set to unspecified (-> means bo_trace.ini are used)
Level
|
Description
|
Unspecified
|
Force the use of BO_trace.ini to be used
|
None
|
Only critical events such as failures will be logged
|
Low
|
Ignores warning and status messages
|
Medium
|
Only Status messages with least important will be ignored
|
High
|
Includes all the logging messages
|
7. Correction of blocking auditing activities, delete auditing events old 30 days:
In CMC go to Auditing and change parameter "Delete Events Older Than (Days)" on 30 from 365
8. Disabling of unused services in the CMC, for instance, Crystal, Analyses services.
9. Reorganisation of BO-Repository and BO-Auditing in DB2 (runstats) (Script is available in the filesystem). This one is high important point. As you know, every database has to manage its statistics according to number of rows. And if you do not collect stat, than you performance as well as refresh rate are decreasing. I used DB2 db, because it was by default with distrib for Linux.
Now we have to collect stat on all DB2 tables in our BO repository as well as AUDIT repository.
Go to DB2 folder, you can find it in home folder of BO linux user:
cd <user's home folder>/sqllib/bin
There are two files:
runstats_audit.out
runstats_repo.out
They are responsible for collecting of DB2 statistics.
Just perform these scripts:
#db2 -tvf runstats_audit.out
#db2 -tvf runstats_repo.out
You have to schedule this task, and perform these scripts once per week.
You can do it via CMC:
CMC->Applications->Right Button on CMC and choose Program Objects Rights.
Now we have to collect stat on all DB2 tables in our BO repository as well as AUDIT repository.
Go to DB2 folder, you can find it in home folder of BO linux user:
cd <user's home folder>/sqllib/bin
There are two files:
runstats_audit.out
runstats_repo.out
They are responsible for collecting of DB2 statistics.
Just perform these scripts:
#db2 -tvf runstats_audit.out
#db2 -tvf runstats_repo.out
You have to schedule this task, and perform these scripts once per week.
You can do it via CMC:
CMC->Applications->Right Button on CMC and choose Program Objects Rights.
Mark "Run Scripts/binaries" and enter credentials for OS.
Or you can schedule it via your OS. For instance use crontab in Linux:
0 23 * * 7 /opt/bo4dev/sqllib/bin/runstats.sh >/dev/null 2&>1
For instance Shell Script for Linux:
db2 connect to boe14
db2 -tvf runstats_repo.out
db2 connect to audboe14
db2 -tvf runstats_audit.out
Than schedule this sh by cron.
In summary, performance of BO was increased dramatically.
