BI 4.0 Platform Tuning – Splitting adaptive servers
This is a fairly well known topic now but it is worth revisiting the reasons why it’s done so we can have an idea of what to aim for in the type and number of adaptive servers to create.
As you probably know much of the work performed by a BI 4 platform is done by two B.I. servers, the Adaptive Processing Server (APS) and the Adaptive Job Server (AJS). These are Adaptive in that they perform tasks for a large number of services required to support the B.I platform.
After creating a standard CMS with all services you will find there is one APS and one AJS each of which supports all of the services available. This will get you started but it is not ideal for a production server as it leads to long startup times, critical services being impacted by less important services and a lack of flexibility in scaling the platform.
For example, the platform search runs as a background service and can be resource hungry so it shouldn’t be competing with your WEBI service that is supporting interactive users and which needs fast response times.
Another reason for splitting the servers is for ease of scaling. This means that you can adjust the memory limits and easily add new instances of an APS and/or AJS to cope with particular types of workload. For example if large numbers of publications are required additional APS and AJS instances can be cloned from a base setup that contains just the publishing services.
SAP note 1694041 has a good description of how to split the services so we won’t go into those details here. Instead we’ll have a look at the best way to do the setup required.
Firstly you can only select services for an APS or AJS when the server is stopped but you do have the ability to clone servers. This gives you a new server that is in a disabled and stopped state and leaves the original server running. Start off with the default server, clone it and give it a name related to its purpose and prefixed with something sensible (I use APS_ and AJS_ but you can use any convention you like – the aim is to make sure you can see your servers).
Once you have a new server then you can right click on it and chose “Select Services”. Initially you will see that it hosts all the available services so you need to remove everything except the services required for this server. For example a Publishing APS would have Publishing and Publishing Post Processing. Next, go into the properties of the server and adjust the Java memory size according to the type of server being created and the physical memory available – a publishing server would typically be given 4 Gb so you would change the Java parameter –Xmx1g to –Xmx4g.
Once you are happy with your new server you can enable and start it. When all of the servers have been setup disable the original and un-tick the selection “Start with CMS”. After testing, the original servers can be deleted if desired.
It’s best to make a checklist of all the services and tick them off as they are added to the new servers to make sure they are all included. It is easy to skip one of the services and end up with that service not being supported by an APS or AJS. If that happens the impact can be fairly obvious and the cause easy to spot. Alternatively, it can be just one feature that fails like saving a report to excel which can take some time to debug as you’ll need to eliminate other causes like security settings, client versions etc.
One problem you can run into when scaling up the servers is that you can hit the maximum number of SAP Java Virtual Machines (JVM) allowed. By default this is set to 32 per SAP system id and a BI4 installation is set to use system id 8 for all of its processes. This is likely to happen if you need to run many publications at once and have created a number of publication servers. As the workload hits these servers they will create new child processes which are each SAP JVM’s in their own right. You can see this happening by viewing the Java processes in task manager on the server. If the number of these increases to 30 and then stays at that level then chances are that some of the publications are failing. The way around this is fairly simple – just increase the number of allowable SAP JVM’s from the default. As long as your server has enough memory and CPU to cope then you can run many more than 32 Java instances. Unfortunately the BI4 default values cannot be changed, instead you must run some of your Adaptive Job Servers under a different SAP system id and increase the SAP JVM count for these. To do this just add the parameter Xjvmx,XsapSystem:09,XX:MaxVMs=<NumberOfProcesses> to the command line of the job server(s) having the problem (i.e. Publication). This gives that set of job servers a completely different limit to the base BI4 system so if your new system had a limit of 64 then your installation could run a total of 96 Java processes concurrently.
One last thing, make sure that the servers have been setup as required before you start scaling the platform by adding new servers. There’s nothing worse than realising you have to increase the memory for an APS after you have created 8 of them.
SAP BI4 SAPJVM No free control area found. Increase number of VMs with option -XX:MaxVMs=<n>. Current value is 32.
- SAP BI4 Adaptive Servers