Graham Whaley
c846e9753d
Add library code that can generate a variety of cpu loads across the cluster. Configuration is via environment variables, documented in the .md file. Signed-off-by: Graham Whaley <graham.whaley@intel.com>
3.5 KiB
cpu-load stack stresser
The cpu-load stress functionality of the scaling framework allows you to optionally add a constant CPU stress
load to cluster under test whilst the tests are running. This aids impact analysis of CPU load.
The cpu-load functionality utilises the stress-ng tool
to generate the CPU load. Some of the configuration parameters are taken directoy from the stress-ng command line.
Configuration
cpu-load is configured via a number of environment variables:
| Tool | Description |
|---|---|
| collectd | collectd based statistics/metrics gathering daemonset code |
| lib | General library helper functions for forming and launching workloads, and storing results in a uniform manner to aid later analysis |
| report | Rmarkdown based report generator, used to produce a PDF comparison report of 1 or more sets of results |
| scaling | Tests to measure scaling, such as linear or parallel launching of pods |
| Variable | Description | Default |
|---|---|---|
SMF_CPU_LOAD_NODES |
Set to non-empty to deploy cpu-load stressor |
unset (off) |
SMF_CPU_LOAD_NODES_NCPU |
Number of stressor threads to launch per node | 0 (one per cpu) |
SMF_CPU_LOAD_NODES_PERCENT |
Percentage of CPU to load | unset (100%) |
SMF_CPU_LOAD_NODES_LIMIT |
k8s cpu resource limit to set | unset (none) |
SMF_CPU_LOAD_NODES_REQUEST |
k8s cpu resource request to set | unset (none) |
cpu_load_post_deploy_sleep |
Seconds to sleep for cpu-load deployment to settle |
30 |
SMF_CPU_LOAD_NODES must be set to a non-empty string to enable the cpu-load functionality. cpu-load uses
a daemonSet to deploy one stress-ng single container pod to each active node in the cluster.
Any of the SMF_CPU_LOAD_NODES_* variables can be set, or unset, and the daemonSet pods will be configured
appropriately.
Examples
The combinations of settings available allow a lot of flexibility. Below are some common example setups:
50% CPU load on all cores of all nodes (stress-ng)
Here we allow stress-ng to spawn workers to cover all the CPUs on each node, but ask it to restrict its
bandwidth use to 50% of the CPU. We do not use the k8s limits.
export SMF_CPU_LOAD_NODES=true
#export SMF_CPU_LOAD_NODES_NCPU=
export SMF_CPU_LOAD_NODES_PERCENT=50
#export SMF_CPU_LOAD_NODES_LIMIT=999m
#export SMF_CPU_LOAD_NODES_REQUEST=999m
50% CPU load on 1 un-pinned core of all nodes (k8s limits)
Here we set stress-ng to run a single worker thread at 100% CPU, but use the k8s resource limits to restrict
actual CPU usage to 50%. Because the k8s limit and request are not whole interger units, if the static policy is
in place on the k8s cluster, the pods will be classified as Guaranteed QoS, but will not get pinned to a specific
cpuset.
export SMF_CPU_LOAD_NODES=true
export SMF_CPU_LOAD_NODES_NCPU=1
export SMF_CPU_LOAD_NODES_PERCENT=100
export SMF_CPU_LOAD_NODES_LIMIT=500m
export SMF_CPU_LOAD_NODES_REQUEST=500m
50% CPU load pinned to 1 core, on all nodes
Here we set stress-ng to run a single worker thread at 50% CPU, and use the k8s resource limits to classify the
pod as Guaranteed, and as we are using whole integer units of CPU resource requests, if the static policy manager is
in play, the thread will be pinned to a single cpu cpuset.
export SMF_CPU_LOAD_NODES=true
export SMF_CPU_LOAD_NODES_NCPU=1
export SMF_CPU_LOAD_NODES_PERCENT=50
export SMF_CPU_LOAD_NODES_LIMIT=1
export SMF_CPU_LOAD_NODES_REQUEST=1