Disk polling: investigate tail latency under concurrent writes

オープン
#4,178 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
docker, rust
領域
performance

調査の方向性

リンクされたリリースで公開されている生のタイムラインとリソース記録から始め、実行順序と有効な低速操作を分けて扱います。#4177 の診断情報とタイムスタンプを再利用し、必要な場合にのみステージまたはキューに関する疎な観測を追加します。完了条件は、レイテンシ境界と負荷モデルを明示し、存在する場合はサポート対象のメカニズムを特定し、親 issue の固定予算および到着モデルのルールに従うことです。

索引モデルが issue の本文から書いたものです。

説明

performance server

Part of #4174, which records the compared revisions, workload and statistical method.

Investigate the unresolved tail behavior under concurrent writes. Start with archived timelines; collect more diagnostics only when a recurring delay or an explicit tail requirement makes the decision useful.

Case Change in run p99 Pointwise 95% interval
Explicit offset −0.02% [−2.79%, +2.88%]
Explicit offset with writes +3.40% [−0.62%, +7.63%]
Next −0.84% [−2.37%, +0.69%]
Consumer group +0.86% [−0.89%, +2.65%]
Resident −2.33% [−6.29%, +1.23%]

Positive values mean higher p99. Estimates are geometric means of paired ratios of run p99 values, not pooled request percentiles. They use the same pair bootstrap described in #4174. The interval with writes includes a small improvement and a meaningful increase, so it neither confirms a tail regression nor resolves a 3% margin. Mean elapsed time is a separate metric, reported in the parent.

The preceding campaign with the same binaries reported Next p99 +6.79% and group p99 +6.06%; those increases were not reproduced. Keep the campaigns separate. The rerun followed reported high Docker memory consumption and a guest restart, but memory pressure was not independently controlled and continuously measured. No container CPU throttling or memory limit events were recorded; those checks cannot exclude host pressure or establish a memory cause.

  1. Inspect the published raw timelines and resource records, including run order and valid slow operations. Look for clustering around a stage or resource condition.
  2. Reuse the parent's diagnostics and timestamps from #4177. Add sparse stage timestamps, scheduler waits or queue observations only where needed to locate the delay. CPU profiles alone cannot locate waiting.
  3. State the latency boundary, load model and worthwhile effect before fresh confirmation. Follow the parent's fixed budget and arrival model rules, including scheduling delays, errors and timeouts.

Tracing can create the tail being studied. Preserve valid slow runs and stop according to the declared budget. Repeating measurements on the same VM cannot remove systematic environment bias or establish physical device latency. A change should address a supported mechanism, not merely a difference between campaigns.

主要言語
Rust
スター
5.2k
フォーク
502
平均マージ
2日 21時間
マージ済み PR(30日)
159

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/iggy のほかの issue

apache/iggy の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。