High Memory Usage and Long GC Times When Writing Parquet Files
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- java
调研方向
从 ExampleParquetWriter.builder 入口开始,跟踪报告中的 InternalParquetRecordWriter → ColumnWriterV1 → FallbackValuesWriter → PlainDoubleDictionaryValuesWriter → IntList 链。将现有的行数和 row group 设置与并发写入场景进行比较。Done 应确定一种受支持的方式来减少内存和 GC 开销,或清楚记录为什么 schema 相关对象无法在线程之间共享。
由索引模型根据 Issue 内容生成。
描述
Describe the usage question you have. Please include as many useful details as possible.
In my project, I am using the following code to write Parquet files to the server:
ParquetWriter parquetWriter = ExampleParquetWriter.builder(new Path(filePath))
.withConf(new Configuration())
.withType(messageType)
.build();
Each Parquet file contains 30000 columns. This code is executed by multiple threads simultaneously, which results in increased GC time. Upon analyzing memory usage, I found that the main memory consumers are related to the following chain:
InternalParquetRecordWriter -> ColumnWriterV1 -> FallbackValuesWriter -> PlainDoubleDictionaryValuesWriter -> IntList
Each thread writes to a file with the same table schema (header), differing only in the filePath.
I initially suspected that the memory usage was caused by the file buffer not being flushed in time. To address this, I tried configuring the writer with the following parameters:
parquetWriter = ExampleParquetWriter.builder(new Path(filePath))
.withConf(new Configuration())
.withType(messageType)
.withMinRowCountForPageSizeCheck(SpringContextUtils.getApplicationContext()
.getBean(EtlTaskProperties.class).getMinRowCountForPageSizeCheck())
.withMaxRowCountForPageSizeCheck(SpringContextUtils.getApplicationContext()
.getBean(EtlTaskProperties.class).getMaxRowCountForPageSizeCheck())
.withRowGroupSize(SpringContextUtils.getApplicationContext()
.getBean(EtlTaskProperties.class).getRowGroupSize())
.build();
However, these adjustments did not solve the issue. The program still experiences long GC pauses and excessive memory usage.
Expected Behavior
Efficient Parquet file writing with reduced GC time and optimized memory usage when multiple threads are writing files simultaneously.
Observed Behavior
• Increased GC time and excessive memory usage.
• Memory analysis indicates IntList under PlainDoubleDictionaryValuesWriter is the primary consumer of memory.
Request
What are the recommended strategies to mitigate excessive memory usage in this scenario?
Is there a way to share table schema-related objects across threads, or other optimizations to reduce memory overhead?
Please let me know if additional information is needed!
No response
- 主要语言
- Java
- 星标
- 3.1k
- 派生
- 1.6k
- 平均合并
- 6 天 16 小时
- 30 天内合并 PR
- 36
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/parquet-java 的其他 Issue
-
Type: bug
难度 2/5 1-3 小时 新手友好度 68/100
apache/parquet-java#3792 ·
-
难度 2/5 1-3 小时 新手友好度 82/100
apache/parquet-java#3767 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
apache/parquet-java#3695 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
apache/parquet-java#3667 ·
-
Type: bug
难度 2/5 1-3 小时 新手友好度 78/100
apache/parquet-java#3574 · 1 条评论 ·
查看 apache/parquet-java 的全部 Issue
相似的 Issue
-
documentation
难度 2/5 1-3 小时 新手友好度 65/100
inu-appcenter/memorIN-backend#288 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
-
frontend maui-pilot pilot-ask question
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
-
area/plugin
难度 2/5 1-3 小时 新手友好度 75/100
kestra-io/plugin-kestra#190 ·