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

Aberta Para iniciantes
  • Algo errado?
#3,754 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
68/100
Tipo de issue
Documentação
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go, prometheus
Domínio
observability

Direção de pesquisa

Comece em sandbox.go e rastreie applyInPlaceExportUnion e as definições das métricas de diferença de snapshot para orchestrator.sandbox.snapshot.diff.ratio e .bytes. Confirme como a baseline do memfile difere entre os checkpoints in-place e os do caminho de destruição, depois documente essa distinção na descrição da métrica ou adicione um atributo de baseline. O trabalho estará concluído quando os usuários puderem distinguir a baseline do template da baseline do último snapshot.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
1.8k
Forks
503
Nenhum PR com merge em 30d

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de e2b-dev/runtime

Todas as issues de e2b-dev/runtime

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.