Skip to content

Improve accuracy and change semantics of metric wasm_memory_bytes#5131

Open
gefjon wants to merge 4 commits into
masterfrom
phoebe/wasmtime-memory-usage-metric
Open

Improve accuracy and change semantics of metric wasm_memory_bytes#5131
gefjon wants to merge 4 commits into
masterfrom
phoebe/wasmtime-memory-usage-metric

Conversation

@gefjon
Copy link
Copy Markdown
Contributor

@gefjon gefjon commented May 27, 2026

Marked as draft until I write its private companion; this PR will probably pass internal tests but still requires private changes.

Description of Changes

Prior to this commit, the metric wasm_memory_bytes had several problems:

  1. Despite its name, it was used for both Wasmtime and V8 modules. For V8 modules, it was the same value as v8_used_heap_size_bytes.
  2. It stored only the value for a single instance at any given time, so it under-reported a database's memory usage.
  3. The same row (set of label values) was written concurrently by all instances of a particular database, with each one clobbering the previously written value.

In this commit, we change the metric so that:

  1. It is recorded only for Wasmtime instances, not V8 instances. For V8 instances, instead directly check v8_used_heap_size_bytes, or one of the other V8 heap metrics. This change involved moving the recording of this metric from module_host_actor.rs to wasmtime/wasm_instance_env.rs
  2. Similar to the V8 heap metrics, all the instances cooperatively share the metric entry, updating it by incrementing and decrementing rather than setting.

Note that this metric is used for billing, and so we will need to update our billing code (elsewhere) to account for the change. In particular, our billing code should now charge for the sum of wasm_memory_bytes and v8_used_heap_size_bytes. We also should expect with this change for each database's recorded usage to increase, as we are now accurately recording the usage for all instances, not just one.

API and ABI breaking changes

Billing metric semantics changed.

Expected complexity level and risk

3: billing metric semantics changed.

Testing

I do not know how to test metrics.

Prior to this commit, the metric `wasm_memory_bytes` had several problems:

1. Despite its name, it was used for both Wasmtime and V8 modules.
   For V8 modules, it was the same value as `v8_used_heap_size_bytes`.
2. It stored only the value for a single instance at any given time,
   so it under-reported a database's memory usage.
3. The same row (set of label values) was written concurrently
   by all instances of a particular database,
   with each one clobbering the previously written value.

In this commit, we change the metric so that:

1. It is recorded only for Wasmtime instances, not V8 instances.
   For V8 instances, instead directly check `v8_used_heap_size_bytes`,
   or one of the other V8 heap metrics.
   This change involved moving the recording of this metric from `module_host_actor.rs`
   to `wasmtime/wasm_instance_env.rs`
2. Similar to the V8 heap metrics, all the instances cooperatively share the metric entry,
   updating it by incrementing and decrementing rather than `set`ting.

Note that this metric is used for billing,
and so we will need to update our billing code (elsewhere) to account for the change.
In particular, our billing code should now charge for
the sum of `wasm_memory_bytes` and `v8_used_heap_size_bytes`.
We also should expect with this change for each database's recorded usage to increase,
as we are now accurately recording the usage for all instances, not just one.
@gefjon gefjon requested a review from joshua-spacetime May 27, 2026 16:55
Comment thread crates/core/src/host/wasmtime/wasm_instance_env.rs Outdated
Comment thread crates/core/src/host/v8/mod.rs Outdated
@gefjon gefjon marked this pull request as ready for review May 28, 2026 18:16
@gefjon gefjon requested a review from joshua-spacetime May 28, 2026 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants