Visit here for our full CompTIA XK0-005 exam dumps and practice test questions.
Question 181:
A Linux administrator needs to identify why a specific service is consuming large amounts of I/O bandwidth during peak hours. The engineer suspects that the service is generating heavy disk writes through buffered I/O. Which tool provides per-process I/O statistics showing both read and write rates in real time, including differences between actual I/O and delayed writeback operations?
A) top
B) pidstat -d 1
C) vmstat 1
D) free -h
Answer:
B
Explanation:
The correct answer is pidstat -d 1 because this command provides real-time, per-process I/O statistics, including read and write throughput, I/O delays, and the number of kilobytes read and written per second. Among the available Linux performance tools, pidstat is uniquely suited for isolating individual process-level disk activity, making it the ideal choice when an administrator needs to determine which specific process is generating heavy or unexpected disk I/O during peak activity. This level of detail is essential when investigating performance bottlenecks in systems used for databases, web servers, file servers, virtualization hosts, or any workload that makes intensive use of disk resources.
Option A, top, does not provide detailed disk I/O information. Although top shows basic CPU, memory, and load information for processes, it does not provide per-process I/O rates. Even extended versions of top do not include the level of I/O breakdown needed to observe differences between buffered and actual I/O. Therefore, top is not appropriate in cases requiring granular I/O diagnostics.
Option C, vmstat 1, provides system-wide metrics, including block input/output and swap activity, but it cannot identify which processes are responsible for the I/O load. Vmstat is helpful for observing general system health and memory pressure but lacks the granularity needed for per-process investigative work. It also cannot differentiate between buffered writes and direct writes.
Option D, free -h, displays memory usage including total, used, cache, and swap allocations. However, free does not provide any I/O metrics at all, making it completely unsuitable for diagnosing disk activity or isolating heavy-writing processes.
Pidstat -d 1 is part of the sysstat suite and provides dynamic, per-process I/O statistics in real time. The information includes:
kilobytes read per second
kilobytes written per second
read and write syscall counts
I/O delay times
impact of kernel writeback
process name and PID
These metrics allow the administrator to evaluate how heavily a process is interacting with storage devices. For example, if the administrator suspects that the service is causing high writeback activity due to buffered writes, pidstat reveals how frequently the process triggers write system calls and how much data is being queued for disk operations.
Buffered I/O occurs when processes write to memory rather than directly to disk. The kernel later flushes these writes to disk in batches. This behavior can cause periods of low disk activity followed by intense spikes during flush operations. Pidstat reveals both the per-process write behavior and the rate at which the kernel must push buffered data to disk.
High I/O usage can result from multiple causes:
excessive logging
inefficient database queries
large temporary files
background tasks writing caching data
backup jobs running unexpectedly
misconfigured services that flush too frequently
applications writing small chunks of data too often
services bypassing caching layers and writing directly
Pidstat is also important for determining whether multiple processes are contributing to I/O contention, or whether a single misbehaving process is responsible. It is common in multi-user or multi-service environments for a single service to monopolize I/O bandwidth, resulting in slow performance for others.
Administrators can use pidstat output to identify problematic processes and take corrective actions such as:
reducing logging verbosity
tuning filesystem mount options
allocating separate storage pools
optimizing application configuration
limiting I/O via cgroups
using write caching optimizations
Pidstat is especially powerful when correlated with other tools such as iostat, sar, and /proc/io-related stats. But when the administrator needs process-level detail, pidstat -d 1 is unmatched.
Because it provides the exact per-process, real-time I/O statistics needed to identify excessive write activity, option B is the correct answer.
Question 182:
A Linux engineer must investigate why a system’s memory consumption slowly increases throughout the day, eventually leading to swap usage. The engineer suspects that a daemon process is leaking memory. Which tool provides detailed, real-time memory usage information per process, including proportional set size and resident memory growth patterns?
A) ps aux
B) pmap -x PID
C) smem
D) top -o %MEM
Answer:
C
Explanation:
The correct answer is smem because this tool provides detailed, accurate memory statistics per process, including proportional set size (PSS), unique set size (USS), and shared set size (RSS). These additional metrics go far beyond what traditional tools display and allow administrators to precisely track memory behavior over time. With smem, an engineer can determine whether a process is leaking memory by observing how its PSS grows steadily as the system runs.
Option A, ps aux, shows basic memory usage including RSS and VSZ, but these values can be misleading when diagnosing leaks. RSS includes shared library usage, so an increase may not reflect true memory growth. VSZ represents virtual memory allocations that do not necessarily consume real physical memory. Therefore, ps cannot reliably confirm the presence of a memory leak.
Option B, pmap -x PID, shows memory mappings for a single process, including how much memory is used by each region such as heap, stack, and shared libraries. While pmap is excellent for static inspection, it does not provide a convenient system-wide view or proportional memory measurements. It is also not designed for tracking memory growth over long periods.
Option D, top -o %MEM, sorts processes by memory use but still shows only RSS. As with ps, top cannot differentiate between shared and private memory or detect subtle leaks. It lacks the advanced metrics necessary to diagnose gradual memory growth patterns.
Smem is unique because it uses PSS as its core measurement. Proportional set size divides shared memory pages evenly among processes that use them, giving a much more accurate picture of actual memory pressure. This is critical because many modern applications rely heavily on shared libraries and shared memory segments. Without PSS, it is difficult to distinguish between legitimate shared memory use and a true memory leak.
Smem also provides:
total system memory breakdown
per-user memory usage
per-process detailed metrics
historical tracking when scripted
visualization in tabular or graphical formats
identification of growing memory regions
When investigating a slow-growing memory leak, smem allows the administrator to periodically sample memory consumption of the suspected daemon. A true leak will show:
steadily increasing USS (unique memory)
increasing PSS
increased memory fragmentation
consistent growth patterns independent of load
Memory leaks are common in:
long-running daemons
web servers
database drivers
caching layers
Python or Java processes with inadequate garbage collection
applications with missing free calls
processes creating unbounded data structures
poorly written backend software
Smem paired with periodic sampling provides evidence that a memory leak exists and pinpoints the responsible process. Once identified, the administrator can apply workarounds such as restarts or patches or escalate the issue to developers.
Because smem is the only tool listed that accurately shows real, proportional memory usage suitable for tracking memory leaks, option C is correct.
Question 183:
A Linux administrator needs to detect when the kernel is performing heavy writeback operations due to dirty pages accumulating in memory. The administrator wants a tool that shows the number of dirty pages, writeback pages, and memory reclamation behavior in detail. Which file should be examined?
A) /proc/meminfo
B) /proc/vmstat
C) /proc/sys/vm/dirty_ratio
D) /proc/sys/kernel/mm/writeback
Answer:
B
Explanation:
The correct answer is /proc/vmstat because this file provides detailed counters related to virtual memory operations, including dirty pages, writeback activity, memory reclaim cycles, page faults, and the kernel’s background flush behavior. These metrics are essential for understanding why the system is experiencing writeback storms or why dirty pages accumulate faster than the kernel can handle them.
Option A, /proc/meminfo, gives a high-level overview of system memory usage but lacks the granular metrics needed to analyze writeback behavior. While meminfo shows total and free memory, available memory, buffers, and cached pages, it does not break down writeback counters or dirty page metrics in the detail required.
Option C, /proc/sys/vm/dirty_ratio, defines a tuning parameter that controls when the kernel begins writing dirty pages to disk, but examining this file only reveals the configured threshold, not the actual state of the system. It cannot display how many dirty pages currently exist or how aggressively the kernel is reclaiming memory.
Option D, /proc/sys/kernel/mm/writeback, is not a standard file on typical Linux systems and is therefore not the correct location for writeback analysis.
The /proc/vmstat file contains a wealth of relevant statistics including:
nr_dirty: number of dirty pages
nr_writeback: pages currently undergoing writeback
nr_writeback_temp: temporary writeback pages
nr_dirtied: number of pages dirtied since boot
nr_clean: number of clean pages
pgsteal: pages reclaimed from various lists
kswapd_steal: pages reclaimed by the kernel swap daemon
pgscan: pages scanned during reclaim attempts
pgfault: page faults
pgmajfault: major page faults
Monitoring these metrics reveals whether the system is under memory pressure or is experiencing excessive flushing behavior. For example, if nr_dirty increases rapidly, it may indicate:
processes writing large amounts of data faster than disks can handle
misconfigured caching behavior
insufficient disk throughput
slow storage devices
incorrectly tuned dirty_ratio or dirty_background_ratio values
Writeback activity is heavily influenced by the kernel’s dirty page thresholds. If dirty pages remain in memory too long, they consume valuable RAM and put pressure on reclaim mechanisms. Conversely, if the kernel flushes too aggressively, it may cause high I/O wait times.
Common causes of writeback storms include:
log-heavy applications generating excessive writes
databases performing checkpoint operations
virtualization hosts writing disk images
poorly configured swap systems
slow storage devices causing writeback backlogs
containers generating frequent disk writes
Administrators may examine /proc/vmstat repeatedly at intervals to detect trends. A growing nr_writeback value indicates the kernel is falling behind on disk flushing. Likewise, high kswapd activity indicates memory reclaim pressure.
By using /proc/vmstat, the administrator gains deep visibility into how the kernel manages dirty memory, delays writes, and synchronizes memory with storage. This information is vital for tuning caching parameters, optimizing filesystem mount options, or upgrading hardware.
Because /proc/vmstat provides the most comprehensive and relevant information for examining dirty memory and writeback operations, option B is correct.
Question 184:
A Linux engineer must troubleshoot a performance issue where the kernel’s automatic NUMA balancing is causing unexpected task migrations between NUMA nodes. The engineer wants to examine NUMA-related process placement and memory locality information. Which command provides per-process NUMA statistics?
A) numactl –hardware
B) numastat -p PID
C) lscpu
D) free -m
Answer:
B
Explanation:
The correct answer is numastat -p PID because this command provides per-process NUMA statistics including memory allocation per NUMA node, local versus remote access patterns, and how the process interacts with the system’s NUMA topology. These metrics are essential when diagnosing issues such as uneven memory distribution, excessive remote memory access, and performance degradation caused by undesirable task migrations between NUMA nodes.
Option A, numactl –hardware, displays NUMA system topology including available nodes, CPU cores per node, and memory distribution, but it does not show per-process NUMA usage or access patterns. It only describes the hardware layout, not process behavior.
Option C, lscpu, provides CPU architecture details, including NUMA nodes and processor counts, but again, it does not provide per-process NUMA memory usage or migration patterns.
Option D, free -m, displays global memory usage but has no NUMA awareness and cannot differentiate memory allocation across nodes.
NUMA, or Non-Uniform Memory Access, means that CPU cores have faster access to memory located on their local memory node compared to remote nodes. Process performance can drop significantly when a process is allocated memory on a remote node or when automatic NUMA balancing migrates tasks unnecessarily.
Numastat -p PID shows:
memory allocated from each NUMA node
the amount of remote versus local memory
memory locality efficiency
NUMA imbalance
migration patterns
These metrics help administrators detect whether the kernel is reallocating pages or moving execution threads between nodes excessively.
NUMA-related performance issues may arise from:
applications with high memory locality requirements
databases or in-memory caches
virtualization hosts with pinned CPUs
misconfigured kernel NUMA balancing
memory fragmentation
cross-node memory contention
Numastat allows the administrator to pinpoint whether the process is utilizing memory optimally or suffering from imbalance. If excessive remote memory is being accessed, performance can plummet due to increased latency.
Administrators often use numastat in combination with numactl to set optimal memory placement policies such as binding a process to specific NUMA nodes or allocating memory from preferred nodes.
Because numastat -p PID is the only option providing per-process NUMA statistics necessary for analyzing task migrations and memory locality, option B is correct.
Question 185:
A Linux administrator must determine why multiple processes are competing heavily for CPU time, causing high load averages. The engineer suspects contention from excessive context switching or CPU scheduling delays. Which tool provides real-time per-process scheduling statistics, including voluntary and involuntary context switches?
A) top -H
B) pidstat -w 1
C) htop
D) ps -eo pid,cswch
Answer:
B
Explanation:
The correct answer is pidstat -w 1 because this command displays real-time per-process scheduling statistics including voluntary and involuntary context switches. Pidstat is part of the sysstat toolkit and offers granular insight into how processes interact with the scheduler, which is essential when diagnosing high load, CPU contention, or system responsiveness problems.
Option A, top -H, shows thread-level CPU usage but does not provide context switch counts. While it can reveal which threads are consuming the most CPU, it cannot explain why processes are switching excessively or waiting for CPU access.
Option C, htop, is a visual enhancement of top and provides additional insights such as CPU frequency, load distribution, and process hierarchies. However, like top, it does not show per-process context switch behavior.
Option D, ps -eo pid,cswch, may show context switches depending on the platform, but it does not provide updated real-time statistics and may not include voluntary versus involuntary switches. It is insufficient for diagnosing ongoing scheduler interactions.
Pidstat -w 1 reveals:
voluntary context switches (processes yielding the CPU willingly)
involuntary context switches (scheduler preemptions)
thread-level scheduling anomalies
processes causing high contention
potential bottlenecks in CPU scheduling
High context switching often indicates:
CPU starvation
excessive thread creation
poorly designed application concurrency
heavy locking or mutex contention
I/O wait cycles causing repeated sleep/wake transitions
misconfigured CPU affinity settings
CPU overload conditions
Pidstat allows administrators to identify which processes are responsible, examine scheduling behavior, and determine whether high load averages are due to actual CPU saturation or scheduler overhead.
Because pidstat -w 1 provides the critical real-time scheduling statistics needed to diagnose CPU contention, option B is correct.
Question 186:
A Linux administrator notices that the system is experiencing high load averages, but CPU utilization remains low. The engineer suspects excessive I/O wait. Which command provides real-time insight into I/O wait percentages across all CPUs, helping determine if disk operations are stalling CPU execution?
A) vmstat 1
B) iostat -c 1
C) mpstat 1
D) free -m
Answer:
C
Explanation:
The correct answer is mpstat 1 because mpstat provides detailed CPU utilization metrics including percentages of CPU time spent waiting on I/O operations. The %iowait field in mpstat output indicates how much time the CPU is idle and waiting for disk operations to complete. This is a critical metric for diagnosing systems experiencing high load averages caused by slow disk I/O rather than intense CPU consumption. The ability to monitor this in real time allows administrators to correlate performance issues with underlying storage problems.
Option A, vmstat 1, provides some system-wide I/O metrics, including information about processes blocked on I/O, but it does not give detailed per-CPU breakdowns. While vmstat indicates system-wide wait times, it cannot show which CPU cores are most affected or provide the finer granularity mpstat offers.
Option B, iostat -c 1, displays CPU utilization statistics, but primarily focuses on overall CPU percentages and does not provide per-CPU analysis. Furthermore, while iostat can display iowait, it is less granular than mpstat and not as directly tied to real-time CPU scheduling insight.
Option D, free -m, displays memory usage and swap statistics but does not include I/O wait or CPU utilization. Free is useful for diagnosing memory pressure but irrelevant for analyzing I/O wait behavior.
High load average alongside low CPU utilization often indicates that processes are stuck in uninterruptible sleep, typically waiting for I/O. When the disk subsystem cannot keep up with the demand of ongoing workloads, processes stall, causing load averages to rise even though CPU cores appear underutilized. This situation frequently occurs on overloaded virtual machines, systems with degraded storage, or servers handling heavy writeback activity.
Mpstat reveals key metrics including:
%usr: user-level CPU usage
%sys: system-level CPU usage
%nice: CPU time spent on niced processes
%idle: idle CPU time
%iowait: time spent waiting for disk operations
%irq: time spent handling hardware interrupts
%soft: time spent handling software interrupts
per-core metrics when using mpstat -P ALL
The most important field for diagnosing I/O wait is %iowait. When this value is high, the CPU is not the bottleneck; rather, processes are waiting on disk I/O to complete.
Common causes of high I/O wait include:
slow or failing disks
overloaded storage arrays
high writeback pressure
numerous tasks competing for disk access
large or fragmented filesystems
misconfigured caching layers
virtualization environments with shared storage contention
Administrators can use mpstat to validate whether the bottleneck is truly storage-related. If %iowait is consistently high, the system is likely stalling on disk operations. If %iowait remains low despite performance issues, the problem lies elsewhere.
Mpstat is particularly important when dealing with:
real-time performance diagnostics
systems with many CPU cores
uneven CPU workloads
isolating which CPUs are affected
distinguishing CPU-bound vs I/O-bound processes
Additionally, mpstat can help correlate I/O wait issues with interrupt and soft interrupt activity, providing deeper insight into performance bottlenecks.
Because mpstat 1 provides real-time per-CPU I/O wait data necessary for diagnosing stalled CPU cycles due to disk performance issues, option C is the correct choice.
Question 187:
A Linux administrator is investigating why certain applications experience intermittent freezes. The engineer suspects excessive kernel-level locking and wishes to analyze kernel lock contention, mutex wait times, and spinlock behavior. Which tool is specifically designed to profile kernel locking events?
A) strace
B) perf lock
C) lsof
D) vmstat
Answer:
B
Explanation:
The correct answer is perf lock because this tool is part of the perf suite and is specifically designed to analyze kernel locking behavior. Perf lock provides insight into kernel-level lock contention, including mutexes, spinlocks, and read-write locks. It reveals how often specific locks are acquired, how long they are held, and where contention occurs within the kernel. These metrics are essential for diagnosing application freezes or sluggish system performance caused by kernel synchronization bottlenecks.
Option A, strace, focuses on system calls rather than kernel locking primitives. Although strace can reveal syscall delays, it cannot identify kernel lock contention or internal synchronization delays.
Option C, lsof, shows open file descriptors but has no awareness of kernel locking or mutex contention.
Option D, vmstat, reports high-level system statistics like process counts, memory activity, and general CPU wait states. While vmstat can indicate system-wide event rates, it cannot display kernel-level lock contention details.
Perf lock exposes critical metrics including:
lock acquisition counts
contention frequency
lock hold duration
top contended locks
kernel stack traces related to locking
per-lock statistics
Lock contention is a significant cause of system performance issues in multi-core systems. When multiple threads or processes attempt to access shared resources, they often must wait for kernel locks. Excessive waiting can cause:
application freezes
slowdowns under load
CPU idle time despite high workload
delays in filesystem operations
performance degradation in network-heavy applications
stalls in high-concurrency environments
Lock contention frequently arises in:
busy filesystems
high I/O workloads
database servers
network packet processing
containerized environments with shared resources
applications designed without concurrency control optimization
Perf lock generates reports that allow administrators to pinpoint which kernel locks are bottlenecks. For example, it may reveal that a filesystem lock is heavily contended during write-heavy operations. Or it may show contention in a network subsystem during peak traffic.
Administrators can then take corrective actions such as:
tuning kernel parameters
optimizing application concurrency
switching to more efficient filesystems
reducing lock contention through scheduling changes
distributing workloads evenly across CPUs
updating drivers with known locking improvements
Perf lock is an advanced diagnostic tool that enables deep performance analysis beyond the capabilities of typical user-space tools.
Because perf lock is the only option designed specifically to analyze kernel-level locking behavior, option B is the correct answer.
Question 188:
A Linux engineer must determine which process is causing a kernel soft lockup that intermittently freezes the system for several seconds. The engineer wants to capture stack traces of tasks stuck in uninterruptible sleep (D-state). Which command provides a snapshot of all running tasks along with their kernel stack traces?
A) ps -aux
B) top -H
C) cat /proc/sysrq-trigger with t
D) journalctl -k
Answer:
C
Explanation:
The correct answer is cat /proc/sysrq-trigger with t because this method triggers the kernel’s SysRq function to dump all task information and associated kernel stack traces. This includes tasks stuck in uninterruptible sleep, which commonly occur during soft lockups or I/O stalls. SysRq-t captures the exact state of the kernel at the moment of the freeze and prints it to the system logs or console, depending on system configuration.
Option A, ps -aux, displays process information but does not include kernel stack traces. It also cannot capture tasks stuck deep inside the kernel, especially during lockups.
Option B, top -H, shows thread-level CPU usage but does not provide kernel-level stack traces. It is useful for diagnosing user-space scheduling issues, but not kernel freezes.
Option D, journalctl -k, shows kernel messages but does not produce stack traces unless they have already occurred. It cannot manually trigger a task dump.
A soft lockup occurs when a CPU is stuck in kernel mode for an extended period, refusing to schedule user-space tasks. This can be caused by:
filesystem driver issues
storage device stalls
kernel bugs
hardware problems
faulty network drivers
infinite loops within kernel code
misbehaving third-party modules
SysRq-t prints:
PID and thread names
process states (S, R, D, I, etc.)
kernel stack traces
function call sequences
locks held by tasks
CPU affinity and scheduling details
Tasks stuck in D-state typically indicate waiting on I/O operations that will not complete, such as:
failing disks
bad controllers
unresponsive NFS mounts
corrupted filesystems
firmware-level timeouts
By analyzing the stack trace, administrators can identify:
which kernel function is causing the stall
which process triggered it
whether the issue is in storage, networking, or another subsystem
whether the system is stuck in a lock
whether a driver is unresponsive
SysRq is a powerful debugging feature for diagnosing low-level kernel problems. SysRq-t is safe to use and does not reboot the system; it only dumps process information. The output is typically sent to the console and kernel logs, allowing for later analysis.
Because triggering SysRq-t via cat /proc/sysrq-trigger is the only way among the options to capture kernel stack traces of tasks causing soft lockups, option C is the correct answer.
Question 189:
A Linux administrator needs to diagnose why a system is frequently entering high load states even though CPU usage remains moderate. The engineer suspects heavy scheduler activity and frequent context switching. Which tool provides real-time per-process context switch counts to identify the responsible processes?
A) lsof
B) pidstat -w 1
C) uptime
D) pstree
Answer:
B
Explanation:
The correct answer is pidstat -w 1 because it provides real-time per-process context switch counts, including both voluntary and involuntary switches. High context switching can lead to elevated load averages even when CPU utilization appears reasonable. Processes constantly switching states consume CPU cycles through scheduler overhead, reducing system efficiency. Pidstat allows administrators to pinpoint which processes are causing the excessive switching.
Option A, lsof, lists open file descriptors but cannot show scheduling or context switching information.
Option C, uptime, shows historical load averages but cannot reveal why the load is high or identify scheduling-related problems.
Option D, pstree, shows process hierarchies but does not include any scheduling information.
Context switching occurs when the CPU switches between threads or processes. While normal in multitasking systems, excessive switching indicates performance issues such as:
too many runnable tasks
threads waiting on shared locks
rapid wake/sleep cycles
processes performing many small operations
I/O-bound workloads repeatedly triggering kernel wakeups
network-heavy tasks relying on frequent interrupts
misconfigured affinity settings causing scheduler imbalance
Pidstat -w 1 displays:
voluntary context switches
involuntary context switches
run queue wait times
process names and PIDs
Voluntary context switches typically indicate that a process is blocking on I/O or locks. Involuntary context switches indicate scheduler-driven preemption, often caused by too many runnable tasks or contention for CPU time.
By monitoring these metrics, administrators can identify patterns such as:
a process waking up thousands of times per second
multi-threaded applications competing for locks
poorly tuned daemons causing scheduler storms
hardware interrupts generating wakeups
processes spawning too many threads
Once identified, the problematic process can be optimized by:
adjusting thread counts
tuning I/O operations
improving concurrency control
using CPU affinity settings
redistributing workloads
Because pidstat -w 1 provides the per-process real-time context switching data necessary for diagnosing scheduler-related load problems, option B is the correct answer.
Question 190:
A Linux engineer must troubleshoot why a critical service is being terminated repeatedly by the systemd OOMPolicy mechanism due to memory overuse. The engineer wants to understand the exact memory usage pattern of the service’s cgroup over time, including real-time memory consumption. Which tool displays live memory usage per cgroup, including total memory, swap, and kernel memory?
A) systemctl status
B) systemd-cgtop
C) free -h
D) ps aux
Answer:
B
Explanation:
The correct answer is systemd-cgtop because this command displays real-time resource usage per cgroup, including memory, CPU, and I/O. When systemd manages services, each service runs inside its own cgroup. If a service exceeds the configured OOMPolicy or MemoryMax settings, systemd may terminate it. To diagnose the problem, administrators must inspect the service’s actual memory usage in real time. Systemd-cgtop provides exactly this visibility.
Option A, systemctl status, provides service logs and metadata but does not display resource usage statistics. It cannot show memory consumption trends or detect which services are growing beyond limits.
Option C, free -h, shows system-wide memory usage but not per-cgroup metrics. It cannot reveal which specific service is consuming excessive memory.
Option D, ps aux, displays per-process memory usage but cannot aggregate memory across the entire service’s cgroup, especially when the service spawns multiple worker processes.
Systemd-cgtop shows key metrics such as:
memory usage per cgroup
swap usage per cgroup
CPU consumption
tasks within each cgroup
real-time changes in memory pressure
This is essential when diagnosing services with:
memory leaks
growing worker threads
caching behaviors exceeding limits
runaway processes
excessive buffer allocation
kernel memory consumption issues
When systemd enforces OOMPolicy, it kills processes or entire services when they violate memory constraints. To find the cause, administrators must monitor the cgroup’s real-time memory usage as it grows. Systemd-cgtop displays this data in a top-like interface, updating continuously.
Memory pressure in cgroups is influenced by:
MemoryMax limits
shared memory segments
forked worker processes
kernel memory usage
slab allocator behavior
I/O buffers
swap usage patterns
By monitoring these with systemd-cgtop, administrators can determine whether:
memory usage grows gradually (indicating a leak)
usage spikes suddenly (indicating bursts)
kernel memory is being consumed excessively
the service’s workers allocate too much memory
This data allows corrective actions such as:
increasing MemoryMax
optimizing application memory usage
adjusting service worker counts
enabling additional memory accounting
investigating kernel-level memory usage
Because systemd-cgtop is the only tool among the options capable of showing real-time memory usage per cgroup, including swap and kernel memory, option B is correct.
Question 191:
A Linux administrator needs to determine why a system using cgroup v2 is experiencing severe memory pressure even though no individual process appears to be using excessive memory. The engineer suspects that a cgroup subtree is consuming memory collectively. Which interface provides detailed memory statistics for a cgroup, including current usage, maximum usage, and pressure stall information?
A) /proc/meminfo
B) systemctl status
C) /sys/fs/cgroup/<group>/memory.stat
D) free -m
Answer:
C
Explanation:
The correct answer is /sys/fs/cgroup/<group>/memory.stat because this file provides detailed, granular memory usage statistics for a specific cgroup when using the cgroup v2 unified hierarchy. Memory.stat reveals how memory is distributed among processes in the cgroup, including current usage, peak usage, anonymous and file-backed memory, kernel memory, and pressure stall information. This makes it the best option for diagnosing memory pressure that arises not from a single process, but from a group of processes collectively using memory.
Option A, /proc/meminfo, provides system-wide memory statistics but cannot break down memory usage by cgroup. When multiple processes inside a subtree consume memory collectively, meminfo does not help identify which group is responsible. It only reflects the overall memory allocation of the entire system.
Option B, systemctl status, provides information about services managed by systemd, but it does not expose cgroup memory metrics. While it displays basic memory usage for systemd services under the MemoryCurrent field, it does not provide fine-grained metrics like those in memory.stat, nor does it show pressure stall information, which is crucial for diagnosing cgroup-level contention.
Option D, free -m, simply displays total memory, used memory, free memory, and swap usage. It offers no insight into memory consumed by individual cgroups or groups of processes. Thus, free cannot diagnose memory pressure originating from within a specific cgroup subtree.
Memory.stat in cgroup v2 provides essential fields such as:
anon: anonymous memory used
file: file-backed memory cached
kernel: memory used by kernel allocations associated with the cgroup
slab: kernel slab usage attributed to the group
shmem: shared memory consumption
workingset_refault
workingset_activate
workingset_restore
pgfault and pgmajfault counts
memory_high and memory_max enforcement metrics
pressure stall statistics
Pressure stall information (PSI) is included in cgroup v2 and provides time-based metrics indicating how often processes in the cgroup experience delays due to memory pressure. For example, memory pressure can cause tasks to stall while waiting for pages to be freed, reclaimed, or flushed. PSI helps quantify these stalls and allows administrators to determine if memory constraints are causing sluggish performance.
Common causes of subtree-level memory overconsumption include:
background daemons launched within the same service
worker-thread-based applications spawning many children
container runtimes grouping multiple containers under a single parent cgroup
memory leaks distributed across multiple small processes rather than a single process
misconfigured resource limits that do not isolate services correctly
log-heavy applications caching excessively in memory
databases that fork auxiliary processes but share memory regions inefficiently
Because memory usage may be distributed across several processes, traditional per-process tools often fail to identify the source of memory pressure. Tools like ps, top, or smem cannot easily detect when many processes belonging to the same cgroup collectively exhaust memory.
Memory.stat shows the cumulative memory usage inside the cgroup, making it possible to identify when a group’s overall consumption exceeds thresholds set by MemoryMax or triggers cgroup-level out-of-memory events.
When debugging cgroup memory pressure, administrators often:
examine memory.current and memory.max values
check for memory.high throttling
evaluate PSI for stalled workloads
compare anon versus file-backed memory patterns
correlate major page faults with memory exhaustion
look for runaway slab usage in kernel memory attributed to the cgroup
identify which cgroup subtree is responsible
Because the memory.stat interface provides full visibility into cgroup memory behavior, including usage and pressure metrics, option C is the correct answer.
Question 192:
A Linux engineer must investigate why a system freezes intermittently under heavy load. The engineer suspects that processes are stuck waiting for CPU resources and wants to analyze the extent of CPU pressure stall information (PSI). Which file provides CPU pressure stall metrics that indicate how often tasks are delayed due to insufficient CPU availability?
A) /proc/loadavg
B) /proc/pressure/cpu
C) /sys/fs/cgroup/cpu.stat
D) /proc/stat
Answer:
B
Explanation:
The correct answer is /proc/pressure/cpu because this file contains CPU pressure stall metrics reported by the kernel’s PSI (Pressure Stall Information) subsystem. PSI provides time-based measurements that indicate how long tasks are stalled due to CPU contention. These metrics are essential for diagnosing system freezes, sluggish performance, and delayed task execution caused by excessive CPU load, high thread concurrency, or scheduler bottlenecks.
Option A, /proc/loadavg, shows load averages but does not indicate how often tasks are stalled or by how much. Load average only reflects runnable processes and those in uninterruptible sleep. It cannot differentiate between CPU shortages, I/O delays, or other forms of resource contention.
Option C, /sys/fs/cgroup/cpu.stat, displays CPU usage metrics for cgroups such as throttling statistics but does not include system-wide PSI metrics. While cpu.stat is useful for cgroup rate limiting and CPU quota enforcement, it does not indicate system-level CPU stalls across all tasks.
Option D, /proc/stat, contains low-level CPU counters such as user, system, idle, and interrupt time but does not provide PSI metrics. It reveals overall usage but not the duration or frequency of scheduler stalls.
CPU pressure stall information from /proc/pressure/cpu includes:
some: total time in which at least one task was stalled
full: total time in which all tasks were stalled
average stall times over 10 seconds, 60 seconds, and 300 seconds
These metrics provide insight into periods when the system struggled to allocate CPU time to tasks.
Examples of causes of CPU pressure include:
too many runnable tasks for the available CPU cores
thread pools exceeding system capacity
CPU-intensive workloads such as compilers, encryption tasks, or scientific workloads
scheduling imbalance across CPU cores
misconfigured CPU affinity leading to overloaded nodes
background daemons consuming CPU unexpectedly
virtualization hosts running too many virtual machines
rapid thread creation and destruction causing scheduler overhead
When CPU pressure is high, applications experience:
slow response times
intermittent freezes
delayed task execution
increased load averages
high involuntary context switching
reduced system throughput
PSI metrics are extremely valuable because they quantify not just CPU usage, but the performance impact of contention. For example, PSI full metrics indicate that all tasks in the system were waiting on CPU at the same time—often a sign of severe performance bottlenecks.
Administrators use PSI to:
pinpoint performance degradation
determine whether to increase CPU resources
balance workloads more evenly
tune thread counts in applications
adjust scheduling priorities
identify runaway processes
Additionally, PSI is used by advanced workload management systems to implement adaptive throttling or queue management. Because PSI CPU metrics directly measure system-wide CPU stalls, they are ideal for diagnosing intermittent freezes.
Because /proc/pressure/cpu is the only option that provides CPU stall metrics essential for diagnosing CPU contention and task delay issues, option B is correct.
Question 193:
A Linux administrator needs to analyze why a containerized service is using excessive I/O resources. The engineer wants to view real-time I/O usage grouped by cgroups rather than by individual processes. Which tool provides a top-like interface that displays I/O, CPU, and memory consumption per cgroup?
A) iotop
B) systemd-cgtop
C) pidstat -d
D) du -sh
Answer:
B
Explanation:
The correct answer is systemd-cgtop because this tool displays aggregated resource usage per cgroup in real time, including CPU time, memory usage, and I/O consumption. When dealing with containerized workloads or systemd-managed services, resources are often grouped into cgroups rather than isolated per process. Using systemd-cgtop, administrators can identify which service or container is responsible for high I/O usage without needing to inspect individual processes.
Option A, iotop, provides real-time I/O statistics per process but does not group results by cgroup. In containerized environments, where multiple processes share a cgroup, iotop may misrepresent which container is using resources.
Option C, pidstat -d, offers per-process I/O metrics but again does not display aggregated cgroup statistics. While pidstat is extremely useful for traditional Linux systems, it falls short when analyzing container-level workloads.
Option D, du -sh, measures disk usage on the filesystem but does not report real-time I/O metrics or identify resource consumption patterns.
Systemd-cgtop is especially critical in environments using technologies such as:
Docker
Podman
Kubernetes
LXC/LXD
systemd-nspawn
flatpak
All of these rely heavily on cgroup resource isolation. Systemd-cgtop enables administrators to determine which container or systemd-managed service is consuming:
CPU time
memory
block I/O
number of tasks
swap usage
The tool updates dynamically, similar to top, allowing administrators to monitor changing resource trends. It is particularly helpful for diagnosing:
containers hogging I/O resources
runaway services consuming too much memory
imbalanced CPU usage across different services
memory leaks inside container groups
containers generating excessive disk writes
I/O overload in a cgroup can result from issues such as:
excessive logging inside a container
misconfigured database services
applications writing temporary files frequently
runaway caching mechanisms
large or repeated file extractions
systemd-journald writing too much container output
Since systemd-cgtop presents resource usage in aggregate form rather than per process, it provides a clearer high-level understanding of each container’s impact on overall system resources. This is crucial for system tuning and for determining whether limits such as IOQuota, MemoryMax, or CPUQuota need adjustment.
Because systemd-cgtop is the only tool among the options that shows real-time aggregated resource usage per cgroup, option B is correct.
Question 194:
A Linux engineer needs to diagnose why multiple processes are becoming unresponsive during intensive disk operations. The engineer suspects that the system is running out of available block I/O bandwidth and wants to examine I/O-related pressure stall information (PSI). Which file contains PSI metrics for I/O wait conditions?
A) /proc/pressure/memory
B) /proc/pressure/io
C) /proc/sys/vm/swappiness
D) /sys/block/<device>/stat
Answer:
B
Explanation:
The correct answer is /proc/pressure/io because this file contains I/O-related PSI metrics, which reveal how frequently and for how long tasks are stalled waiting for I/O operations. PSI I/O metrics show the degree of contention in the I/O subsystem. This is critical for diagnosing unresponsive applications or high load averages caused by I/O bottlenecks rather than CPU or memory issues.
Option A, /proc/pressure/memory, shows memory pressure stall information but does not reflect I/O-related delays. Memory PSI metrics include stall percentages caused by memory reclaim and page faults, not I/O behavior.
Option C, /proc/sys/vm/swappiness, is a kernel tuning parameter that controls swap behavior. It does not provide real-time or historical I/O stall metrics.
Option D, /sys/block/<device>/stat, displays block device statistics like read/write requests and time spent on I/O operations but does not provide PSI stall percentages. While it can show raw throughput and wait times, it does not capture the impact on tasks or system responsiveness.
The I/O PSI file provides:
some metrics: time when at least one task was stalled
full metrics: time when all tasks were stalled
stall time over 10s, 60s, and 300s windows
a measure of how much I/O contention delays computation
High I/O stalls often indicate that processes spend significant time waiting for disk access, leading to:
slow application responses
system freezes or pauses
high load averages
reduced throughput
increased scheduling delays
runaway writeback activity
The causes of I/O stalls may include:
slow disks
failing or degraded storage
insufficient IOPS in virtualized environments
excessive writeback pressure
multiple containers competing for I/O
large file operations
database flushes
backup jobs running during production hours
PSI helps quantify these stalls in a way traditional I/O monitoring tools cannot. While tools like iostat show device performance, they cannot measure the impact on task scheduling or responsiveness.
Administrators use I/O PSI metrics to decide:
whether to tune dirty_ratio parameters
whether to allocate faster storage
whether workload scheduling must change
whether cgroup-based I/O limits are needed
whether certain containers need dedicated I/O bandwidth
Because /proc/pressure/io is the only interface providing PSI metrics for I/O wait conditions, option B is correct.
Question 195:
A Linux administrator needs to determine why a system service is repeatedly hitting the cgroup memory.high threshold, causing throttling. The engineer wants to view how much time tasks spend stalled due to memory pressure inside a specific cgroup. Which file provides pressure stall information for memory within that cgroup?
A) /sys/fs/cgroup/<group>/memory.pressure
B) /proc/pressure/memory
C) /sys/fs/cgroup/<group>/memory.stat
D) /sys/fs/cgroup/<group>/memory.events
Answer:
A
Explanation:
The correct answer is /sys/fs/cgroup/<group>/memory.pressure because this file contains cgroup-specific memory PSI metrics. While /proc/pressure/memory provides system-wide PSI details, cgroup-level PSI is essential for diagnosing resource contention inside a service or container. The memory.pressure file shows how often tasks are stalled due to memory pressure in that cgroup, including both some and full stall metrics over multiple time windows.
Option B, /proc/pressure/memory, displays global memory PSI, but cannot isolate which cgroup is experiencing memory stalls. When multiple containers or services run on the same system, global PSI cannot reveal which group is suffering the most.
Option C, memory.stat, displays memory usage statistics but does not include time-based stall information. Although memory.stat shows critical fields such as anon, file, slab, and active pages, it does not measure how memory pressure impacts performance.
Option D, memory.events, shows cgroup events such as high memory alerts, OOM kills, and threshold crossings, but not PSI stall metrics.
Memory.pressure provides insight into:
how often tasks in the cgroup stall
how frequently memory shortages delay execution
how much performance degradation is caused by memory reclaim
whether throttling from memory.high is contributing to slow performance
Memory pressure stalls often occur due to:
aggressive kernel memory reclaim
cgroup memory.high enforcement
insufficient memory allotment for the service
memory leaks
filesystem caching competing for space
high anonymous memory growth
insufficient swap or swap thrashing
large heap or buffer allocations
The PSI metrics in memory.pressure quantify these delays, helping administrators:
determine whether to increase MemoryMax or MemoryHigh
optimize memory usage in applications
rebalance workloads between cgroups
adjust caching behavior or swappiness
diagnose why services appear slowed or unresponsive
Because memory.pressure provides the most accurate reflection of memory stall conditions inside a cgroup, option A is the correct answer.
Question 196:
A Linux administrator is troubleshooting a system where memory usage spikes unpredictably during peak application loads. The engineer suspects that memory reclaim activity is causing latency. Which file provides detailed information about reclaim metrics such as pages scanned, pages reclaimed, and kswapd activity?
A) /proc/meminfo
B) /proc/vmstat
C) /proc/zoneinfo
D) /sys/fs/cgroup/memory.stat
Answer:
B
Explanation:
The correct answer is /proc/vmstat because this file contains detailed kernel-level virtual memory statistics, including page scanning activity, reclaim counters, kswapd behavior, and metrics describing how aggressively the kernel is attempting to free memory. These values are crucial when diagnosing systems experiencing memory pressure, stalls during reclaim, or sudden latency spikes caused by excessive page scanning. The vmstat interface provides real-time insight into how memory is being managed, which processes are triggering page faults, and how the kernel attempts to maintain memory availability when workloads become unpredictable.
Option A, /proc/meminfo, displays general memory statistics including buffers, cached pages, free memory, and swap usage. While these metrics are useful for obtaining a broad overview of system memory consumption, they do not provide insight into the memory reclaim cycle or the behavior of kswapd. Meminfo cannot reveal how many pages the kernel is scanning, how many are being reclaimed, or how aggressively memory pressure is affecting system performance.
Option C, /proc/zoneinfo, contains lower-level NUMA and zone-specific information such as free pages per zone, watermark thresholds, and zone fragmentation levels. While zoneinfo is useful for advanced NUMA-level memory analysis, it is not the primary interface for understanding reclaim activity. It lacks aggregated reclaim counters and is more suitable for debugging physical memory fragmentation, not general performance issues.
Option D, /sys/fs/cgroup/memory.stat, contains memory usage metrics for a specific cgroup when using cgroup v1 or v2. Although it helps diagnose memory constraints in container environments or systemd-managed services, it cannot show global system reclaim activity that affects all cgroups. Memory.stat does not contain page scanning or reclaim information for the entire system, making it insufficient when memory spikes are system-wide.
The vmstat file includes essential metrics such as:
pgscan: pages scanned during active and inactive list scanning
pgsteal: pages taken from the lists to satisfy allocations
kswapd_steal: steals performed by the kswapd thread
pgfault: total page faults
pgmajfault: major faults requiring disk I/O
nr_dirty: number of dirty pages
nr_writeback: pages under writeback
nr_isolated_anon and nr_isolated_file: isolated pages during reclaim
When memory usage spikes, processes often trigger large numbers of page faults, causing the kernel’s reclaim mechanisms to initiate background activity. Kswapd attempts to maintain free pages by scanning page lists and reclaiming unused memory. During peak loads, page scanning can become aggressive, consuming CPU time and causing latency. Administrators must understand reclaim behavior to determine whether the system is under normal pressure or experiencing abnormal memory stress.
Common causes of excessive memory reclaim include:
applications allocating memory faster than release
processes leaking memory slowly over time
insufficient RAM for peak workloads
heavy I/O activity increasing dirty pages
large caching operations
containers exceeding memory quotas
database workloads increasing resident memory usage
Excessive reclaim can lead to:
sluggish performance
high CPU consumption
increased I/O waits
delayed service responses
applications entering memory contention
swap thrashing if swap is enabled
Analyzing vmstat helps administrators decide whether to:
increase system RAM
adjust swappiness or dirty page settings
tune memory reclaim thresholds
optimize application memory usage
redistribute container memory limits
investigate memory leaks
add NUMA pinning for better memory locality
Because /proc/vmstat is the only file among the options providing full, system-wide reclaim metrics, it is the correct answer.
Question 197:
A Linux administrator needs to diagnose why a real-time workload suffers from increased jitter and unpredictable execution delays. The engineer suspects CPU frequency scaling is fluctuating based on load. Which command displays real-time frequency values for each CPU core to verify frequency scaling behavior?
A) lspci
B) cpupower frequency-info
C) uptime
D) ps -eo pid,psr,cmd
Answer:
B
Explanation:
The correct answer is cpupower frequency-info because this command reveals detailed information about CPU frequency scaling, governor settings, and current operating frequencies for each CPU core. Real-time workloads, such as industrial control systems, audio processing, or low-latency trading applications, depend on predictable timing. Fluctuations in CPU frequency caused by power-saving governors or thermal throttling can introduce jitter and unpredictable delays. Cpupower is specifically designed to analyze and manage CPU frequency scaling behavior.
Option A, lspci, lists PCI devices and has no relationship to CPU frequency behavior or power management. It is irrelevant for diagnosing real-time performance instability.
Option C, uptime, shows load averages and system uptime. It cannot provide per-core frequency information or any metrics about dynamic frequency changes.
Option D, ps -eo pid,psr,cmd, displays the processor core on which each process is executing (psr) but cannot show CPU frequency or scaling policies. It helps diagnose scheduling but not frequency jitter.
CPU frequency scaling is controlled by the CPUFreq subsystem, which dynamically adjusts processor speed based on workload, power profiles, and thermal considerations. Frequency changes can introduce latency due to ramp-up delays. Real-time workloads require stable frequencies to avoid jitter.
Cpupower frequency-info displays:
current frequency
minimum and maximum available frequencies
driver and governor in use
turbo or boost availability
transition latency
energy performance bias settings
hardware frequency limits
These metrics allow administrators to observe:
whether frequency scaling is active
how often the CPU is changing frequency
whether turbo mode is causing unpredictable spikes
whether power-saving governors reduce frequencies during low load
whether thermal conditions force throttling
Common causes of jitter include:
powersave or ondemand governor changes
thermal throttling reducing clock speeds
BIOS or firmware settings altering frequency behavior
container CPU quotas affecting scaling decisions
real-time processes being scheduled on cores with shared thermal boundaries
workloads migrating between high- and low-frequency cores
Administrators often adjust CPU governors to improve real-time behavior:
using the performance governor to lock frequencies
disabling turbo on some CPUs to reduce jitter
isolating cores for real-time tasks
pinning workloads to specific CPUs
adjusting thermal limits where appropriate
Cpupower frequency-info provides the visibility needed to verify whether such adjustments are effective. It is also useful for diagnosing unexpected performance issues caused by scaling such as:
delayed response times
inefficient CPU power management
frequency oscillations due to rapid workload changes
latency spikes in multithreaded applications
Because cpupower frequency-info is specifically designed to display detailed CPU frequency scaling information necessary for diagnosing jitter, option B is correct.
Question 198:
A Linux administrator needs to determine why a filesystem-backed application is experiencing delays when reading metadata-heavy directories. The engineer suspects excessive directory lookups and readdir operations. Which tool traces file access operations, directory traversals, and metadata calls in real time to help identify bottlenecks?
A) lsof
B) strace -e trace=file
C) vmstat
D) free -h
Answer:
B
Explanation:
The correct answer is strace -e trace=file because this command traces file-related system calls, including open, stat, readdir, access, and metadata operations. When an application experiences delays navigating large directory structures, identifying the underlying filesystem operations is essential. Strace reveals the sequence of system calls the application performs, how long each call takes, and where delays accumulate.
Option A, lsof, lists open files and processes that hold them. It cannot trace file operations or display metadata-related activity. It provides static snapshots rather than dynamic tracing.
Option C, vmstat, provides general performance statistics including memory and I/O, but cannot trace directory-level operations or system calls.
Option D, free -h, provides memory usage statistics only and has no relevance to filesystem metadata delays.
Metadata-heavy workloads occur when applications frequently:
open many small files
traverse directories with thousands of entries
check permissions repeatedly
access symbolic links
perform many stat or access calls
use inefficient file lookup patterns
Strace can identify issues such as:
repeated open or stat calls in loops
inefficient directory scanning patterns
poorly optimized file access logic
applications failing to use caching
unexpected recursive traversal
excessive permission checks
symlink chains causing overhead
Strace output shows detailed timing, helping administrators detect where slowdown occurs. When reading metadata-heavy directories, bottlenecks may arise from:
inefficient filesystem design
insufficient directory indexing
multiple applications competing for metadata locks
slow storage underlying the filesystem
heavy kernel-level locking
poorly distributed directory entries
inode cache misses
Strace is also useful for analyzing complex applications such as web servers, compilers, search engines, or backup tools. These often perform repetitive file operations that become bottlenecks under scale.
Additionally, strace helps identify application bugs such as:
loops causing repeated path checks
failure to close file descriptors
redundant existence checks
broken file caching logic
Because strace -e trace=file monitors real-time file access patterns and reveals metadata bottlenecks, option B is the correct answer.
Question 199:
A Linux engineer needs to determine why a high-performance network application is experiencing increased packet-processing latency. The engineer suspects softirq overload. Which command shows real-time softirq activity per CPU to verify whether network-related softirqs are overwhelming certain cores?
A) top
B) mpstat -I SCPU
C) iostat
D) netstat -i
Answer:
B
Explanation:
The correct answer is mpstat -I SCPU because this command displays softirq activity per CPU, allowing administrators to determine whether network softirqs are dominating CPU time. Softirqs handle many network operations such as packet processing, interrupt handling, and TCP stack operations. When network traffic is high, softirq workloads can overwhelm certain CPU cores, causing latency spikes and packet drops.
Option A, top, shows process-level CPU usage but cannot display softirq activity. Softirqs run in kernel context and do not appear as user processes.
Option C, iostat, covers block device I/O and has no relation to softirq processing.
Option D, netstat -i, shows network interface statistics but cannot display kernel interrupt activity or show which CPUs are overloaded.
Softirq overload occurs when:
network traffic is too high for available CPU resources
interrupt-handling is unbalanced across cores
network drivers use busy polling
the system receives many small packets
network stack processing becomes CPU-bound
multicore balancing is not optimized
Mpstat -I SCPU displays metrics such as:
packet-processing softirqs
timer-related softirqs
tasklet activity
kernel network processing distribution
softirq load per core
Softirq saturation often results in:
increased packet latency
reduced throughput
packet drops
CPU starvation for normal tasks
imbalanced interrupt handling
Administrators can use mpstat to:
verify which cores are overloaded
enable irqbalance
manually reassign interrupts
pin network queues to different CPUs
optimize network driver parameters
enable multi-queue network interfaces
Because mpstat -I SCPU uniquely reveals softirq activity per CPU, option B is the correct answer.
Question 200:
A Linux administrator is troubleshooting a system where multiple services start slowly during boot. The engineer suspects that some systemd units are waiting excessively for dependencies or timeouts. Which command provides a ranked list showing how long each systemd unit took to start?
A) systemctl status
B) systemd-analyze blame
C) journalctl -b
D) ps -aux
Answer:
B
Explanation:
The correct answer is systemd-analyze blame because this command provides a list of systemd units sorted by the amount of time they took to initialize during boot. This enables administrators to quickly identify slow-starting services, misconfigured dependencies, or units that cause cascading delays. Systemd-analyze blame is especially useful when troubleshooting systems experiencing long boot times or services that appear to hang during startup.
Option A, systemctl status, displays the status and logs for a specific unit but does not provide comparative startup timing across all units.
Option C, journalctl -b, shows startup logs in chronological order but does not summarize timing or rank services by startup duration.
Option D, ps -aux, shows running processes but provides no startup timing information.
Slow systemd startup can be caused by:
network-online.target delays
mount units waiting for remote filesystems
hardware initialization delays
DNS resolution failures
poorly written service scripts
long-running ExecStart commands
dependencies waiting for timeouts
services waiting for network routes or devices
Systemd-analyze blame reveals issues such as:
which services consistently cause delays
long waits on disk or network services
startup processes exceeding expected durations
misconfigured dependencies causing chain stalls
This information allows administrators to:
optimize boot performance
remove unnecessary dependencies
resolve slow network initialization
fix failing mount points
adjust timeouts in service files
change ordering with After= or Requires=
convert slow scripts into oneshot or simple services
Because systemd-analyze blame uniquely provides a sorted list of startup durations, it is the correct answer.
