snapshot.diff.ratio memfile baseline is path-dependent (template vs last-snapshot) — misleads skip/no-op analysis

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,754 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
68/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
Active
Stack technique
go, prometheus
Domaine
observability

Piste de recherche

Commencez dans sandbox.go et suivez applyInPlaceExportUnion ainsi que les définitions des métriques d’écart entre snapshots pour orchestrator.sandbox.snapshot.diff.ratio et .bytes. Confirmez en quoi la référence memfile diffère entre les checkpoints in-place et ceux du parcours de destruction, puis documentez cette distinction dans la description de la métrique ou ajoutez un attribut de référence. Le travail est terminé lorsque les utilisateurs peuvent distinguer la référence du modèle de celle du dernier snapshot.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

orchestrator.sandbox.snapshot.diff.ratio / .bytes for file_type=memfile are measured against different baselines depending on the checkpoint path, which makes the memory ratio easy to misread as "how much changed this pause."

Detail

  • In-place checkpoint: the memory export advances a cumulative baseline (applyInPlaceExportUnion, sandbox.go), so the diff is roughly "since the last in-place checkpoint."
  • Destroy-path pause (the common autopause / pause→resume-fresh path): the memory diff is parented on the ORIGINAL template, not the previous snapshot. The in-code comment says it outright:

    "In-place checkpoints parent every diff on the ORIGINAL template header ... Only the in-place path advances the baseline — a destroyed sandbox has no next interval."

So on the destroy path the memfile diff reflects the resume working set (pages faulted/written since the template loaded), not the change since the last snapshot. A genuine no-op pause still reports a large memfile dirty ratio.

Impact

Anyone using snapshot.diff.ratio{file_type=memfile} to gauge "did memory change this pause" (e.g. to size a skip-unchanged / fs-only-downgrade opportunity) will over-count memory change on the destroy path. The rootfs dimension is a true diff and is not affected.

Suggestion

Either (a) add a baseline ∈ {template, last_snapshot} attribute to the diff metrics so dashboards can separate the two, or (b) document the path-dependent baseline in the metric description. No behavior change.

Context: surfaced while measuring the no-op-pause rate for a possible skip-unchanged feature (see the change_footprint metric PR). On a synthetic dev workload the memfile dirty sat in a stable ~115-134 MB band on every pause regardless of work — the template-baseline artifact, not real per-pause churn.

Langage dominant
Go
Étoiles
1.8k
Forks
503
Aucune PR mergée en 30 j

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de e2b-dev/runtime

Toutes les issues de e2b-dev/runtime

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.