Stream: wasmtime

Topic: Store Memory consumption patterns


view this post on Zulip spino17 (Nov 12 2024 at 12:13):

If I cache store, is it expected to increase my memory consumption as I would be holding up linear memory allocated for the module. Is it virtual memory or resident memory. Will the memory be under control if I keep on caching the store objects.

view this post on Zulip Lann Martin (Nov 12 2024 at 13:15):

Could you say more about what you by "caching"? A Store itself is just a container. If you have instantiated modules into that Store then it will have at least one linear memory which will (typically) include at least a large virtual allocation. Whether there is also "resident" memory usage is a bit dependent on the module, wasmtime configuration, platform, and also on what exactly you mean by "resident". For example, your module's predefined memory contents may be memory mapped from the module's source file in some situations which will only use physical memory when accessed.

view this post on Zulip Lann Martin (Nov 12 2024 at 13:17):

As general advice, I would confirm with benchmarking that Store caching actually helps in your situation before doing it. You may also be able to get most of the benefits of manual caching with wasmtime's pooling allocator.

view this post on Zulip spino17 (Nov 12 2024 at 14:25):

yeah I am using pooling allocator, and then caching (instance, store) tuple where store is just for that instance. So for every module I have this tuple cached and I use it whenever I want to execute methods from that module

view this post on Zulip spino17 (Nov 12 2024 at 14:27):

when I use InstancePre then I am getting half the throughput as when I am caching (instance, store) tuple so naturally I am inclined towards the latter but need to know whether it will hold up the memory allocated to the store and have increasing runtime memory consumption ?

view this post on Zulip Lann Martin (Nov 12 2024 at 15:07):

If you are keeping one long-lived instance around then yes, at the very least it will be using whatever memory the module code itself allocates.

view this post on Zulip fitzgen (he/him) (Nov 12 2024 at 18:49):

to put it another way: nothing in a store is deallocated until the store is dropped.

the intention is that, if you want to recycle resources, then you drop the store and create a fresh one the next time you need to run a Wasm instance.

in general, create one store per "task" and then throw it away when the task is complete and create a new store for the next task. (for example, create a new store for handling each HTTP request in a function-as-a-service platform)


Last updated: Nov 22 2024 at 16:03 UTC