You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "haohuaijin (via GitHub)" <gi...@apache.org> on 2024/09/23 08:05:52 UTC
[I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
haohuaijin opened a new issue, #6439:
URL: https://github.com/apache/arrow-rs/issues/6439
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
<!--
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
(This section helps Arrow developers understand the context and *why* for this feature, in addition to the *what*)
-->
See this comment https://github.com/apache/arrow-rs/issues/6363#issuecomment-2366788331,
when the `Buffer`'s data is shared between many `Buffer`, the `capacity()` method will always return the total buffer memory usage, which causes the issue #6363, we need discussion the better memory track for shared buffers.
https://github.com/apache/arrow-rs/blob/d05cf6d5e74e79ddcacaa4a68bddaba230b0f163/arrow-buffer/src/buffer/immutable.rs#L166-L168
**Describe the solution you'd like**
<!--
A clear and concise description of what you want to happen.
-->
The easy way to do this is to return the length and the unused capacity of the `Buffer` like pr #6438,
```rust
pub fn capacity(&self) -> usize {
self.length + self.data.capacity() - self.data.len()
}
```
This is changing what these methods report to something else that I'm not sure is correct. Whilst this formulation may benefit your use-case, there are common situations where it will now under report... Perhaps you might file a ticket to discuss a memory tracking approach that better handles shared buffers, as that is the actual issue here. This is not a bug
_Originally posted by @tustvold in https://github.com/apache/arrow-rs/issues/6438#issuecomment-2367426442_
But as @tustvold said, we need more discussion.
**Describe alternatives you've considered**
<!--
A clear and concise description of any alternative solutions or features you've considered.
-->
**Additional context**
<!--
Add any other context or screenshots about the feature request here.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-3188376233
@waynexia has begun implementing memory tracking
- https://github.com/apache/arrow-rs/pull/7303
I have filed an epic to track the work let's continue there
- https://github.com/apache/arrow-rs/issues/8137
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "kszlim (via GitHub)" <gi...@apache.org>.
kszlim commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2423688508
That would be super useful for my use case
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2371800400
> I personally prefer the allocator approach which gives the most accurate stats in theory.
I agree with @waynexia -- if the usecase is "accurately track the total memory used across some number of Arrays which (potentially) share underlying `Buffers`", I think this needs a hook into the underlying allocator. There is proposed PR https://github.com/apache/arrow-rs/pull/6336 which might be worth a look (I haven't had a chance to really understand it yet myself)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb closed issue #6439: [DISSCUSSION] the memory tracking approach that better handles shared buffers
URL: https://github.com/apache/arrow-rs/issues/6439
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "tustvold (via GitHub)" <gi...@apache.org>.
tustvold commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2423683840
Builders are an interesting point, but come with two potential challenges to be aware of:
* Builders tend to over-allocate to avoid repeatedly reallocating
* Updating memory accounting per element is likely prohibitively expensive
This means any "eager" memory computation is likely to work poorly, however, the lazy approach as currently implemented for arrays could actually work quite well.
I could see a world where we remove lazy array memory tracking in favour of eager allocation tracking, and add lazy memory tracking for builders
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "tustvold (via GitHub)" <gi...@apache.org>.
tustvold commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2367502773
https://github.com/apache/arrow-rs/issues/3960 is likely related.
Tagging @jhorstmann @waynexia @alamb
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "kszlim (via GitHub)" <gi...@apache.org>.
kszlim commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2423621612
I don't know if this is the right place to post this, but if this is being reworked, it would also be very useful to have a total memory usage method available within builders, especially for nested stuff. I'm writing a parser which outputs record batches at a static number of rows, but that doesn't work very well when the goal is to keep memory usage roughly constant. It would be nice to be able to get a roughly accurate measure of memory usage in builders in addition to arrays/buffers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "waynexia (via GitHub)" <gi...@apache.org>.
waynexia commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2367676865
I personally prefer the allocator approach which gives the most accurate stats in theory. Given we in some aspects encourage sharing underlying buffer and arrays, only changing the behavior of `.capacity()` would still cause problems for end users when they want to track how many physical memories are used somewhere (e.g., in one query session).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [DISSCUSSION] the memory tracking approach that better handles shared buffers [arrow-rs]
Posted by "tustvold (via GitHub)" <gi...@apache.org>.
tustvold commented on issue #6439:
URL: https://github.com/apache/arrow-rs/issues/6439#issuecomment-2423716771
As this appears to have stalled slightly I have created a POC in https://github.com/apache/arrow-rs/pull/6590 for what I think this could look like
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org