Operate running systems →mediumMultiple Choice

EX200 Operate running systems Practice Question

A server running Red Hat Enterprise Linux 9 experiences high system load (load average 15 on a 4-core system) and slow response times. The administrator runs 'top' and sees that the 'kworker' processes are consuming significant CPU time. Further investigation reveals that the system is performing heavy I/O operations on the root filesystem, which is formatted as XFS. The administrator wants to reduce the impact of filesystem maintenance tasks on system performance. Which of the following actions should the administrator take?

⚠ Common exam trap

Test-takers frequently confuse filesystem maintenance tasks (like fsck or atime updates) with kernel writeback mechanisms, and incorrectly choose options that address metadata or integrity checks rather than the actual I/O load caused by dirty page flushing.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Set the dirty ratio sysctl parameters (vm.dirty_ratio and vm.dirty_background_ratio) to lower values.

The high system load is caused by heavy I/O operations, and the kworker processes indicate kernel threads handling writeback. Lowering vm.dirty_ratio and vm.dirty_background_ratio reduces the amount of dirty pages that accumulate before writeback begins, which prevents large bursts of I/O and smooths out disk writes, thereby reducing the impact on system performance.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Increase the value of the 'nr_requests' queue parameter for the underlying block device.
Why it's wrong here
Increasing nr_requests enlarges the I/O request queue for the block device, allowing more outstanding requests but doing nothing to change how the page cache accumulates dirty pages. This does not reduce the CPU overhead of the kworkers that perform writeback; in fact, a deeper queue can exacerbate bursty I/O rather than smoothing it. The high-load symptom here originates in memory dirtying rates, not in the request queue depth.
✗
Mount the filesystem with the 'noatime' option to reduce metadata updates.
Why it's wrong here
Mounting with noatime disables access-time updates, which eliminates a class of small metadata writes and can reduce overall write load in some workloads. However, the described bursty writeback is caused by the kernel's page cache writeback thresholds, not by atime updates. Even without atime writes, dirty page accumulation would still occur and trigger the same kworker-driven flush bursts, so this option does not address the actual mechanism.
✗
Schedule filesystem checks (fsck) to run during off-peak hours using a cron job.
Why it's wrong here
Scheduling fsck with cron defers filesystem checks to off-peak hours, but those checks are not running and are unrelated to the current writeback load. Filesystem integrity checks are offline maintenance operations that require the filesystem to be unmounted or otherwise quiesced, so they cannot influence ongoing I/O patterns. This option mistakes routine maintenance for a performance tuning action and provides no immediate relief.
✓
Set the dirty ratio sysctl parameters (vm.dirty_ratio and vm.dirty_background_ratio) to lower values.
Why this is correct
Lowering vm.dirty_ratio and vm.dirty_background_ratio reduces the amount of dirty page cache allowed to accumulate before the kernel forces writeback. This causes the flusher threads to run more frequently with smaller batches, which smooths I/O bursts and prevents the CPU and disk from being pegged by large writeback spikes. These parameters directly control the dirty-page writeback behavior described in the scenario, making them the correct tuning target.

Go deeper

EX200 Operate running systems Practice Question

Why each option matters

Option-by-option breakdown

Related to this question