feat: Automatically resize blocks if they get too small #270
Conversation
This is a naive implementation that resizes input/output blocks if they become too small. Blocks are reallocated once the overflowing batch is successfully drained. This will make startup of a consumer slower, but over time hopefully all blocks eventually reach a state where they won't overflow anymore.
| resize_input_blocks: bool = False, | ||
| resize_output_blocks: bool = False, | ||
| max_input_block_size: Optional[int] = None, | ||
| max_output_block_size: Optional[int] = None, |
There was a problem hiding this comment.
With so many extra parameters, this seems like it would be more complicated rather than less to figure out what to pass here
There was a problem hiding this comment.
yeah I just want to make this opt-in for now. I think long-term we should give input_block_size and default, and enable auto-resizing by default. Then we still have a lot of parameters, but people don't need to set any of them.
Right now they need to configure input_block_size, and we can't give them a default.
There was a problem hiding this comment.
If the user knows what the max is supposed to be, what's the rationale for them to start with a smaller number at all, rather than just passing the max into input_block_size and output_block_size
There was a problem hiding this comment.
I expect most users to not configure a max at all. I just added that because people were concerned about unbounded memory usage, but I would also be fine with not having a max parameter at all. I also believe passing 1GB or 500MB to max_output_block_size would be reasonable, but I don't think such a value would be reasonable for output_block_size.
| "arroyo.strategies.run_task_with_multiprocessing.batch.input.resize" | ||
| ) | ||
| new_input_block = self.__shared_memory_manager.SharedMemory( | ||
| old_input_block.size * 2 |
There was a problem hiding this comment.
This seems like it could trigger quite a few resizes depending on the values passed. Is there another way to calculate the sharedmemory size based on prior seen message sizes?
There was a problem hiding this comment.
I think that's a good idea, we can keep track of the batch size and use it as input for reallocating. I'll have to see how to do that.. I don't think I can use our existing batch size metrics because they don't emit the right value when batches are split up due to input/output overflow.
| self.__metrics.increment( | ||
| "arroyo.strategies.run_task_with_multiprocessing.batch.input.resize" | ||
| ) | ||
| new_input_block = self.__shared_memory_manager.SharedMemory( |
There was a problem hiding this comment.
Knowing that memory settings for Kubernetes are static (we cannot resize the memory assigned to a pod) and that you cannot exceed the memory allocated (OOMKill), do we have a reason to ever resize our input/output blocks instead of just taking all the available memory at the start ? It seems it would be much easier to just statically create memory blocks that used all the available memory of the pod and not try to change anything.
There was a problem hiding this comment.
do we have a reason to ever resize our input/output blocks instead of just taking all the available memory at the start
there's still a ton of stuff outside of arroyo that takes memory, but even if not I don't think it's a good idea to consume significantly more memory than needed. When we deploy a new service we configure k8s limits based on projected memory usage, and later optionally adjust based on average memory usage. If arroyo defaults to consuming all pod memory, we lose insight into how much memory we actually need and how much cost we could save.
There was a problem hiding this comment.
but even if not I don't think it's a good idea to consume significantly more memory than needed
Why? That memory is already allocated and not usable by others anyway.
If you are concerned of not having visibility on the actual usage, why not having specific metrics for that? It seems an easier, safer system with fewer moving parts and fewer failure modes.
There was a problem hiding this comment.
The goal is to eliminate tuning parameters the user has to tweak to get optimal consumer performance. If we manage to do that, then we can start thinking of removing some of those options (as they are not required and have optimal defaults) and therefore moving parts in that sense. I would be aiming for these defaults for all consumers specifically:
auto_resize=Truefor both input/output blockmax_input_block_size/max_output_block_sizeat eitherNoneor 1GB each, or some limit that only a really misbehaving consumer would hitinput_block_size = output_block_size = 10MBso we can be somewhat sure the block can hold a single message
An engineer of the product team should not have to think about how much memory their pod is going to consume and tune Arroyo parameters based off of it.
I don't think this is possible at all with a static approach, because it requires the author of the consumer to think about how much memory their pod has (unclear, gets adjusted by ops), how much their regular code consumes per-process (entirely unclear, especially in a shared codebase like sentry where tons of random stuff gets imported at every CLI invocation) and then think about how much of the remainder can be allocated to input/output blocks.
If you are suggesting a static approach that is also zero-config, I don't know how that would work. Does it mean that arroyo determines free memory and allocates it evenly divided for input/output blocks? And is it evenly, or do input blocks get more than output blocks? And what does it do on a dev machine where there's no k8s request/limit per-consumer?
There was a problem hiding this comment.
If you are concerned of not having visibility on the actual usage, why not having specific metrics for that?
I think this is possible but it feels like Java/node heap tuning parameters and I would like to avoid that sort of experience as well.
|
after talking to lyn, we decided that it makes more sense to expose There was also an idea to use the message size to guide by how much the input block should be reallocated. I tried this and found it was quite hard to implement, I don't think it will significantly impact startup performance. |
This is a naive implementation that resizes input/output blocks if they
become too small.
Blocks are reallocated once the overflowing batch is successfully
drained.
This will make initial throughput of a consumer slower, but over time
hopefully all blocks eventually reach a state where they won't overflow
anymore.
Fix #248