Efficiency

Efficiency pillar in the LinuxGuard console — rightsizing, storage, network IO, JVM, waste assessment, labor savings, and reports.

The Efficiency pillar surfaces resource utilization and cost-impact analysis across the fleet. Where Identity Intelligence and Zero Trust answer security questions, Efficiency answers operational ones: which servers are over-provisioned, which storage volumes are wasting space, which JVM applications are mis-tuned, and what the cumulative cost of those conditions looks like in dollars and operator hours. It is used by infrastructure leads, FinOps practitioners, and platform teams running capacity reviews.

Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.

Efficiency findings are advisory — LinuxGuard does not act on them automatically. The pillar surfaces evidence and recommendations; the decision to downsize an instance, archive a volume, or retune a JVM remains with the operator. This separation is deliberate: cost-driven changes have cross-team dependencies (capacity planning, application owner sign-off, change windows) that automated remediation cannot navigate safely.

Rightsizing

Rightsizing analyzes CPU and memory utilization per server over a configurable time window and classifies each server as a downsize candidate, maintain candidate, or upsize candidate. The classification draws on percentile-based utilization metrics — typical inputs include p50, p95, and p99 of CPU and memory over the window — rather than peak values alone, so a single transient spike does not move a server out of the downsize category.

A downsize candidate is a server whose p95 utilization sits consistently below the configured threshold (commonly 30-40% for CPU, 50-60% for memory). An upsize candidate is one whose p95 approaches the configured ceiling (commonly 75-85%) over multiple periods, indicating that the workload is bumping into the current instance size.

The rightsizing table includes a per-server recommended instance size where the tenant has provided an instance-size catalog (e.g., AWS / GCP / Azure SKU list). When no catalog is configured, recommendations are expressed as a relative target — "reduce vCPU by 50%" or "increase memory by 100%" — rather than as a specific SKU name.

Storage

Storage Recommendations identifies mount points with low utilization, stale data, or growth trajectories worth highlighting. Each entry includes a growth forecast computed via linear regression over the observed history, and a projected time-to-capacity estimate. Operators use this to decide whether to reclaim, expand, or watch a volume.

Stale data detection flags directories whose access times indicate no recent reads — typical findings are archived log directories, old backup staging paths, and application caches that were never wired up to a retention policy. The findings are advisory; LinuxGuard does not delete data.

For environments where filesystem access time tracking is disabled (noatime or relatime mount options), stale-data detection falls back to modification time and file-creation cadence, with a lower confidence indicator on the resulting findings.

Network IO

Network IO analysis surfaces bandwidth utilization, connection patterns, and per-interface throughput across the fleet. The view highlights servers whose interface utilization sits in an unusual band — chronically near saturation (capacity-constrained), chronically near zero (likely candidate for instance class downsize), or showing patterns that suggest a config issue (asymmetric duplex, NIC-bond imbalance, link flapping).

Network IO findings often correlate with rightsizing — a server with low CPU but saturated network throughput is not a downsize candidate at the instance level; it may instead be a candidate for an instance class with better network performance at similar compute cost.

JVM applications

JVM application optimization surfaces Java processes with heap sizing or garbage collection configuration issues. The agent collects JVM process metadata — heap configuration, garbage collector choice, observed GC pause distribution, allocation rate, and heap utilization — and flags processes where the configuration is contributing to memory waste, GC churn, or instability.

Typical findings:

Pattern	Likely cause
Heap >> working set	Over-provisioned -Xmx; reclaim memory
Heap ≈ working set, frequent old-gen GC	Under-provisioned heap; expand
High allocation rate, short pauses	Allocation tuning opportunity (object pooling, escape analysis)
Long pauses, low allocation rate	GC algorithm mismatch (CMS / G1 / ZGC / Shenandoah selection)

These findings are surfaced for review by application owners. LinuxGuard does not modify JVM flags directly.

Waste assessment

Waste Assessment aggregates rightsizing, storage, and JVM findings into a tenant-wide view with estimated monthly and annual cost impact. The cost model requires a cost catalog — either configured by the operator (per-vCPU-hour, per-GB-month) or imported from a cloud provider billing integration where available. Without a cost catalog, waste assessment shows units-of-waste (vCPU-hours, GB-months) rather than dollar figures.

The view groups waste by category (CPU, memory, storage, JVM) and by environment / tag, allowing finance teams to attribute cost-impact recommendations to the team or product that owns each environment.

Labor savings

Labor Savings estimates the operator time recovered by acting on Efficiency findings. The estimate is based on time-per-action baselines configured per tenant (e.g., "a single rightsizing change takes 30 minutes including change management") multiplied by the number of pending findings.

The metric is intentionally directional rather than precise. It exists to give operators and managers a sense of the recurring overhead a fleet's drift surfaces represent, not to commit to a specific hours-saved number. Tenants typically calibrate the baselines once and then track the trend over quarters.

Efficiency reports

Efficiency Reports produces exportable summaries of rightsizing, storage, JVM, waste assessment, and labor savings findings for a configurable period. Exports include a per-server breakdown, a per-environment summary, and the cost-impact aggregation if a cost catalog is configured. Output formats: CSV, JSON, and PDF.

Reports are used in capacity-planning reviews, quarterly business reviews, and FinOps presentations. They are also a natural feed into chargeback / showback workflows where infrastructure cost is attributed to the team owning each environment.

Data sources

Efficiency draws on agent-collected resource telemetry — process listings, CPU and memory utilization sampled at the agent's metric interval, mount-point utilization, network interface statistics, and JVM process metadata. No external sources feed Efficiency by default. Cost catalogs (per-SKU pricing) and time-per-action baselines (labor savings) are operator-supplied through console settings.

Data	Agent surface
CPU / memory utilization	/proc/stat, /proc/meminfo, per-process /proc/[pid]/stat
Mount utilization	/proc/mounts, statfs() per mount
Network IO	/proc/net/dev, per-interface ethtool statistics where available
JVM metadata	Per-process command-line, JMX where exposed, GC log scraping where present
Storage stale data	Atime / mtime / ctime across watched filesystems

Module gating

Efficiency is part of the Infrastructure module. Subscription gating documented in console — the Efficiency Reports export, cost catalog configuration, and labor savings estimation are typically gated on higher tiers, while the underlying rightsizing and storage findings are available across tiers.

JVM application analysis requires the agent to be able to inspect Java processes, which is conditional on process visibility and may be subject to per-tier limits on the number of JVMs analyzed.

Cross-references

• Related CLI commands: probe (verifies agent's resource-collection probes are healthy)

• Related Concepts: Infrastructure (per-server Efficiency tab on server detail), Baselines (config-drift findings can correlate with efficiency drift)

• Related How-to: Log Management (log volume contributes to storage findings)

---

Related: Console | Infrastructure | Baselines | Glossary