System Resources

Weasis routinely handles studies far larger than its memory: a CT or MR series is hundreds of slices, a digital mammography image is tens of megabytes, a 3D volume is hundreds of megabytes. The System resources panel shows, in real time, how much of the machine Weasis is using, whether the hardware matches your daily practice, and — when it does not — what to upgrade.

Open it from the menu Help > System resources.

The panel does not change anything by itself. It is a diagnostic view: it observes, measures across all your sessions, and gives a verdict you can act on.

How memory works in Weasis

To read the panel, it helps to know that Weasis uses memory in two separate pools:

• JVM heap — holds the user interface, the DICOM metadata and temporary copies of pixels. Its maximum size is fixed when Weasis starts.
• Native image memory — holds the decoded pixel data of images. This is the pool that grows when you open large studies. It is not part of the heap; it is sized from the physical memory of the machine.

A third pool, GPU memory (VRAM), is used only by the 3D viewer.

This separation is why a single “memory” number is not enough — and why the panel shows both pools side by side.

Reading the panel

The dialog refreshes every two seconds while it is open. It has five sections.

Hardware

A static description of the machine:

Live pressure

Three bars showing current use, each with its peak value for the session:

• JVM heap — interface and metadata memory.
• Native image memory — decoded images currently cached.
• CPU load — processor use by Weasis.

A bar turning red above 90 % means that pool is close to its limit. Native image memory reaching its limit is normal and harmless: Weasis simply drops the least-recently-seen images from the cache and reloads them transparently when you scroll back. A heap bar staying near 100 %, on the other hand, is a real warning sign.

Assessment

The verdict — the heart of the panel. Each line is rated with one of four levels:

• Overall — the worst of the rows below.
• Memory — based on real failure signals, not on raw usage: out-of-memory errors, a 3D volume that had to spill to disk, or sustained garbage-collection overhead. A rare event is tolerated; a recurring one turns the verdict red.
• CPU — sub-optimal on 2 cores or fewer; abundant on 8+ cores left mostly idle.
• Recommended upgrade — see below.

Workload

What the heaviest study you opened actually demanded: the largest image (in megabytes) and the largest volume (in number of slices). These explain why a verdict came out the way it did.

Events (all sessions)

The counters behind the memory verdict, accumulated over every session:

A non-zero count is not necessarily a problem — the panel colors a counter red only when it is the signal currently causing a sub-optimal memory verdict.

Acting on the recommendation

When Memory or CPU is sub-optimal, the Recommended upgrade line gives a concrete target. Weasis distinguishes a configuration problem from a hardware one:

• A larger heap (-Xmx) — shown when the machine has free RAM but Weasis was not allowed to use enough of it. This is fixed by changing a setting, not by buying hardware.
• More RAM — shown when the heap is already a fair share of physical memory: the machine itself is the limit.
• More CPU cores — shown when too few cores slowed image decoding and reconstruction.

Increasing the memory limits

The heap maximum and the native-memory budget are controlled by start-up options. The simplest way to raise the heap is the -Xmx option; the native-image pool is controlled by a Weasis property:

For an installed Weasis, edit the java-options of the application configuration (for example app/Weasis.cfg next to the installation). For a study workstation that opens large studies, raising the native-memory percentage keeps more images cached and avoids reloads:

weasis.native.memory.percent=70

The full set of memory parameters is described in the Memory Management developer guide.

Exporting the report

The Copy report button places a plain-text summary of the whole panel on the clipboard — hardware, verdict, recommendation and event counters. Paste it into a bug report or a message to your IT department when asking for a hardware upgrade.