Add right-sizing to tasks

Signed-off-by: Alex Ellis (OpenFaaS Ltd) <[email protected]>

Author: alexellis

docs/tasks/cli.md

@@ -1,4 +1,4 @@
-# Actuated CLI
+# Task: Manage Actuated via CLI
 
 Monitor Actuated runners and jobs from the command line.
 

docs/tasks/debug-ssh.md

@@ -1,4 +1,4 @@
-# Example: Debug a job with SSH
+# Task: Debug a job with SSH
 
 If your it's included within your actuated plan, then you can get a shell into any self-hosted runner - including GitHub's own hosted runners.
 

docs/tasks/local-github-cache.md

@@ -1,4 +1,4 @@
-# Run a local GitHub Cache
+# Task: Run a local GitHub Cache
 
 The cache for GitHub Actions can speed up CI/CD pipelines. Hosted runners are placed close to the cache which means the latency is very low. Self-hosted runners can also make good use of this cache. Just like caching container images on the host in [a registry mirror](/tasks/registry-mirror/), you can also get a speed boost over the hosted cache by running your own cache directly on the host.
 

docs/tasks/monitoring.md

@@ -1,4 +1,4 @@
-# Monitoring
+# Task: Monitoring Actuated
 
 !!! info "Our team monitors actuated around the clock, on your behalf"
     The actuated team proactively monitors your servers and build queue for issues. We remediate them on your behalf and for anything cannot be fixed remotely, we'll be in touch via Slack or email.

docs/tasks/registry-mirror.md

@@ -1,4 +1,4 @@
-# Example: Set up a registry mirror
+# Task: Set up a registry mirror
 
 Use-cases:
 

docs/tasks/right-sizing-vm.md

@@ -0,0 +1,67 @@
+# Task: Right size a VM by profiling a job
+
+Use-cases:
+
+* Reduce costs by using smaller VMs that fit the workload better
+* Increase density by running more jobs on the same hardware
+* Improve performance bottlenecks by adding more resources when needed
+
+In the blog post [Right sizing VMs for GitHub Actions](https://actuated.com/blog/right-sizing-vms-github-actions), we introduce the need for profiling (or metering) a running job in order to make sure the VM is the right size for the workload.
+
+A range of metrics are collected in addition to the standard ones like CPU & RAM consumption, vmmeter also shows contention on I/O, whether a job is running out of disk apce, and how many open files are in use. Non-obvious metrics like entropy and I/O contention are also collected, which can also be linked to degraded performance.
+
+## Try it out
+
+Add the following to the top of your worklflow:
+
+```yaml
+steps:
+# vmmeter start
+        - uses: alexellis/setup-arkade@master
+        - uses: self-actuated/vmmeter-action@master
+# vmmeter end
+```
+
+The `vmmeter-action` will run in the background and collect metrics about the job. Its *Post run action* will collect the metrics and upload them to the job's summary.
+
+Here is an example from building a Linux Kernel:
+
+```bash
+Total RAM: 61.2GB
+Total vCPU: 32
+Load averages:
+Max 1 min: 5.76 (18.00%)
+Max 5 min: 1.34 (4.19%)
+Max 15 min: 0.44 (1.38%)
+
+
+RAM usage (10 samples):
+Max RAM usage: 2.348GB
+
+
+Max 10s avg RAM usage: 1.788GB
+Max 1 min avg RAM usage: 1.233GB
+Max 5 min avg RAM usage: 1.233GB
+
+
+Disk read: 405.4MB
+Disk write: 469.6MB
+Max disk I/O inflight: 0
+Free: 45.16GB	Used: 4.66GB	(Total: 52.52GB)
+
+
+Egress adapter RX: 275.6MB
+Egress adapter TX: 1.341MB
+
+
+Entropy min: 256
+Entropy max: 256
+
+
+Max open connections: 23
+Max open files: 1856
+Processes since boot: 19819
+
+
+Run time: 47s
+```