Issues / #1984

#1984 `--ple-io mmap` picked automatically at boot can wedge the engine: "no progress for 60 s" at the prompt's first chunk (self-stop + restart)

open · @jy02375437-max · 0 Kommentare · Auf GitHub

Server & APINVIDIA / CUDAModels & quantsWindows

Beschreibung

**Summary.** On this box (Windows 11 26200, single RTX 4090 D 48 GB, Ryzen AI Max+ 395, 127.1 GiB RAM, engine 0.1.43 release build, IQ3_XXS GSQ-RCO with a `tools/iq_pack.py` native pack) the engine self-stopped four times with `--ple-io mmap` — three times in a `--mmap-experts` session, once in a plain arena session — all in sessions whose boot had auto-selected `--ple-io mmap`. The stall stage is the first prompt chunk (`layer 1 of the prompt chunk from token 0`) and the counters show *zero* progress, not slow I/O. Pinning `--ple-io direct` in the config restored normal service (32K needles 9/9, repeated).

**What those sessions logged at boot**

```
strata generate: --ple-io direct measures slow here (11812 rows/s, about 48 MB/s of random 4 KiB reads):
                 using --ple-io mmap instead (the OS file cache holds the pages; --ple-io direct forces the
                 old mode, --ple-io ram keeps the table in RAM)
```

**What happened next (arena-mode session, a 32K prompt)**

```
strata serve: no progress for 60 s during a request (reading the prompt (batched): layer 1 of the prompt
chunk from token 0) - stopping the engine so the server starts it again (issue #29)
strata serve: stall report (engine 0.1.43): stage "reading the prompt (batched): layer 1 of the prompt
chunk from token 0" for 60 s; 0 layers served since the last finished step
  expert pool: epoch 0, batch epoch 0: 0 of 0 jobs claimed, 0 done; 15 of 15 workers parked, 15 sleeping
  expert pool threads: w0..w14=sleeping; host idle for 90366 ms
  verify window: 0 tokens at position 0, host at layer step 1; the GPU rang 0; flags: served 0, plan (A) 0, copies (B) 0
  memory: 7964 MiB resident, 96196 MiB committed, 63482 MiB RAM available; 3184370 page faults so far
  wrote the thread stacks to ...\strata-stall-3644.dmp (attach it to the issue)
strata: released the verify window's GPU waits (#267): the GPU finished in 0 ms
```

`server.py` restarted the engine; clients saw HTTP 503 while that happened. The stopped engine was left with a
7.1 GB working set against 96 GB committed (its pages had been paged out / compressed).

**The A/B** — same config file, same machine, same hour; only the boot probe's verdict differs:

| session | boot line | the same 32K prompt |
| --- | --- | --- |
| 02:20:21 | `direct measures slow here (11812 rows/s)` → **`using --ple-io mmap instead`** | `no progress for 60 s` → self-stop → `strata-stall-3644.dmp` |
| 02:23:34 (auto-restart) | `PLE direct read probe: 42898 rows/s (fine)` | 32K needle 3x3 = 9/9, reads 10.9 s / 14.8 s (repeated) |

The three earlier stalls were in a `--mmap-experts` session (GGUF in place, no `experts.bin`) whose log also
shows the auto-switch to `--ple-io mmap`: dumps `strata-stall-43064.dmp` (01:48), `strata-stall-38852.dmp`
(01:52), `strata-stall-21644.dmp` (01:57) — same stage, same "0 layers served" pattern. I can attach all four
dumps if useful; I held them back because thread stacks may contain memory contents.

**Context that may matter.** The probe's verdict varies with the state of the OS file cache. Before these
sessions the machine had done a lot of I/O (a 47 GB pack build, full-file sha256 passes, an 81 GB download, and
mapped-mode runs that read ~104 GB through the file tier), so "direct measures slow" may well have been true at
that moment — but the fallback then appears to *stall* rather than merely be slow. The stall counters
(`0 of 0 jobs claimed`, all workers sleeping, host idle 90 s, GPU rang 0) look like a read that never completes
rather than I/O that is slow. It may be the same family as #1910 (a report about 0.1.42 mmap'ing the PLE shard
and re-reading it).

**Workaround I now use.** Pin `--ple-io direct` in the config: with `--ple-io` given explicitly the probe only
warns (`generate.cpp:3180`) and the engine stays on the unbuffered direct reads with the bounded row cache.
Since then: 32K needles 9/9 repeatedly, no stalls. (`--ple-io ram` is the other candidate; I measured it on
this box — +0.1% at 117K prompt tokens — so I kept `direct`.)

**Question.** Is the mmap PLE path expected to be stall-safe on NTFS? Happy to rerun with `STRATA_*` tracing,
to keep a session in the bad state for you to inspect, or to send the four dumps.

Mehr auf der Site

Links zu Install, Modellen, Releases.