Reduce stage log Put allocation overhead in filestore persistence
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 58/100
Hướng nghiên cứu
Bắt đầu tại pkg/app/server/stagelogstore/filestore.go, đọc stageLogFileStore.Put quanh các dòng 65-82 và TODO về hiệu năng của nó. Thêm benchmark tập trung được mô tả trong issue cho lf.Blocks tăng dần, sau đó so sánh số lượng cấp phát và chi phí ghi trong khi kiểm tra hành vi đọc hiện có. Được coi là hoàn tất khi có cải thiện đo lường được, định dạng phân tách theo dòng và EOL marker được giữ nguyên, đồng thời không có thay đổi hành vi không liên quan.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happened:
Summary
stageLogFileStore.Put rewrites the entire stage-log fragment on every save by JSON-encoding each LogBlock into a fresh in-memory buffer and then writing the full byte slice to the filestore. The code already carries a TODO for this hot path, and the current implementation scales allocations and latency with total block count on every write.
Affected Area
pkg/app/server/stagelogstore/filestore.go- stage log persistence in the control plane filestore path
What you expected to happen:
Large or frequently updated stage logs should be persisted with lower peak allocation overhead and an encoding path that does not materialize avoidable intermediate payloads for every block.
How to reproduce it:
- Open
pkg/app/server/stagelogstore/filestore.go. - Inspect
stageLogFileStore.Putaround the existing performance TODO. - Note that each call loops over all
lf.Blocks, marshals each block individually, appends it to abytes.Buffer, and finally callsfilestore.Putwith the complete byte slice. - Add a focused benchmark that grows
lf.Blocksand repeatedly callsPut. - Observe allocation count and write cost grow with total block count because the full fragment is rebuilt for every save.
Environment:
pipedversion: repository checkout on 2026-07-13control-planeversion: repository checkout on 2026-07-13- Others: validated by current code inspection; previous related issue
#40was closed as stale, not fixed
Technical Evidence
pkg/app/server/stagelogstore/filestore.go:65-82rebuilds the payload in memory for everyPut- The code includes
TODO: Reduce the number of marshaling log blocks for improving performance - Upstream issue
#40tracked the same performance concern but was auto-closed as stale without an implementation change
Suspected Root Cause
The filestore path is implemented as full-object persistence, and Put currently uses per-block json.Marshal calls plus a whole-fragment buffer build before every write.
Proposed Direction
Start with a benchmark for realistic stage-log sizes, then refactor the write path to stream JSON encoding into the final buffer or otherwise reduce avoidable intermediate allocations while preserving the existing line-delimited on-disk format and EOL completion marker.
Acceptance Criteria
- A benchmark captures baseline throughput and allocations for larger stage-log fragments
- The write path measurably reduces allocations or latency compared with the current implementation
- Existing read compatibility for stored stage logs is preserved
- No unrelated stage-log behavior changes are introduced
- Ngôn ngữ chính
- Go
- Star
- 1.4k
- Fork
- 391
- Merge trung bình
- 4 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 58
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pipe-cd/pipecd
-
Applications at the repository root are not triggered by new commitsCó thể đã có người làm @Daksha1611 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTINGCó thể đã có người làm @Dhirenderchoudhary đã nhận hôm nay. Đang mở
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 74/100
pipe-cd/pipecd#7626 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
pipectl transfer restore application drops backed-up labelsCó thể đã có người làm @bhavishyajain545 đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
pipe-cd/pipecd#7622 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của pipe-cd/pipecd
Issue tương tự
-
needs-triage typo
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
llm-d-incubation/llm-d-scaling-manager#122 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue severity: low tech-debt
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 75/100
TMHSDigital/subenum#329 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] Backend summarize min() / max() panics when a field has no numeric valuesCó thể đã có người làm @weng5e đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
grafana/grafana-infinity-datasource#1832 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
tech-debt
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
GillMacedo/godebugdiff#13 ·