Addressing Memory Constraints: Visualize Over-Requests, Then Right-Size (LSF FP16 Memory Report × IBM Bob, with Quarkus)
Figure 1. Period collect → Investigate / All — Requested vs Peak, Accuracy, and average memory comparison at a glance.
Rising memory prices and hard-to-procure servers are a shared constraint across many sites. Budgets and rack space do not grow overnight. So the practical question becomes: how do we keep job throughput and wait times under control with the cluster we already have?
That question led us to the Memory Report in IBM Spectrum LSF Fix Pack 16 (bacct -mreport). The flow we want customers to see is simple:
Deal with memory pressure → visualize over-requests (“too much reserved”) → investigate → right-size.
Memory Report compares what each job requested with the Peak it actually used, and summarizes over-reservation (Over), under-reservation (Under), and waste. On a slide, that is easy to understand. In practice, though, numbers alone rarely feel real. Neither operators nor submitters easily connect the idea to “what happened in my jobs.” On top of that, the standard Web UIs—RTM and Application Center—do not present a Memory Report–style accuracy view. Showing raw CLI output in a customer meeting is also a weak experience.
So we asked IBM Bob to help build a demo with one goal: make the story easy to grasp.
- Submit intentional sample jobs (over-request, under-request, and cases where runtime changes with the memory budget).
- Visualize the results in a Web UI.
IBM Bob built this Quarkus UI and the surrounding demo environment (Java / Quarkus app, allowlisted collect wiring, sample-job side). At runtime, collect is still a straight path—Browser → Quarkus → SSH → allowlisted LSF commands only—so the cluster is not opened to free-form agent actions.
This is not a replacement for the product Memory Report. It is demo material to add tangibility in customer conversations: take the Requested-vs-Peak gap that is hard to see in standard screens, reproduce it with sample jobs, and show it live.
Why Memory Report now
When you cannot easily buy more servers, how you use the cluster you already own matters. Request too much memory and slots stay blocked; wait times grow. Request too little and you risk host pressure, failures, or the quiet case where jobs still finish as DONE while Peak exceeds the request. Memory Report is an entry point for seeing that gap over a period—and for connecting procurement constraints with day-to-day scheduling behavior.
“I understand—but I don’t feel it”
On slides, Over / Under / waste land as concepts. Without “what happened in yesterday’s jobs,” they rarely drive action. Because standard UIs do not surface Memory Report accuracy buckets, the path to noticing the problem stays narrow.
What the demo shows
- Over-reservation samples (Requested ≫ Peak)
- Under-reservation samples (Peak ≫ Requested)
- Workloads whose path (and runtime) change with the memory budget
- Period collect → Over / Under lists in the UI
Figure 2. Over view — jobs where Requested ≫ Peak; top candidates by excess MB for reservation cuts.
Figure 3. Under view — jobs where Peak ≫ Requested; even DONE jobs can leave an under-reservation trail.
About “Average memory comparison” (see Figure 1)
The top bar is cluster physical memory (context). The middle bar is average Requested; the bottom is average Peak. In our demo, Requested sits well above Peak—an over-reservation leaning period. Do not compare bar lengths across the top vs middle/bottom as one scale; read “capacity context” and “job request vs actual” separately.
Architecture (brief)
Built with IBM Bob: the Quarkus UI and demo environment (including the allowlist-shaped collect design).
Collect at runtime: Browser → Quarkus UI → SSH to LSF → only allowlisted commands → format and list on screen (no free-form commands on the cluster).
Per-job tables (Requested, Peak, turnaround, excess) are shaped from classic bacct -l accounting (not FP16-specific). bacct -mreport (FP16) supplies the period summary—Accuracy Over/Under, averages, and waste.
Figure 4. CLI output of bacct -mreport — Memory report summary (Requested / Peak / Accuracy Over·Under / waste).
The UI shows these same period totals after bringing the result back and listing them.
What happened in a customer conversation
We did not get the “wow” reaction we half expected. Instead, people understood it as smoothly as if they were looking at a normal product screen. The next question was already one step ahead: “So we can’t see memory shortfalls in the usual UI?”
From there the talk turned practical: Are Fix Packs cumulative, or applied one by one? Which version should we use? Can we roll them out? It felt less like a feature tour and more like Fix Pack adoption was already on the table.
That reinforced the point: visualization matters. Topics that stay “understood in theory” after a slide deck keep moving when sample jobs are shown live—into “what we can’t see today,” and then into how to apply and operate. Judging a demo only by surprise misses the real test: Did the conversation needed for a decision start?
Takeaways
When memory is expensive and servers are hard to buy, seeing the gap between request and reality is how you move from pressure to action: visualize over-requests, investigate, then right-size. LSF FP16 Memory Report is the product entry point. A IBM Bob-built demo—sample jobs and a Quarkus UI—makes that path easy to grasp. In our session, the discussion went past comprehension into visibility gaps and Fix Pack specifics. Visualization is not just an aid to product understanding; it can become the shared language that unlocks the next decision.