Rangsh commented on issue #12058: URL: https://github.com/apache/seatunnel/issues/12058#issuecomment-5629167349
@SEZ9 thanks — closing the root-cause step from the unchanged `origin/dev` baseline artifacts (same Corretto 11.0.26 / Apple M1 / `profile_benchmarks.sh` run that produced the attached flames). **1. Dominating wall frame(s) for `checkpointOverviewIncrementalUpdate$`** From `flame-wall-reverse.html` / the timed path in `flame-wall-forward.html` (stacks under `jmhStub` → `updateCheckpointOverview`), wall time is dominated by **blocking wait**, not by CPU in `hsync`: roughly **~60%** of timed-path wall samples sit in `updateOverview` → `MapProxyImpl.compute` → `InvocationFuture.get` → `LockSupport.park` / `Unsafe.park` while the durable sync itself runs off the benchmark thread (`RequestFuture.get` → WAL → `HdfsWriter.flush` → `FSDataOutputStream.hsync` → `RawLocalFileSystem$LocalFSFileOutputStream.write`). That matches the CPU zoom where `hsync` is only **0.82%** of CPU samples: the measured path spends wall time **blocked waiting for write-through MapStore / WAL completion**, not burning CPU in sync. The `205.64` / `115.29` samples still do not line up with GC pauses, which also points back to this wait/sync path rather than collector jitter. **Stated cause (one sentence):** on unchanged `origin/dev`, the primary source of the observed latency variance for this method is **wall-clock blocking on the Hazelcast write-through wait** (`InvocationFuture.get` / `RequestFuture` → WAL `hsync` on `file:///`), not GC and not CPU-heavy work inside `hsync`. **2. Loop** Agreed — no further candidate-fix A/B until this cause is accepted. Once we agree, the next step is **one change at a time** on the same environment, then re-run `profile_benchmarks.sh` (`wall` / `cpu` / `gc`) and show the original hotspot shrinks or disappears from the flame / GC summary, not only that Score/Error/CV moved. Happy to take the first single-variable change only after you confirm this reading of the baseline. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
