CPU requests and limits on Magnolia PaaS

Your Kubernetes clusters on Magnolia PaaS have resource types that are allocated among all the pods and containers running on the clusters, including your Magnolia instances and your frontend instances if you have a headless project. In this case, resource allocation affects how well your site runs.

There are many different resource types, but the most important are CPU and memory:

  • CPU: represents how much compute processing is dedicated to a pod.

  • Memory: in simple terms, this is how much memory a pod can use.

You can specify the memory allocated to your Magnolia instances and your frontend instances when they are started - the memory request for the pod - and you can specify the maximum amount of memory the instances are allowed, the memory limit.

Your Kubernetes clusters on Magnolia PaaS are composed of nodes, each having a finite amount of CPU and memory resources. Magnolia PaaS clusters will usually be composed of 3 or more nodes, each node having 32 GB of memory and 4 CPUs. The cluster will have 96 GB total memory and 12 CPUs total for all pods and containers running on the cluster.

The CPU request for a pod affects where Kubernetes will run the pod: Kubernetes picks a node that has enough memory and CPU to satisfy the memory and CPU requested for the pod. If Kubernetes cannot find a node that has the requested CPU and memory, the pod will not start, so it is important to keep in mind the total memory and CPU resources in your cluster and the total memory and CPU available on the individual nodes in your cluster.

Choose memory, CPU requests, and limits that can be met by both constraints.

Best Practice

Don’t set CPU requests or limits for Magnolia front end pods running on your clusters.

Why shouldn’t you set CPU requests for your Magnolia front end instances?

It is tempting to set CPU requests for your pods to ensure that the pods have sufficient processing power to handle your expected traffic, but you have to take into account all the pods and containers running on your cluster, including essential Kubernetes and Rancher services.

You cannot set CPU requests and limits for your Magnolia instances: the Magnolia Helm chart does not allow the setting of CPU requests and limits for Magnolia instances and their associated databases.

You could modify the deployments for the Magnolia author, publics and their databases and add CPU requests and limits, but we do not recommend doing this either: your changes would be overwritten when you redeploy Magnolia and also could affect the stability of your Magnolia PaaS cluster.

Setting CPU requests and limits for front end pods can affect the stability of your Magnolia instances and your Magnolia PaaS cluster, causing:

  • overcommitment of CPU resources in your cluster

  • missing metrics and logs in your Magnolia PaaS cockpit

  • slow responses from Magnolia

  • random restarts of Magnolia because Magnolia cannot respond to liveness and readiness checks by Kubernetes

  • random restarts of cluster nodes that affect critical Kubernetes services, including access to your Magnolia and front end instances because these services cannot respond to liveness and readiness checks

These consequences can be difficult to distinguish from high load on your production web site and make the appropriate sizing of your cluster difficult to determine.
Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules