You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Li Jin <ic...@gmail.com> on 2023/09/06 15:55:41 UTC
[C++] Potential cache/memory leak when reading parquet
Hello,
I have been testing "What is the max rss needed to scan through ~100G of
data in a parquet stored in gcs using Arrow C++".
The current answer is about ~6G of memory which seems a bit high so I
looked into it. What I observed during the process led me to think that
there are some potential cache/memory issues in the dataset/parquet cpp
code.
Main observation:
(1) As I am scanning through the dataset, I printed out (a) memory
allocated by the memory pool from ScanOptions (b) process rss. I found that
while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
increasing during the scan (looks linear to the number of files scanned).
(2) I tested ScanNode in Arrow as well as an in-house library that
implements its own "S3Dataset" similar to Arrow dataset, both showing
similar rss usage. (Which led me to think the issue is more likely to be in
the parquet cpp code instead of dataset code).
(3) Scan the same dataset twice in the same process doesn't increase the
max rss.
I plan to look into the parquet cpp/dataset code but I wonder if someone
has some clues what the issue might be or where to look at?
Thanks,
Li
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
> Hi Jin,
> Do you have more information about the parquet file?
This is metadata for one file (I scanned about 2000 files in total)
<pyarrow._parquet.FileMetaData object at 0x7fb885e92ef0>
created_by: parquet-mr version 1.12.3 (build
f8dced182c4c1fbdec6ccb3185537b5a01e6ed6b)
num_columns: 840
num_rows: 87382
num_row_groups: 1
format_version: 1.0
serialized_size: 247053
On Wed, Sep 6, 2023 at 12:22 PM wish maple <ma...@gmail.com> wrote:
> 1. In dataset, it might have `fragment_readahead` or other.
> 2. In Parquet, if prebuffer is enabled, it will prebuffer some column ( See
> `FileReaderImpl::GetRecordBatchReader`)
> 3. In Parquet, if non-buffered read is enabled, when read a column, the
> whole ColumChunk would be read.
> Otherwise, it will "buffered" read it decided by buffer-size
>
> Maybe I forgot someplaces. You can try to check that.
>
> Best
> Xuwei Fu
>
> Li Jin <ic...@gmail.com> 于2023年9月7日周四 00:16写道：
>
> > Thanks both for the quick response! I wonder if there is some code in
> > parquet cpp that might be keeping some cached information (perhaps
> > metadata) per file scanned?
> >
> > On Wed, Sep 6, 2023 at 12:10 PM wish maple <ma...@gmail.com>
> wrote:
> >
> > > I've met lots of Parquet Dataset issues. The main problem is that
> > currently
> > > we have 2 sets or API
> > > and they have different scan-options. And sometimes different
> interfaces
> > > like `to_batches()` or
> > > others would enable different scan options.
> > >
> > > I think [2] is similar to your problem. 1-4 are some issues I met
> before.
> > >
> > > As for the code, you may take a look at :
> > > 1. ParquetFileFormat and Dataset related.
> > > 2. FileSystem and CacheRange. Parquet might use this to handle
> pre-buffer
> > > 3. How Parquet RowReader handle IO
> > >
> > > [1] https://github.com/apache/arrow/issues/36765
> > > [2] https://github.com/apache/arrow/issues/37139
> > > [3] https://github.com/apache/arrow/issues/36587
> > > [4] https://github.com/apache/arrow/issues/37136
> > >
> > > Li Jin <ic...@gmail.com> 于2023年9月6日周三 23:56写道：
> > >
> > > > Hello,
> > > >
> > > > I have been testing "What is the max rss needed to scan through ~100G
> > of
> > > > data in a parquet stored in gcs using Arrow C++".
> > > >
> > > > The current answer is about ~6G of memory which seems a bit high so I
> > > > looked into it. What I observed during the process led me to think
> that
> > > > there are some potential cache/memory issues in the dataset/parquet
> cpp
> > > > code.
> > > >
> > > > Main observation:
> > > > (1) As I am scanning through the dataset, I printed out (a) memory
> > > > allocated by the memory pool from ScanOptions (b) process rss. I
> found
> > > that
> > > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
> > keeps
> > > > increasing during the scan (looks linear to the number of files
> > scanned).
> > > > (2) I tested ScanNode in Arrow as well as an in-house library that
> > > > implements its own "S3Dataset" similar to Arrow dataset, both showing
> > > > similar rss usage. (Which led me to think the issue is more likely to
> > be
> > > in
> > > > the parquet cpp code instead of dataset code).
> > > > (3) Scan the same dataset twice in the same process doesn't increase
> > the
> > > > max rss.
> > > >
> > > > I plan to look into the parquet cpp/dataset code but I wonder if
> > someone
> > > > has some clues what the issue might be or where to look at?
> > > >
> > > > Thanks,
> > > > Li
> > > >
> > >
> >
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by wish maple <ma...@gmail.com>.
1. In dataset, it might have `fragment_readahead` or other.
2. In Parquet, if prebuffer is enabled, it will prebuffer some column ( See
`FileReaderImpl::GetRecordBatchReader`)
3. In Parquet, if non-buffered read is enabled, when read a column, the
whole ColumChunk would be read.
Otherwise, it will "buffered" read it decided by buffer-size
Maybe I forgot someplaces. You can try to check that.
Best
Xuwei Fu
Li Jin <ic...@gmail.com> 于2023年9月7日周四 00:16写道：
> Thanks both for the quick response! I wonder if there is some code in
> parquet cpp that might be keeping some cached information (perhaps
> metadata) per file scanned?
>
> On Wed, Sep 6, 2023 at 12:10 PM wish maple <ma...@gmail.com> wrote:
>
> > I've met lots of Parquet Dataset issues. The main problem is that
> currently
> > we have 2 sets or API
> > and they have different scan-options. And sometimes different interfaces
> > like `to_batches()` or
> > others would enable different scan options.
> >
> > I think [2] is similar to your problem. 1-4 are some issues I met before.
> >
> > As for the code, you may take a look at :
> > 1. ParquetFileFormat and Dataset related.
> > 2. FileSystem and CacheRange. Parquet might use this to handle pre-buffer
> > 3. How Parquet RowReader handle IO
> >
> > [1] https://github.com/apache/arrow/issues/36765
> > [2] https://github.com/apache/arrow/issues/37139
> > [3] https://github.com/apache/arrow/issues/36587
> > [4] https://github.com/apache/arrow/issues/37136
> >
> > Li Jin <ic...@gmail.com> 于2023年9月6日周三 23:56写道：
> >
> > > Hello,
> > >
> > > I have been testing "What is the max rss needed to scan through ~100G
> of
> > > data in a parquet stored in gcs using Arrow C++".
> > >
> > > The current answer is about ~6G of memory which seems a bit high so I
> > > looked into it. What I observed during the process led me to think that
> > > there are some potential cache/memory issues in the dataset/parquet cpp
> > > code.
> > >
> > > Main observation:
> > > (1) As I am scanning through the dataset, I printed out (a) memory
> > > allocated by the memory pool from ScanOptions (b) process rss. I found
> > that
> > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
> keeps
> > > increasing during the scan (looks linear to the number of files
> scanned).
> > > (2) I tested ScanNode in Arrow as well as an in-house library that
> > > implements its own "S3Dataset" similar to Arrow dataset, both showing
> > > similar rss usage. (Which led me to think the issue is more likely to
> be
> > in
> > > the parquet cpp code instead of dataset code).
> > > (3) Scan the same dataset twice in the same process doesn't increase
> the
> > > max rss.
> > >
> > > I plan to look into the parquet cpp/dataset code but I wonder if
> someone
> > > has some clues what the issue might be or where to look at?
> > >
> > > Thanks,
> > > Li
> > >
> >
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Thanks both for the quick response! I wonder if there is some code in
parquet cpp that might be keeping some cached information (perhaps
metadata) per file scanned?
On Wed, Sep 6, 2023 at 12:10 PM wish maple <ma...@gmail.com> wrote:
> I've met lots of Parquet Dataset issues. The main problem is that currently
> we have 2 sets or API
> and they have different scan-options. And sometimes different interfaces
> like `to_batches()` or
> others would enable different scan options.
>
> I think [2] is similar to your problem. 1-4 are some issues I met before.
>
> As for the code, you may take a look at :
> 1. ParquetFileFormat and Dataset related.
> 2. FileSystem and CacheRange. Parquet might use this to handle pre-buffer
> 3. How Parquet RowReader handle IO
>
> [1] https://github.com/apache/arrow/issues/36765
> [2] https://github.com/apache/arrow/issues/37139
> [3] https://github.com/apache/arrow/issues/36587
> [4] https://github.com/apache/arrow/issues/37136
>
> Li Jin <ic...@gmail.com> 于2023年9月6日周三 23:56写道：
>
> > Hello,
> >
> > I have been testing "What is the max rss needed to scan through ~100G of
> > data in a parquet stored in gcs using Arrow C++".
> >
> > The current answer is about ~6G of memory which seems a bit high so I
> > looked into it. What I observed during the process led me to think that
> > there are some potential cache/memory issues in the dataset/parquet cpp
> > code.
> >
> > Main observation:
> > (1) As I am scanning through the dataset, I printed out (a) memory
> > allocated by the memory pool from ScanOptions (b) process rss. I found
> that
> > while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> > increasing during the scan (looks linear to the number of files scanned).
> > (2) I tested ScanNode in Arrow as well as an in-house library that
> > implements its own "S3Dataset" similar to Arrow dataset, both showing
> > similar rss usage. (Which led me to think the issue is more likely to be
> in
> > the parquet cpp code instead of dataset code).
> > (3) Scan the same dataset twice in the same process doesn't increase the
> > max rss.
> >
> > I plan to look into the parquet cpp/dataset code but I wonder if someone
> > has some clues what the issue might be or where to look at?
> >
> > Thanks,
> > Li
> >
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by wish maple <ma...@gmail.com>.
I've met lots of Parquet Dataset issues. The main problem is that currently
we have 2 sets or API
and they have different scan-options. And sometimes different interfaces
like `to_batches()` or
others would enable different scan options.
I think [2] is similar to your problem. 1-4 are some issues I met before.
As for the code, you may take a look at :
1. ParquetFileFormat and Dataset related.
2. FileSystem and CacheRange. Parquet might use this to handle pre-buffer
3. How Parquet RowReader handle IO
[1] https://github.com/apache/arrow/issues/36765
[2] https://github.com/apache/arrow/issues/37139
[3] https://github.com/apache/arrow/issues/36587
[4] https://github.com/apache/arrow/issues/37136
Li Jin <ic...@gmail.com> 于2023年9月6日周三 23:56写道：
> Hello,
>
> I have been testing "What is the max rss needed to scan through ~100G of
> data in a parquet stored in gcs using Arrow C++".
>
> The current answer is about ~6G of memory which seems a bit high so I
> looked into it. What I observed during the process led me to think that
> there are some potential cache/memory issues in the dataset/parquet cpp
> code.
>
> Main observation:
> (1) As I am scanning through the dataset, I printed out (a) memory
> allocated by the memory pool from ScanOptions (b) process rss. I found that
> while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> increasing during the scan (looks linear to the number of files scanned).
> (2) I tested ScanNode in Arrow as well as an in-house library that
> implements its own "S3Dataset" similar to Arrow dataset, both showing
> similar rss usage. (Which led me to think the issue is more likely to be in
> the parquet cpp code instead of dataset code).
> (3) Scan the same dataset twice in the same process doesn't increase the
> max rss.
>
> I plan to look into the parquet cpp/dataset code but I wonder if someone
> has some clues what the issue might be or where to look at?
>
> Thanks,
> Li
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Antoine Pitrou <an...@python.org>.
Hi Li,
Le 06/09/2023 à 17:55, Li Jin a écrit :
> Hello,
>
> I have been testing "What is the max rss needed to scan through ~100G of
> data in a parquet stored in gcs using Arrow C++".
>
> The current answer is about ~6G of memory which seems a bit high so I
> looked into it. What I observed during the process led me to think that
> there are some potential cache/memory issues in the dataset/parquet cpp
> code.
>
> Main observation:
> (1) As I am scanning through the dataset, I printed out (a) memory
> allocated by the memory pool from ScanOptions (b) process rss. I found that
> while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> increasing during the scan (looks linear to the number of files scanned).
RSS is typically not a very reliable indicator, because allocators tend
to keep memory around as an allocation cache even if the application
code deallocated it.
(in other words: the application returns memory to the allocator, but
the allocator does not always return memory to the OS, because
requesting memory from the OS is expensive)
You may start by trying a different memory pool (see
https://arrow.apache.org/docs/cpp/env_vars.html#envvar-ARROW_DEFAULT_MEMORY_POOL
for an easy way to do that).
My second suggestion is to ask the memory pool to release more memory:
https://arrow.apache.org/docs/cpp/api/memory.html#_CPPv4N5arrow10MemoryPool13ReleaseUnusedEv
If either of these two fix the apparent RSS issue, then there is no leak
nor caching issue.
*However*, in addition to the Arrow memory pool, many small or
medium-sized allocations (such as all Parquet Thrift metadata) will use
the system allocator. These allocations will evade tracking by the
memory pool.
Which leads to the question: what is your OS?
Regards
Antoine.
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Sorry I realized my previous email might have the wrong format. Resending
with correct format.
Update:
I have done a memory profiling and the result seems to suggest memory leak.
I
have opened a issue to further discuss this:
https://github.com/apache/arrow/issues/37630
On Fri, Sep 8, 2023 at 10:07 AM Li Jin <ic...@gmail.com> wrote:
> Update:
>
> I have done a memory profiling and the result seems to suggest memory
> leak. I
> have opened a issue to further discuss this:
> https://github.com/apache/arrow/issues/37630
>
>
> On Fri, Sep 8, 2023 at 10:04 AM Li Jin <ic...@gmail.com> wrote:
>
>> Update:
>>
>> I have done a memory profiling and the result seems to suggest memory
>> leak. I
>> have opened a issue to further discuss this:
>> https://github.com/apache/arrow/issues/37630
>>
>> Attaching the memory profiling result here as well:
>>
>> On Wed, Sep 6, 2023 at 9:18 PM Gang Wu <us...@gmail.com> wrote:
>>
>>> As suggested from other comments, I also highly recommend using a
>>> heap profiling tool to investigate what's going on there.
>>>
>>> BTW, 800 columns look suspicious to me. Could you try to test them
>>> without reading any batch? Not sure if the file metadata is the root
>>> cause. Or you may want to try another dataset with a smaller number
>>> of columns.
>>>
>>> On Thu, Sep 7, 2023 at 5:45 AM Li Jin <ic...@gmail.com> wrote:
>>>
>>> > Correction:
>>> >
>>> > > I tried with both Antione's suggestions (swapping the default
>>> allocator
>>> > and calls ReleaseUnused but neither seem to affect the max rss.
>>> >
>>> > Calling ReleaseUnused does have some effect on the rss - the max rss
>>> goes
>>> > from ~6G -> 5G but still there seems to be something else.
>>> >
>>> > On Wed, Sep 6, 2023 at 4:35 PM Li Jin <ic...@gmail.com> wrote:
>>> >
>>> > > Also attaching my experiment code just in case:
>>> > > https://gist.github.com/icexelloss/88195de046962e1d043c99d96e1b8b43
>>> > >
>>> > > On Wed, Sep 6, 2023 at 4:29 PM Li Jin <ic...@gmail.com> wrote:
>>> > >
>>> > >> Reporting back with some new findings.
>>> > >>
>>> > >> Re Felipe and Antione:
>>> > >> I tried with both Antione's suggestions (swapping the default
>>> allocator
>>> > >> and calls ReleaseUnused but neither seem to affect the max rss. In
>>> > >> addition, I manage to repro the issue by reading a list of n local
>>> > parquet
>>> > >> files that point to the same file, i.e., {"a.parquet", "a.parquet",
>>> ...
>>> > }.
>>> > >> I am also able to crash my process by reading and passing a large
>>> > enough n.
>>> > >> (I observed rss keep going up and eventually the process gets
>>> killed).
>>> > This
>>> > >> observation led me to think there might actually be some memory leak
>>> > issues.
>>> > >>
>>> > >> Re Xuwei:
>>> > >> Thanks for the tips. I am gonna try to memorize this profile next
>>> and
>>> > see
>>> > >> what I can find.
>>> > >>
>>> > >> I am gonna keep looking into this but again, any ideas /
>>> suggestions are
>>> > >> appreciated (and thanks for all the help so far!)
>>> > >>
>>> > >> Li
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com>
>>> wrote:
>>> > >>
>>> > >>> Thanks all for the additional suggestions. Will try it but want to
>>> > >>> answer Antoine's question first:
>>> > >>>
>>> > >>> > Which leads to the question: what is your OS?
>>> > >>>
>>> > >>> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
>>> > >>>
>>> > >>> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com>
>>> > >>> wrote:
>>> > >>>
>>> > >>>> By the way, you can try to use a memory-profiler like [1] and [2]
>>> .
>>> > >>>> It would be help to find how the memory is used
>>> > >>>>
>>> > >>>> Best,
>>> > >>>> Xuwei Fu
>>> > >>>>
>>> > >>>> [1]
>>> > >>>>
>>> https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
>>> > >>>> [2] https://google.github.io/tcmalloc/gperftools.html
>>> > >>>>
>>> > >>>>
>>> > >>>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四
>>> 00:28写道：
>>> > >>>>
>>> > >>>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b)
>>> > keeps
>>> > >>>> > increasing during the scan (looks linear to the number of files
>>> > >>>> scanned).
>>> > >>>> >
>>> > >>>> > I wouldn't take this to mean a memory leak but the memory
>>> allocator
>>> > >>>> not
>>> > >>>> > paging out virtual memory that has been allocated throughout the
>>> > scan.
>>> > >>>> > Could you run your workload under a memory profiler?
>>> > >>>> >
>>> > >>>> > (3) Scan the same dataset twice in the same process doesn't
>>> increase
>>> > >>>> the
>>> > >>>> > max rss.
>>> > >>>> >
>>> > >>>> > Another sign this isn't a leak, just the allocator reaching a
>>> level
>>> > of
>>> > >>>> > memory commitment that it doesn't feel like undoing.
>>> > >>>> >
>>> > >>>> > --
>>> > >>>> > Felipe
>>> > >>>> >
>>> > >>>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com>
>>> > wrote:
>>> > >>>> >
>>> > >>>> > > Hello,
>>> > >>>> > >
>>> > >>>> > > I have been testing "What is the max rss needed to scan
>>> through
>>> > >>>> ~100G of
>>> > >>>> > > data in a parquet stored in gcs using Arrow C++".
>>> > >>>> > >
>>> > >>>> > > The current answer is about ~6G of memory which seems a bit
>>> high
>>> > so
>>> > >>>> I
>>> > >>>> > > looked into it. What I observed during the process led me to
>>> think
>>> > >>>> that
>>> > >>>> > > there are some potential cache/memory issues in the
>>> > dataset/parquet
>>> > >>>> cpp
>>> > >>>> > > code.
>>> > >>>> > >
>>> > >>>> > > Main observation:
>>> > >>>> > > (1) As I am scanning through the dataset, I printed out (a)
>>> memory
>>> > >>>> > > allocated by the memory pool from ScanOptions (b) process
>>> rss. I
>>> > >>>> found
>>> > >>>> > that
>>> > >>>> > > while (a) stays pretty stable throughout the scan (stays <
>>> 1G),
>>> > (b)
>>> > >>>> keeps
>>> > >>>> > > increasing during the scan (looks linear to the number of
>>> files
>>> > >>>> scanned).
>>> > >>>> > > (2) I tested ScanNode in Arrow as well as an in-house library
>>> that
>>> > >>>> > > implements its own "S3Dataset" similar to Arrow dataset, both
>>> > >>>> showing
>>> > >>>> > > similar rss usage. (Which led me to think the issue is more
>>> likely
>>> > >>>> to be
>>> > >>>> > in
>>> > >>>> > > the parquet cpp code instead of dataset code).
>>> > >>>> > > (3) Scan the same dataset twice in the same process doesn't
>>> > >>>> increase the
>>> > >>>> > > max rss.
>>> > >>>> > >
>>> > >>>> > > I plan to look into the parquet cpp/dataset code but I wonder
>>> if
>>> > >>>> someone
>>> > >>>> > > has some clues what the issue might be or where to look at?
>>> > >>>> > >
>>> > >>>> > > Thanks,
>>> > >>>> > > Li
>>> > >>>> > >
>>> > >>>> >
>>> > >>>>
>>> > >>>
>>> >
>>>
>>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Update:
I have done a memory profiling and the result seems to suggest memory leak.
I
have opened a issue to further discuss this:
https://github.com/apache/arrow/issues/37630
On Fri, Sep 8, 2023 at 10:04 AM Li Jin <ic...@gmail.com> wrote:
> Update:
>
> I have done a memory profiling and the result seems to suggest memory
> leak. I
> have opened a issue to further discuss this:
> https://github.com/apache/arrow/issues/37630
>
> Attaching the memory profiling result here as well:
>
> On Wed, Sep 6, 2023 at 9:18 PM Gang Wu <us...@gmail.com> wrote:
>
>> As suggested from other comments, I also highly recommend using a
>> heap profiling tool to investigate what's going on there.
>>
>> BTW, 800 columns look suspicious to me. Could you try to test them
>> without reading any batch? Not sure if the file metadata is the root
>> cause. Or you may want to try another dataset with a smaller number
>> of columns.
>>
>> On Thu, Sep 7, 2023 at 5:45 AM Li Jin <ic...@gmail.com> wrote:
>>
>> > Correction:
>> >
>> > > I tried with both Antione's suggestions (swapping the default
>> allocator
>> > and calls ReleaseUnused but neither seem to affect the max rss.
>> >
>> > Calling ReleaseUnused does have some effect on the rss - the max rss
>> goes
>> > from ~6G -> 5G but still there seems to be something else.
>> >
>> > On Wed, Sep 6, 2023 at 4:35 PM Li Jin <ic...@gmail.com> wrote:
>> >
>> > > Also attaching my experiment code just in case:
>> > > https://gist.github.com/icexelloss/88195de046962e1d043c99d96e1b8b43
>> > >
>> > > On Wed, Sep 6, 2023 at 4:29 PM Li Jin <ic...@gmail.com> wrote:
>> > >
>> > >> Reporting back with some new findings.
>> > >>
>> > >> Re Felipe and Antione:
>> > >> I tried with both Antione's suggestions (swapping the default
>> allocator
>> > >> and calls ReleaseUnused but neither seem to affect the max rss. In
>> > >> addition, I manage to repro the issue by reading a list of n local
>> > parquet
>> > >> files that point to the same file, i.e., {"a.parquet", "a.parquet",
>> ...
>> > }.
>> > >> I am also able to crash my process by reading and passing a large
>> > enough n.
>> > >> (I observed rss keep going up and eventually the process gets
>> killed).
>> > This
>> > >> observation led me to think there might actually be some memory leak
>> > issues.
>> > >>
>> > >> Re Xuwei:
>> > >> Thanks for the tips. I am gonna try to memorize this profile next and
>> > see
>> > >> what I can find.
>> > >>
>> > >> I am gonna keep looking into this but again, any ideas / suggestions
>> are
>> > >> appreciated (and thanks for all the help so far!)
>> > >>
>> > >> Li
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com> wrote:
>> > >>
>> > >>> Thanks all for the additional suggestions. Will try it but want to
>> > >>> answer Antoine's question first:
>> > >>>
>> > >>> > Which leads to the question: what is your OS?
>> > >>>
>> > >>> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
>> > >>>
>> > >>> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>>> By the way, you can try to use a memory-profiler like [1] and [2] .
>> > >>>> It would be help to find how the memory is used
>> > >>>>
>> > >>>> Best,
>> > >>>> Xuwei Fu
>> > >>>>
>> > >>>> [1]
>> > >>>>
>> https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
>> > >>>> [2] https://google.github.io/tcmalloc/gperftools.html
>> > >>>>
>> > >>>>
>> > >>>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四
>> 00:28写道：
>> > >>>>
>> > >>>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b)
>> > keeps
>> > >>>> > increasing during the scan (looks linear to the number of files
>> > >>>> scanned).
>> > >>>> >
>> > >>>> > I wouldn't take this to mean a memory leak but the memory
>> allocator
>> > >>>> not
>> > >>>> > paging out virtual memory that has been allocated throughout the
>> > scan.
>> > >>>> > Could you run your workload under a memory profiler?
>> > >>>> >
>> > >>>> > (3) Scan the same dataset twice in the same process doesn't
>> increase
>> > >>>> the
>> > >>>> > max rss.
>> > >>>> >
>> > >>>> > Another sign this isn't a leak, just the allocator reaching a
>> level
>> > of
>> > >>>> > memory commitment that it doesn't feel like undoing.
>> > >>>> >
>> > >>>> > --
>> > >>>> > Felipe
>> > >>>> >
>> > >>>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com>
>> > wrote:
>> > >>>> >
>> > >>>> > > Hello,
>> > >>>> > >
>> > >>>> > > I have been testing "What is the max rss needed to scan through
>> > >>>> ~100G of
>> > >>>> > > data in a parquet stored in gcs using Arrow C++".
>> > >>>> > >
>> > >>>> > > The current answer is about ~6G of memory which seems a bit
>> high
>> > so
>> > >>>> I
>> > >>>> > > looked into it. What I observed during the process led me to
>> think
>> > >>>> that
>> > >>>> > > there are some potential cache/memory issues in the
>> > dataset/parquet
>> > >>>> cpp
>> > >>>> > > code.
>> > >>>> > >
>> > >>>> > > Main observation:
>> > >>>> > > (1) As I am scanning through the dataset, I printed out (a)
>> memory
>> > >>>> > > allocated by the memory pool from ScanOptions (b) process rss.
>> I
>> > >>>> found
>> > >>>> > that
>> > >>>> > > while (a) stays pretty stable throughout the scan (stays < 1G),
>> > (b)
>> > >>>> keeps
>> > >>>> > > increasing during the scan (looks linear to the number of files
>> > >>>> scanned).
>> > >>>> > > (2) I tested ScanNode in Arrow as well as an in-house library
>> that
>> > >>>> > > implements its own "S3Dataset" similar to Arrow dataset, both
>> > >>>> showing
>> > >>>> > > similar rss usage. (Which led me to think the issue is more
>> likely
>> > >>>> to be
>> > >>>> > in
>> > >>>> > > the parquet cpp code instead of dataset code).
>> > >>>> > > (3) Scan the same dataset twice in the same process doesn't
>> > >>>> increase the
>> > >>>> > > max rss.
>> > >>>> > >
>> > >>>> > > I plan to look into the parquet cpp/dataset code but I wonder
>> if
>> > >>>> someone
>> > >>>> > > has some clues what the issue might be or where to look at?
>> > >>>> > >
>> > >>>> > > Thanks,
>> > >>>> > > Li
>> > >>>> > >
>> > >>>> >
>> > >>>>
>> > >>>
>> >
>>
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Gang Wu <us...@gmail.com>.
As suggested from other comments, I also highly recommend using a
heap profiling tool to investigate what's going on there.
BTW, 800 columns look suspicious to me. Could you try to test them
without reading any batch? Not sure if the file metadata is the root
cause. Or you may want to try another dataset with a smaller number
of columns.
On Thu, Sep 7, 2023 at 5:45 AM Li Jin <ic...@gmail.com> wrote:
> Correction:
>
> > I tried with both Antione's suggestions (swapping the default allocator
> and calls ReleaseUnused but neither seem to affect the max rss.
>
> Calling ReleaseUnused does have some effect on the rss - the max rss goes
> from ~6G -> 5G but still there seems to be something else.
>
> On Wed, Sep 6, 2023 at 4:35 PM Li Jin <ic...@gmail.com> wrote:
>
> > Also attaching my experiment code just in case:
> > https://gist.github.com/icexelloss/88195de046962e1d043c99d96e1b8b43
> >
> > On Wed, Sep 6, 2023 at 4:29 PM Li Jin <ic...@gmail.com> wrote:
> >
> >> Reporting back with some new findings.
> >>
> >> Re Felipe and Antione:
> >> I tried with both Antione's suggestions (swapping the default allocator
> >> and calls ReleaseUnused but neither seem to affect the max rss. In
> >> addition, I manage to repro the issue by reading a list of n local
> parquet
> >> files that point to the same file, i.e., {"a.parquet", "a.parquet", ...
> }.
> >> I am also able to crash my process by reading and passing a large
> enough n.
> >> (I observed rss keep going up and eventually the process gets killed).
> This
> >> observation led me to think there might actually be some memory leak
> issues.
> >>
> >> Re Xuwei:
> >> Thanks for the tips. I am gonna try to memorize this profile next and
> see
> >> what I can find.
> >>
> >> I am gonna keep looking into this but again, any ideas / suggestions are
> >> appreciated (and thanks for all the help so far!)
> >>
> >> Li
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com> wrote:
> >>
> >>> Thanks all for the additional suggestions. Will try it but want to
> >>> answer Antoine's question first:
> >>>
> >>> > Which leads to the question: what is your OS?
> >>>
> >>> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
> >>>
> >>> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com>
> >>> wrote:
> >>>
> >>>> By the way, you can try to use a memory-profiler like [1] and [2] .
> >>>> It would be help to find how the memory is used
> >>>>
> >>>> Best,
> >>>> Xuwei Fu
> >>>>
> >>>> [1]
> >>>> https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
> >>>> [2] https://google.github.io/tcmalloc/gperftools.html
> >>>>
> >>>>
> >>>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
> >>>>
> >>>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b)
> keeps
> >>>> > increasing during the scan (looks linear to the number of files
> >>>> scanned).
> >>>> >
> >>>> > I wouldn't take this to mean a memory leak but the memory allocator
> >>>> not
> >>>> > paging out virtual memory that has been allocated throughout the
> scan.
> >>>> > Could you run your workload under a memory profiler?
> >>>> >
> >>>> > (3) Scan the same dataset twice in the same process doesn't increase
> >>>> the
> >>>> > max rss.
> >>>> >
> >>>> > Another sign this isn't a leak, just the allocator reaching a level
> of
> >>>> > memory commitment that it doesn't feel like undoing.
> >>>> >
> >>>> > --
> >>>> > Felipe
> >>>> >
> >>>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com>
> wrote:
> >>>> >
> >>>> > > Hello,
> >>>> > >
> >>>> > > I have been testing "What is the max rss needed to scan through
> >>>> ~100G of
> >>>> > > data in a parquet stored in gcs using Arrow C++".
> >>>> > >
> >>>> > > The current answer is about ~6G of memory which seems a bit high
> so
> >>>> I
> >>>> > > looked into it. What I observed during the process led me to think
> >>>> that
> >>>> > > there are some potential cache/memory issues in the
> dataset/parquet
> >>>> cpp
> >>>> > > code.
> >>>> > >
> >>>> > > Main observation:
> >>>> > > (1) As I am scanning through the dataset, I printed out (a) memory
> >>>> > > allocated by the memory pool from ScanOptions (b) process rss. I
> >>>> found
> >>>> > that
> >>>> > > while (a) stays pretty stable throughout the scan (stays < 1G),
> (b)
> >>>> keeps
> >>>> > > increasing during the scan (looks linear to the number of files
> >>>> scanned).
> >>>> > > (2) I tested ScanNode in Arrow as well as an in-house library that
> >>>> > > implements its own "S3Dataset" similar to Arrow dataset, both
> >>>> showing
> >>>> > > similar rss usage. (Which led me to think the issue is more likely
> >>>> to be
> >>>> > in
> >>>> > > the parquet cpp code instead of dataset code).
> >>>> > > (3) Scan the same dataset twice in the same process doesn't
> >>>> increase the
> >>>> > > max rss.
> >>>> > >
> >>>> > > I plan to look into the parquet cpp/dataset code but I wonder if
> >>>> someone
> >>>> > > has some clues what the issue might be or where to look at?
> >>>> > >
> >>>> > > Thanks,
> >>>> > > Li
> >>>> > >
> >>>> >
> >>>>
> >>>
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Correction:
> I tried with both Antione's suggestions (swapping the default allocator
and calls ReleaseUnused but neither seem to affect the max rss.
Calling ReleaseUnused does have some effect on the rss - the max rss goes
from ~6G -> 5G but still there seems to be something else.
On Wed, Sep 6, 2023 at 4:35 PM Li Jin <ic...@gmail.com> wrote:
> Also attaching my experiment code just in case:
> https://gist.github.com/icexelloss/88195de046962e1d043c99d96e1b8b43
>
> On Wed, Sep 6, 2023 at 4:29 PM Li Jin <ic...@gmail.com> wrote:
>
>> Reporting back with some new findings.
>>
>> Re Felipe and Antione:
>> I tried with both Antione's suggestions (swapping the default allocator
>> and calls ReleaseUnused but neither seem to affect the max rss. In
>> addition, I manage to repro the issue by reading a list of n local parquet
>> files that point to the same file, i.e., {"a.parquet", "a.parquet", ... }.
>> I am also able to crash my process by reading and passing a large enough n.
>> (I observed rss keep going up and eventually the process gets killed). This
>> observation led me to think there might actually be some memory leak issues.
>>
>> Re Xuwei:
>> Thanks for the tips. I am gonna try to memorize this profile next and see
>> what I can find.
>>
>> I am gonna keep looking into this but again, any ideas / suggestions are
>> appreciated (and thanks for all the help so far!)
>>
>> Li
>>
>>
>>
>>
>>
>>
>> On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com> wrote:
>>
>>> Thanks all for the additional suggestions. Will try it but want to
>>> answer Antoine's question first:
>>>
>>> > Which leads to the question: what is your OS?
>>>
>>> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
>>>
>>> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com>
>>> wrote:
>>>
>>>> By the way, you can try to use a memory-profiler like [1] and [2] .
>>>> It would be help to find how the memory is used
>>>>
>>>> Best,
>>>> Xuwei Fu
>>>>
>>>> [1]
>>>> https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
>>>> [2] https://google.github.io/tcmalloc/gperftools.html
>>>>
>>>>
>>>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
>>>>
>>>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
>>>> > increasing during the scan (looks linear to the number of files
>>>> scanned).
>>>> >
>>>> > I wouldn't take this to mean a memory leak but the memory allocator
>>>> not
>>>> > paging out virtual memory that has been allocated throughout the scan.
>>>> > Could you run your workload under a memory profiler?
>>>> >
>>>> > (3) Scan the same dataset twice in the same process doesn't increase
>>>> the
>>>> > max rss.
>>>> >
>>>> > Another sign this isn't a leak, just the allocator reaching a level of
>>>> > memory commitment that it doesn't feel like undoing.
>>>> >
>>>> > --
>>>> > Felipe
>>>> >
>>>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
>>>> >
>>>> > > Hello,
>>>> > >
>>>> > > I have been testing "What is the max rss needed to scan through
>>>> ~100G of
>>>> > > data in a parquet stored in gcs using Arrow C++".
>>>> > >
>>>> > > The current answer is about ~6G of memory which seems a bit high so
>>>> I
>>>> > > looked into it. What I observed during the process led me to think
>>>> that
>>>> > > there are some potential cache/memory issues in the dataset/parquet
>>>> cpp
>>>> > > code.
>>>> > >
>>>> > > Main observation:
>>>> > > (1) As I am scanning through the dataset, I printed out (a) memory
>>>> > > allocated by the memory pool from ScanOptions (b) process rss. I
>>>> found
>>>> > that
>>>> > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
>>>> keeps
>>>> > > increasing during the scan (looks linear to the number of files
>>>> scanned).
>>>> > > (2) I tested ScanNode in Arrow as well as an in-house library that
>>>> > > implements its own "S3Dataset" similar to Arrow dataset, both
>>>> showing
>>>> > > similar rss usage. (Which led me to think the issue is more likely
>>>> to be
>>>> > in
>>>> > > the parquet cpp code instead of dataset code).
>>>> > > (3) Scan the same dataset twice in the same process doesn't
>>>> increase the
>>>> > > max rss.
>>>> > >
>>>> > > I plan to look into the parquet cpp/dataset code but I wonder if
>>>> someone
>>>> > > has some clues what the issue might be or where to look at?
>>>> > >
>>>> > > Thanks,
>>>> > > Li
>>>> > >
>>>> >
>>>>
>>>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Also attaching my experiment code just in case:
https://gist.github.com/icexelloss/88195de046962e1d043c99d96e1b8b43
On Wed, Sep 6, 2023 at 4:29 PM Li Jin <ic...@gmail.com> wrote:
> Reporting back with some new findings.
>
> Re Felipe and Antione:
> I tried with both Antione's suggestions (swapping the default allocator
> and calls ReleaseUnused but neither seem to affect the max rss. In
> addition, I manage to repro the issue by reading a list of n local parquet
> files that point to the same file, i.e., {"a.parquet", "a.parquet", ... }.
> I am also able to crash my process by reading and passing a large enough n.
> (I observed rss keep going up and eventually the process gets killed). This
> observation led me to think there might actually be some memory leak issues.
>
> Re Xuwei:
> Thanks for the tips. I am gonna try to memorize this profile next and see
> what I can find.
>
> I am gonna keep looking into this but again, any ideas / suggestions are
> appreciated (and thanks for all the help so far!)
>
> Li
>
>
>
>
>
>
> On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com> wrote:
>
>> Thanks all for the additional suggestions. Will try it but want to answer
>> Antoine's question first:
>>
>> > Which leads to the question: what is your OS?
>>
>> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
>>
>> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com> wrote:
>>
>>> By the way, you can try to use a memory-profiler like [1] and [2] .
>>> It would be help to find how the memory is used
>>>
>>> Best,
>>> Xuwei Fu
>>>
>>> [1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
>>> [2] https://google.github.io/tcmalloc/gperftools.html
>>>
>>>
>>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
>>>
>>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
>>> > increasing during the scan (looks linear to the number of files
>>> scanned).
>>> >
>>> > I wouldn't take this to mean a memory leak but the memory allocator not
>>> > paging out virtual memory that has been allocated throughout the scan.
>>> > Could you run your workload under a memory profiler?
>>> >
>>> > (3) Scan the same dataset twice in the same process doesn't increase
>>> the
>>> > max rss.
>>> >
>>> > Another sign this isn't a leak, just the allocator reaching a level of
>>> > memory commitment that it doesn't feel like undoing.
>>> >
>>> > --
>>> > Felipe
>>> >
>>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
>>> >
>>> > > Hello,
>>> > >
>>> > > I have been testing "What is the max rss needed to scan through
>>> ~100G of
>>> > > data in a parquet stored in gcs using Arrow C++".
>>> > >
>>> > > The current answer is about ~6G of memory which seems a bit high so I
>>> > > looked into it. What I observed during the process led me to think
>>> that
>>> > > there are some potential cache/memory issues in the dataset/parquet
>>> cpp
>>> > > code.
>>> > >
>>> > > Main observation:
>>> > > (1) As I am scanning through the dataset, I printed out (a) memory
>>> > > allocated by the memory pool from ScanOptions (b) process rss. I
>>> found
>>> > that
>>> > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
>>> keeps
>>> > > increasing during the scan (looks linear to the number of files
>>> scanned).
>>> > > (2) I tested ScanNode in Arrow as well as an in-house library that
>>> > > implements its own "S3Dataset" similar to Arrow dataset, both showing
>>> > > similar rss usage. (Which led me to think the issue is more likely
>>> to be
>>> > in
>>> > > the parquet cpp code instead of dataset code).
>>> > > (3) Scan the same dataset twice in the same process doesn't increase
>>> the
>>> > > max rss.
>>> > >
>>> > > I plan to look into the parquet cpp/dataset code but I wonder if
>>> someone
>>> > > has some clues what the issue might be or where to look at?
>>> > >
>>> > > Thanks,
>>> > > Li
>>> > >
>>> >
>>>
>>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Reporting back with some new findings.
Re Felipe and Antione:
I tried with both Antione's suggestions (swapping the default allocator and
calls ReleaseUnused but neither seem to affect the max rss. In addition, I
manage to repro the issue by reading a list of n local parquet files that
point to the same file, i.e., {"a.parquet", "a.parquet", ... }. I am also
able to crash my process by reading and passing a large enough n. (I
observed rss keep going up and eventually the process gets killed). This
observation led me to think there might actually be some memory leak issues.
Re Xuwei:
Thanks for the tips. I am gonna try to memorize this profile next and see
what I can find.
I am gonna keep looking into this but again, any ideas / suggestions are
appreciated (and thanks for all the help so far!)
Li
On Wed, Sep 6, 2023 at 1:59 PM Li Jin <ic...@gmail.com> wrote:
> Thanks all for the additional suggestions. Will try it but want to answer
> Antoine's question first:
>
> > Which leads to the question: what is your OS?
>
> I am testing this on Debian 5.4.228 x86_64 GNU/Linux
>
> On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com> wrote:
>
>> By the way, you can try to use a memory-profiler like [1] and [2] .
>> It would be help to find how the memory is used
>>
>> Best,
>> Xuwei Fu
>>
>> [1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
>> [2] https://google.github.io/tcmalloc/gperftools.html
>>
>>
>> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
>>
>> > > (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
>> > increasing during the scan (looks linear to the number of files
>> scanned).
>> >
>> > I wouldn't take this to mean a memory leak but the memory allocator not
>> > paging out virtual memory that has been allocated throughout the scan.
>> > Could you run your workload under a memory profiler?
>> >
>> > (3) Scan the same dataset twice in the same process doesn't increase the
>> > max rss.
>> >
>> > Another sign this isn't a leak, just the allocator reaching a level of
>> > memory commitment that it doesn't feel like undoing.
>> >
>> > --
>> > Felipe
>> >
>> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
>> >
>> > > Hello,
>> > >
>> > > I have been testing "What is the max rss needed to scan through ~100G
>> of
>> > > data in a parquet stored in gcs using Arrow C++".
>> > >
>> > > The current answer is about ~6G of memory which seems a bit high so I
>> > > looked into it. What I observed during the process led me to think
>> that
>> > > there are some potential cache/memory issues in the dataset/parquet
>> cpp
>> > > code.
>> > >
>> > > Main observation:
>> > > (1) As I am scanning through the dataset, I printed out (a) memory
>> > > allocated by the memory pool from ScanOptions (b) process rss. I found
>> > that
>> > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
>> keeps
>> > > increasing during the scan (looks linear to the number of files
>> scanned).
>> > > (2) I tested ScanNode in Arrow as well as an in-house library that
>> > > implements its own "S3Dataset" similar to Arrow dataset, both showing
>> > > similar rss usage. (Which led me to think the issue is more likely to
>> be
>> > in
>> > > the parquet cpp code instead of dataset code).
>> > > (3) Scan the same dataset twice in the same process doesn't increase
>> the
>> > > max rss.
>> > >
>> > > I plan to look into the parquet cpp/dataset code but I wonder if
>> someone
>> > > has some clues what the issue might be or where to look at?
>> > >
>> > > Thanks,
>> > > Li
>> > >
>> >
>>
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Li Jin <ic...@gmail.com>.
Thanks all for the additional suggestions. Will try it but want to answer
Antoine's question first:
> Which leads to the question: what is your OS?
I am testing this on Debian 5.4.228 x86_64 GNU/Linux
On Wed, Sep 6, 2023 at 1:31 PM wish maple <ma...@gmail.com> wrote:
> By the way, you can try to use a memory-profiler like [1] and [2] .
> It would be help to find how the memory is used
>
> Best,
> Xuwei Fu
>
> [1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
> [2] https://google.github.io/tcmalloc/gperftools.html
>
>
> Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
>
> > > (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> > increasing during the scan (looks linear to the number of files scanned).
> >
> > I wouldn't take this to mean a memory leak but the memory allocator not
> > paging out virtual memory that has been allocated throughout the scan.
> > Could you run your workload under a memory profiler?
> >
> > (3) Scan the same dataset twice in the same process doesn't increase the
> > max rss.
> >
> > Another sign this isn't a leak, just the allocator reaching a level of
> > memory commitment that it doesn't feel like undoing.
> >
> > --
> > Felipe
> >
> > On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I have been testing "What is the max rss needed to scan through ~100G
> of
> > > data in a parquet stored in gcs using Arrow C++".
> > >
> > > The current answer is about ~6G of memory which seems a bit high so I
> > > looked into it. What I observed during the process led me to think that
> > > there are some potential cache/memory issues in the dataset/parquet cpp
> > > code.
> > >
> > > Main observation:
> > > (1) As I am scanning through the dataset, I printed out (a) memory
> > > allocated by the memory pool from ScanOptions (b) process rss. I found
> > that
> > > while (a) stays pretty stable throughout the scan (stays < 1G), (b)
> keeps
> > > increasing during the scan (looks linear to the number of files
> scanned).
> > > (2) I tested ScanNode in Arrow as well as an in-house library that
> > > implements its own "S3Dataset" similar to Arrow dataset, both showing
> > > similar rss usage. (Which led me to think the issue is more likely to
> be
> > in
> > > the parquet cpp code instead of dataset code).
> > > (3) Scan the same dataset twice in the same process doesn't increase
> the
> > > max rss.
> > >
> > > I plan to look into the parquet cpp/dataset code but I wonder if
> someone
> > > has some clues what the issue might be or where to look at?
> > >
> > > Thanks,
> > > Li
> > >
> >
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by wish maple <ma...@gmail.com>.
By the way, you can try to use a memory-profiler like [1] and [2] .
It would be help to find how the memory is used
Best,
Xuwei Fu
[1] https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling
[2] https://google.github.io/tcmalloc/gperftools.html
Felipe Oliveira Carvalho <fe...@gmail.com> 于2023年9月7日周四 00:28写道：
> > (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> increasing during the scan (looks linear to the number of files scanned).
>
> I wouldn't take this to mean a memory leak but the memory allocator not
> paging out virtual memory that has been allocated throughout the scan.
> Could you run your workload under a memory profiler?
>
> (3) Scan the same dataset twice in the same process doesn't increase the
> max rss.
>
> Another sign this isn't a leak, just the allocator reaching a level of
> memory commitment that it doesn't feel like undoing.
>
> --
> Felipe
>
> On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
>
> > Hello,
> >
> > I have been testing "What is the max rss needed to scan through ~100G of
> > data in a parquet stored in gcs using Arrow C++".
> >
> > The current answer is about ~6G of memory which seems a bit high so I
> > looked into it. What I observed during the process led me to think that
> > there are some potential cache/memory issues in the dataset/parquet cpp
> > code.
> >
> > Main observation:
> > (1) As I am scanning through the dataset, I printed out (a) memory
> > allocated by the memory pool from ScanOptions (b) process rss. I found
> that
> > while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> > increasing during the scan (looks linear to the number of files scanned).
> > (2) I tested ScanNode in Arrow as well as an in-house library that
> > implements its own "S3Dataset" similar to Arrow dataset, both showing
> > similar rss usage. (Which led me to think the issue is more likely to be
> in
> > the parquet cpp code instead of dataset code).
> > (3) Scan the same dataset twice in the same process doesn't increase the
> > max rss.
> >
> > I plan to look into the parquet cpp/dataset code but I wonder if someone
> > has some clues what the issue might be or where to look at?
> >
> > Thanks,
> > Li
> >
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Felipe Oliveira Carvalho <fe...@gmail.com>.
> (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
increasing during the scan (looks linear to the number of files scanned).
I wouldn't take this to mean a memory leak but the memory allocator not
paging out virtual memory that has been allocated throughout the scan.
Could you run your workload under a memory profiler?
(3) Scan the same dataset twice in the same process doesn't increase the
max rss.
Another sign this isn't a leak, just the allocator reaching a level of
memory commitment that it doesn't feel like undoing.
--
Felipe
On Wed, Sep 6, 2023 at 12:56 PM Li Jin <ic...@gmail.com> wrote:
> Hello,
>
> I have been testing "What is the max rss needed to scan through ~100G of
> data in a parquet stored in gcs using Arrow C++".
>
> The current answer is about ~6G of memory which seems a bit high so I
> looked into it. What I observed during the process led me to think that
> there are some potential cache/memory issues in the dataset/parquet cpp
> code.
>
> Main observation:
> (1) As I am scanning through the dataset, I printed out (a) memory
> allocated by the memory pool from ScanOptions (b) process rss. I found that
> while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> increasing during the scan (looks linear to the number of files scanned).
> (2) I tested ScanNode in Arrow as well as an in-house library that
> implements its own "S3Dataset" similar to Arrow dataset, both showing
> similar rss usage. (Which led me to think the issue is more likely to be in
> the parquet cpp code instead of dataset code).
> (3) Scan the same dataset twice in the same process doesn't increase the
> max rss.
>
> I plan to look into the parquet cpp/dataset code but I wonder if someone
> has some clues what the issue might be or where to look at?
>
> Thanks,
> Li
>
Re: [C++] Potential cache/memory leak when reading parquet
Posted by Gang Wu <us...@gmail.com>.
Hi Jin,
Do you have more information about the parquet file? What came to
my mind is this issue: https://github.com/apache/arrow/issues/35393
If you have observed something, please feel free to create a new issue
and post what you have found there.
Thanks,
Gang
On Wed, Sep 6, 2023 at 11:56 PM Li Jin <ic...@gmail.com> wrote:
> Hello,
>
> I have been testing "What is the max rss needed to scan through ~100G of
> data in a parquet stored in gcs using Arrow C++".
>
> The current answer is about ~6G of memory which seems a bit high so I
> looked into it. What I observed during the process led me to think that
> there are some potential cache/memory issues in the dataset/parquet cpp
> code.
>
> Main observation:
> (1) As I am scanning through the dataset, I printed out (a) memory
> allocated by the memory pool from ScanOptions (b) process rss. I found that
> while (a) stays pretty stable throughout the scan (stays < 1G), (b) keeps
> increasing during the scan (looks linear to the number of files scanned).
> (2) I tested ScanNode in Arrow as well as an in-house library that
> implements its own "S3Dataset" similar to Arrow dataset, both showing
> similar rss usage. (Which led me to think the issue is more likely to be in
> the parquet cpp code instead of dataset code).
> (3) Scan the same dataset twice in the same process doesn't increase the
> max rss.
>
> I plan to look into the parquet cpp/dataset code but I wonder if someone
> has some clues what the issue might be or where to look at?
>
> Thanks,
> Li
>