Azure / Azure/azure-functions-host
Flex Consumption Per-Function Scaling: Can One Service Bus Trigger Cause OOM in Another?
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
We have an Azure Function App running on the Flex Consumption plan, configured with 512 MB memory. We understand that Flex uses per-function scaling, meaning each Service Bus trigger should scale independently and run on its own instance when needed.
Our Function App contains only Service Bus triggers and Timer triggers. One of the Service Bus triggers has very low execution frequency, yet it occasionally throws Out-of-Memory (OOM) exceptions in production. We tried reproducing the issue in our development environment by applying load, but it never happens there.
The key behavioral difference is:
In Dev, after some time, the Function App becomes idle, so the memory working set drops to zero.
In Prod, the Function App never becomes idle because other Service Bus triggers keep receiving messages, so at least one instance always remains active.
What we don’t understand is: If Flex performs per-function scaling, and each trigger should receive its own dedicated instance, how can a low-frequency trigger be impacted by memory usage from other triggers? Shouldn’t Azure create a separate instance for it?
So our core question is: Is it possible, under Flex per-function scaling, for one Service Bus trigger’s memory usage to affect another trigger — and if so, why?
If Flex Consumption truly provides per-function independent instances, then how can memory pressure from one trigger affect another? For example, if FunctionA has a memory leak or performs heavy processing, and FunctionB runs infrequently, Flex should allocate a separate instance with its own memory for FunctionB. In that case, FunctionB shouldn’t experience OOM errors caused by FunctionA. So how—and under what circumstances—can memory be shared or inherited between triggers if each trigger is supposed to scale independently?
Contributor guide
Research direction
Start by reviewing the Flex Consumption per-function scaling behavior and the Service Bus and Timer trigger setup described in the issue. Compare the development and production idle states, then establish whether the reported OOM interaction is expected and document the conditions or evidence needed to explain the difference.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- backend, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100