Skip to main content

Workload Simulation with Resource Protection

The idea behind resource control is to distribute resources between workloads so that machines can be shared among different tasks without interfering. The sharing workloads can be the web browser and kernel compilation job on your laptop or a web server and maintenance workloads, such as package upgrades and cron jobs. Maybe we want to transcode videos to utilize the unused capacities of the web server.

In this interactive demo, we will use the test workload called rd-hashd. rd-hashd sets up test files from which it serves data requests and measures the end-to-end latency of each request. It tries to serve as many requests as possible without sacrificing response time, similar to how web servers or workloads like memcache operate in load-balanced compute pools. Because it's highly sensitive to latencies, it can also stand in for other applications, such as browsers or similar interactive desktop or mobile applications. While their requests-per-second might be fewer, low latency and fast response time are top priorities for users.

rd-hashd's sensitivity to the steady availability of CPU, memory, and IO makes it an honest indicator of how well resource isolation is working on all fronts on the host. Let's fire up rd-hashd to get rolling:

  • In the demo pane, start rd-hashd at 60% load

Watch the panel on the left to see the RPS ramping up. You can check the logs for warnings and errors as well.

Now that our main workload's running, let's see how it responds to competition. For this purpose, we're going to turn off resource control and launch a compile job and a memory hog. The former will eat up as many CPU cycles as it can get its hands on, along with some memory and IO bandwidth. The latter will keep gobbling up memory, causing memory shortage and subsequent IOs once memory fills up. The combination is a potent antagonist to our interactive rd-hashd.

  • Click the Disable resource control and start the competitions button in the demo pane.

See the graph for the steep drop in RPS for hashd. That's the competitions taking away its resources, which is not good.

Once the workload's memory pressure (memP%) in the top right panel starts spiking, you might not have a lot of time before the whole system starts stalling severely. Let's stop them.

  • Click the Stop the compile job and memory hog button in the demo pane.

Once the RPS climbs back up and the memory usage of workload in the top right panel stops growing, start the same competitions but with resource control enabled and the compile job under the supervision of the sideloader.

  • Click the Start the competitions under full resource control button in the demo pane.

Watch the stable RPS. rd-hashd is now fully protected against the competitions. The compile job and memory hog are throttled. You will see that the compile job doesn't seem to make much progress. This is because sideloads (workloads under the siderloader supersivision) are configured to have lower priority than sysloads (workloads under system). Don't worry about the distinction between sideloads and sysloads for now. We'll revisit them later. Let's stop the memory hog and see what happens.

  • Click the Stop the memory hog button in the demo pane.

You can see that rd-hashd is still doing fine, and the compile job is now making reasonable forward progress: These two workloads are now sharing the machine safely and productively, something that wasn't possible before. Continue reading to learn more about the various components of resource protection that make this possible.