Surface OS page-cache stats (Buffers/Cached) in /status?full=true

[gaurav]

Note

Superseded by #287. Kept open pending a decision on that issue — see the update below for why the approach proposed here is not achievable from /status.

Update (2026-07-24): why this cannot be served from /status

Investigated while building #231 (/status metrics). The premise of this issue is right — free_physical_memory_bytes is misleading, and #231 removed that field for exactly the reason described below. But the proposed mechanism turns out not to be achievable, for two independent reasons:

1. Solr's metrics API cannot report Buffers/Cached. Verified empirically against Solr 9.10 (/admin/metrics, all groups): the JVM's OperatingSystemMXBean exposes only freePhysicalMemorySize (= Linux MemFree, which excludes page cache) and totalPhysicalMemorySize. There is no Buffers/Cached/MemAvailable anywhere in Solr's metrics output, so there is nothing for NameRes to fetch.

2. The suggested implementation point cannot read the Solr host. The plan above ("read inside the Solr container ... implementation belongs in api/solr.py (SolrClient.fetch_status)") conflates two different machines: that code runs in the NameRes API process, which reaches Solr only over HTTP — it cannot read the Solr container's /proc/meminfo. Reading its own /proc/meminfo reports the API node, which equals the Solr node only when the two are co-located. This was prototyped in #231 as an api_node_memory block and then removed, because a figure labelled as Solr's page cache that silently isn't is worse than no figure at all. (Separately, api/solr.py exists only on the #253 branch, which is not being merged to main.)

So the "Alternative" already noted in this issue — a node-level exporter — is in fact the only workable path. That is now tracked in #287.

What /status?full=true does provide as of #231

Enough to confirm the #265 heap reduction landed and to size the pod, though not page-cache occupancy:

• solr_metrics.jvm — heap_used_mb / heap_max_mb / heap_used_pct, gc_count / gc_time_ms
• solr_metrics.host — total_physical_mem_mb, available_processors, system_load_average, system_cpu_load

free_physical_mem_mb was deliberately not carried over, for the reason this issue opens with. Solr's GC logs now also go to stdout, so they are visible in Grafana next to whatever a node exporter would publish.

---

Summary

solr.os.free_physical_memory_bytes alone is misleading on Linux — what matters for Solr/Lucene query performance is Buffers + Cached from /proc/meminfo. The currently exposed free_physical_memory_bytes reports as 632 KB on the production node, which is alarming-looking but technically expected on Linux even when there is plenty of cache available.

This makes it hard to tell at a glance whether the heap-vs-cache fix proposed in #265 has actually freed enough memory for the OS page cache to hold a useful portion of the 142 GB index.

Suggested action

Add a solr.os.linux_meminfo block to the /status?full=true payload populated from /proc/meminfo (read inside the Solr container — readable by any user). Surface at least:

• MemAvailable_bytes
• Cached_bytes
• Buffers_bytes

Implementation belongs in api/solr.py (SolrClient.fetch_status) since this is part of the Solr-host story rather than the API process. The existing parse_os helper can be extended.

Alternative: scrape from a node-exporter sidecar and link the dashboard from /status. Either is fine; the goal is one place to look during incident triage.

Why this matters

After deploying the heap reduction in #265, we want a single check that confirms the cache is actually being populated, not just that the heap was reduced. Right now we would have to SSH into the Solr container to read /proc/meminfo directly.