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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,754 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
68/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, prometheus
Área
observability

Línea de trabajo

Empieza en sandbox.go y sigue applyInPlaceExportUnion y las definiciones de las métricas de diferencias entre snapshots para orchestrator.sandbox.snapshot.diff.ratio y .bytes. Confirma en qué se diferencia la referencia de memfile entre los checkpoints in-place y los del recorrido de destrucción, y documenta esa diferencia en la descripción de la métrica o añade un atributo de referencia. El trabajo estará terminado cuando los usuarios puedan distinguir la referencia de la plantilla de la referencia del último snapshot.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
1.8k
Forks
503
Sin PR fusionados en 30 d

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de e2b-dev/runtime

Todos los issues de e2b-dev/runtime

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.