Optimise your SAP BTP, Cloud Foundry runtime costs
Recent talks with customers motivated me to write this blog post on how you can optimize your consumptions and therefore charges for SAP BTP, Cloud Foundry runtime when using the consumption-based models of SAP BTP. The runtime is charged by “GB of memory”, but it wasn’t obvious which amount of memory is taken into consideration.
When you deploy an application either via the user interface or by defining its attributes via YAML, you set the amount of memory which is reserved for each instance (or a default of 1024 MB is set). In the UI, this is called “Memory Quota” and inside a YAML, this is the value
Each hour, this is metered for each application instance in each Space inside a Global Account. At the end of a month, the hourly values are summed-up, divided by 730 hours, and rounded-up to the next full GB which is then charged in case the Global Account is based on the consumption-based model (CPEA or Pay-as-You-Go). An elaborate example for this calculation is given in the SAP Help Portal.
To start optimizing the above value, open your deployed application. You can see the defined value in the UI at “Quota Information > Memory Quota”. The maximum you can define for each instance is the “Instance Memory Limit“.
The memory available for the whole subaccount is shown in the brackets of “Memory Quota” called “available memory“ (see the second “Note” box here).
Further down below in the “Instances” section, you can see how much of the memory quota per instance is currently used. This is visualized with by the green bar of “Memory Usage”.
If you want to analyze the memory usage over time, you can use the “SAP Application Logging Service for SAP BTP“. It retains logs for 7 days and inside the Kibana dashboard of the service instance, you can open “Four Golden Signals > Saturation” and there see the “Memory load” over time. At the top right, you can change the time frame for the charts.
Furthermore, keep in mind that the assigned memory relates to the assigned CPUs. Each GB of memory relates to 1/4 CPU. Therefore, it is important to consider as well the “CPU load” over time which is displayd above the memory load chart.
After learning about the required memory+CPU and potential peaks, you can apply changes to the Memory Quota. Keep in mind that “if an instance exceeds this limit, Cloud Foundry restarts the instance. If an instance exceeds its memory limit repeatedly in a short period of time, Cloud Foundry delays restarting the instance.“ (source)
On top, keep in mind that apps based on certain technologies require a minimum of memory, like Java-based applications.
Avoiding trouble with help of the Application Autoscaler
Once you know the limits you need to set per instance for the vertical scaling, you can start thinking about horizontal scaling to dynamically add instances upon load or time schedule. Have a look into the “Application Autoscaler” service offered inside the SAP BTP to learn more about this.
“Efficient Workload management on SAP Cloud Foundry using Application Autoscaler” elaborates on the topic, too.