Context
A server can have moderate average utilization while users experience stalls. Pressure Stall Information, usually called PSI, reports time when tasks lose progress because CPU, memory or I/O resources are contended. It complements utilization by asking whether work is being delayed, rather than simply how busy a resource appears.
Start with a Linux kernel that exposes PSI, the affected host or workload scope and a timestamped application symptom. Read the deployed kernel documentation because resource-specific behavior and available fields can vary. The initial checks below are read-only; they do not require changing resource controls or terminating tasks.
Read the signal in context
- Inspect
/proc/pressure/cpu,/proc/pressure/memoryand/proc/pressure/io. If the files are absent, determine whether PSI is supported and enabled rather than interpreting absence as zero contention. Save samples with timestamps alongside the application latency interval. Host-level pressure can be produced by a workload other than the one users reported. - Interpret
someandfullusing the kernel documentation for that resource. Broadly, the signals distinguish partial task stalls from periods with more complete loss of productive progress in the measured scope. Do not treat every resource's fields as interchangeable. Read the displayed averaging windows and cumulativetotalvalues as different representations of time-related pressure. - Compare changes over an interval, especially cumulative totals, with request latency, throughput and relevant workload activity. A historical total on an otherwise quiet machine does not establish a current incident. Short bursts can also disappear within a longer average, so align collection windows with the symptom rather than relying on one dashboard value.
- Attribute the pressure using resource-specific evidence. CPU run queues, memory reclaim activity and device latency answer different follow-up questions. If the workload has a supported separate scope, compare its pressure with the host while preserving the meaning of both. Avoid assuming that the largest process is automatically responsible for the observed stalls.
An illustrative scheduled contention
In an illustrative application host, a nightly compression job overlaps with a customer import. CPU PSI and import duration rise together, while memory and I/O pressure stay close to their ordinary levels. That pattern supports investigating scheduling and CPU contention first. It does not establish a universal threshold for every application or justify a memory upgrade.
| Pressure pattern | Correlating evidence | Useful next question |
|---|---|---|
| CPU stalls during a batch | Runnable tasks and job timing | Can competing work be scheduled differently? |
| Memory stalls with reclaim | Working set and reclaim activity | Is memory demand sustainable? |
| I/O stalls with device delay | Filesystem mapping and latency | Which storage path is waiting? |
| Host pressure without service impact | Workload-specific latency | Is the alert scoped usefully? |
Correct and verify contention
Select one demonstrated cause and test a focused correction, such as shifting a batch window or reducing unnecessary concurrent work. PSI is a measurement interface, not a diagnosis or a capacity prescription by itself. Preserve the original workload and collection method for comparison.
Verify that service latency and throughput improve under equivalent demand, and check whether pressure moved to another resource. A quiet pressure graph during a reduced workload is not enough. Review errors and completion counts so dropped work is not mistaken for improved responsiveness.
Create actionable monitoring
Choose alert conditions from measured workload impact and the team's response capacity. Document signal scope, sampling windows, ownership and the first attribution checks. Keep the business-service objective separate from any example graph threshold. Clouvenix server performance can help connect PSI evidence to an operational response.