> ## Documentation Index > Fetch the complete documentation index at: https://docs.nikaplanet.com/llms.txt > Use this file to discover all available pages before exploring further. # Right-Size GPU, CPU and RAM per Geoprocessing Worker > Every NIKA GeoEngine run records runtime and CPU, memory and GPU use over time, so you can pick the right machine class for each worker from evidence. Every run records its runtime and its CPU, memory and GPU use over time. That turns "how big a machine does this worker need?" from a guess into a reading. > [card] Every 30 s > > CPU and memory samples > [card] Every 5 s > > GPU use, GPU memory and power > [card] Every run > > Including failed and stopped ones GPU samples are the average of the driver's own high-frequency readings, so short spikes are not missed between samples. Records are saved throughout the run and again when a task stops, so a task killed for running out of memory still leaves its curve behind. Recording never fails a run. ## Read one run A land-cover classification run on the GPU class: 64 GiB of RAM and one GPU, 42 minutes. Hover to read all three signals at once. > [card] 42 min > > Runtime > [card] 34.2 GiB > > Peak memory, of 64 GiB > [card] 4.0 cores > > Peak CPU, of 8 > [card] 76% > > Of the run with the GPU busy * **Memory peaks at stitching, not inference.** Size for the peak: 64 GiB is safe, 32 GiB would be killed at minute 28. * **CPU is busy only while loading and writing.** Eight cores is generous; four would do. * **The GPU dips every two minutes** while the next tile is read. Faster storage, or prefetching the next tile, buys time on the most expensive node. ## Right-size across a batch One run shows a shape. A batch shows the spread. These are the peak memory figures for the 200 tasks of a `cloud-removal-ndvi` batch. Pick a class and a headroom margin to see what would happen. Class 16 GiB32 GiB 48 GiB64 GiB Headroom **20%** Three outlier scenes push the whole batch up a class. Tiling those three lets the other 197 run on a class half the size. That is the kind of decision this data makes obvious. ## Find reserved capacity you don't use Requested memory (track) against the 95th-percentile peak (bar) for each worker, across its last 30 days of runs. Reserved but unused memory is capacity no other task can use. Cutting a class in half doubles how many tasks a pool runs at once, at the same cost. ## Three decisions the data answers | Decision | Read | Rule of thumb | | - | - | - | | **Which class?** | Peak memory across a batch | Smallest class above the largest peak plus 15–25% | | **Is the GPU worth it?** | GPU utilisation over the run | Mostly under 30%: the work is I/O- or CPU-bound, so try the CPU class | | **How big a pool?** | Runtime and concurrency per batch | Pool maximum = items ÷ acceptable waves | NIKA can also review your run records and advise how to optimise each workload. ## Get the data Metrics are available per task. Each series names its columns and sample interval, then lists one row per sample. The endpoint path and response shape below are illustrative; the released API reference gives the final names. ```http theme={null} GET https:///v1/jobs/j-7q2c9xk4/tasks/017/metrics ``` ```json theme={null} { "cpu_mem": { "interval_s": 30, "columns": ["t", "cpu_cores", "mem_gib"], "rows": [[0, 3.61, 2.1], [30, 3.58, 4.7], [60, 3.70, 7.3]] }, "gpu": { "interval_s": 5, "gpu_count": 1, "columns": ["t", "gpu_util_pct", "gpu_mem_gib", "power_w", "power_pct_tdp"], "rows": [[240, 91.2, 17.8, 61.0, 84.7], [245, 89.6, 17.8, 60.2, 83.6]] } } ``` Load it into a notebook, your monitoring stack or a dashboard to track trends across versions. A new worker version that suddenly needs twice the memory is worth catching before it reaches production. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.