Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#8,196 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
django, kubernetes, postgresql, python
Ambito
backend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Issue

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
Lingua principale
Python
Stelle
612
Fork
175
Merge medio
16h 53m
PR unite (30g)
112

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pulp/pulpcore

Tutte le issue di pulp/pulpcore

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.