Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

/status/ runs a full SUM(size) over all artifacts on every call

オープン
  • 何か問題がありますか？
#8,196 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
django, kubernetes, postgresql, python
領域
backend, performance

調査の方向性

The full aggregate is in _disk_usage() in pulpcore/app/views/status.py, filtered by pulp_domain and run on every /status/ call when storage is not FileSystem. Read that function and how the storage type is checked, then pick one of the fixes in the issue (periodic task, cache, or an opt-out) after confirming the approach with maintainers. Done means /status/ no longer runs the full SUM(size) per request, with the storage figure still reported.

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

説明

Issue Triage-Needed

Version

  • pulpcore 3.95.2. The code is the same in 3.121.2 and on main.
  • Deployed with pulp-operator, with object storage (Google Cloud Storage) and the default domain only.

Describe the bug

Each call to GET /pulp/api/v3/status/ runs an aggregate over the whole artifact table when the storage is not FileSystem. In pulpcore/app/views/status.py, _disk_usage() does this:

used = Artifact.objects.filter(pulp_domain=domain).aggregate(size=Sum("size", default=0))

This becomes:

SELECT COALESCE(SUM("core_artifact"."size"), $1) AS "size"
FROM "core_artifact"
WHERE "core_artifact"."pulp_domain_id" = $2::uuid

With one domain, the WHERE matches every row, so each call reads all artifacts. The cost grows with the number of artifacts.

The pulp-operator uses /status/ for both default API probes (liveness httpGet, readiness readyz.py). So the query runs on every probe of every API pod, not only when a user asks for the status. In our deployment, this load kept the database CPU high. During package uploads, /status/ became slower than the probe timeout, and the liveness probe restarted healthy API pods.

To Reproduce

  1. Use object storage (for example S3 or GCS) and a large core_artifact table.
  2. Deploy with pulp-operator and the default probes, with many API replicas.
  3. Look at the query above in pg_stat_statements, and at the database CPU.

Expected behavior

/status/ is cheap enough to call from health checks. The storage usage does not run a full aggregate on each call.

Some possible fixes:

  • Compute the storage usage in a periodic task and store or cache the result. /status/ returns the stored value.
  • Cache the result of _disk_usage() for some minutes.
  • Add a query parameter or a setting to leave storage out of the response.

Additional context

  • #7475 reports the same aggregate in the otel_metrics task. Per the comments on #7475, the index from #7511 did not help. With one domain, an index-only scan still reads one entry for each artifact.
  • As a workaround, we override the probes in the Pulp CR: liveness uses /livez/, and readiness calls /status/ less often. We opened an issue in pulp-operator to change the defaults: https://github.com/pulp/pulp-operator/issues/1696
主要言語
Python
スター
606
フォーク
174
平均マージ
16時間 44分
マージ済み PR（30日）
107

環境構築

はじめの一歩

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

pulp/pulpcore のほかの issue

pulp/pulpcore の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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