Intermittent ReadFile stalls after guest idle — not reproduced, bisector included

Đang mở
  • Có gì không ổn?
#73 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
28/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
go, grpc
Lĩnh vực
distributed-systems, observability

Hướng nghiên cứu

Review the capture tooling under .specs/tools/, especially wedge and e03probe, and use their documented probe modes to understand the existing measurements. A useful outcome would be a reproducible stall with receiver-side latency distributions or a clear pointer to existing guest-read instrumentation; the issue does not define a specific code change.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

question
Summary

On a self-hosted single-node k3s deployment I've observed intermittent multi-second (at times tens of seconds) ReadFile latency on paths that had been reading normally moments earlier. Occurrences correlate loosely with guest inactivity. Working hypothesis class: a wake-up path — suspended guest or idle connection state — blocking on the read. I have not been able to reproduce it under controlled conditions, so I'm filing this for visibility with capture tooling attached, rather than a speculative fix.

Investigation to date

Probes driven by a purpose-built bisector against a real router + guest:

Probe Result
Missing-path reads, cold and warm NotFound in ~25 ms, no stalls
Sequential read load (150 ops) clean
Forced suspend → immediate warm read guest auto-resumed; read completed in 185 ms
Composite (follow-stream + poller + mid-run suspend) 60/60 reads clean
Asks
  1. Has anyone observed multi-second ReadFile stalls correlated with guest idle or suspend/resume?
  2. Is there existing latency instrumentation on the guest read path (metrics or trace spans) that could confirm or refute wake-up attribution? If yes, pointers appreciated. If not, that instrumentation may be worth adding independently — it would turn the next occurrence into evidence rather than anecdote.
  3. If it recurs on our side, I'll attach receiver-side latency distributions captured with the tooling below.
Capture tooling

Available on fork branch barceloneta-k3s under .specs/tools/:

  • wedge — targeted bisector: segment-read patterns (s1/s2/s3), plus getenv, suspend, warm-hang, load, soak modes
  • e03probe — transcript-egress latency probe: follow-stream vs polling vs segmented reads, plus microbenchmarks (shell echo round-trip, StartProcess → first chunk, ReadFile at 4 KB / 256 KB / 1 MB)

Both emit JSON lines on stdout, so runs are directly diffable.

Environment
  • Single-node k3s; guests exercised both run-to-completion and under suspend/resume
  • Standard client → api → router → guest gRPC path
Ngôn ngữ chính
Go
Star
70
Fork
17
Merge trung bình
21 giờ 36 phút
Pull request đã merge (30 ngày)
19

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của agent-substrate/env

Tất cả issue của agent-substrate/env

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.