You may notice that CPU and memory usage on a TrendMiner VM often stays low — sometimes below 25%. This raises the question: why do we have minimum recommend X GB RAM and X vCPU?
Understanding Resource Allocation
TrendMiner is a microservices-based application, where each component runs in its own pod within Kubernetes. Each pod has:
-
Request: Minimum guaranteed CPU and memory.
-
Limit: Maximum resources it can use under load.
Kubernetes schedules (create & run) pods based on requests, not current usage. Even if a pod is idle most of the time, the VM must have enough capacity for all pods’ requests simultaneously.
Visualizing the TrendMiner VM
Below is a simplified view of a TrendMiner VM hosting multiple microservices pods:
Each pod acts like a mini-VM running a single microservice. The TrendMiner VM acts like the hypervisor, guaranteeing resources for all pods at all times.
Why Not Scale Down?
Even if your TrendMiner VM doesn’t look busy, reducing CPU or memory can cause problems:
-
Pods might fail or slow down: Each microservice needs its own guaranteed resources.
-
Services could interfere with each other: Reserved resources keep each microservice running independently.
-
Spikes and maintenance need extra resources: Analytics jobs, multiple users, or upgrades can require more memory and CPU than what’s currently being used.
The recommended VM size keeps TrendMiner stable, fast, and ready for all workloads — even during busy periods or updates.
Key Takeaways
-
VM sizing is based on aggregate pod/microservice resource requests, not average usage.
-
Requests and limits guarantee TrendMiner remains stable and responsive.
-
Scaling below the minimum risks unpredictable behavior or degraded performance.
By following these recommendations, your TrendMiner deployment is always ready for peak workloads and safe operations.