【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.4
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
直接使用700G的大文件做旁路导入报了超时,切分成100个小文件依次load,速度越来越慢,一开始可能3-4分钟1个文件,到最后单个文件耗时1小时左右
@论坛小助手
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.4
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
直接使用700G的大文件做旁路导入报了超时,切分成100个小文件依次load,速度越来越慢,一开始可能3-4分钟1个文件,到最后单个文件耗时1小时左右
@论坛小助手
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试,在发帖时输入 [@论坛小助手] 即可召唤小助手,欢迎试用!
根据文档库中的信息,旁路导入的效率受多种因素影响,包括但不限于数据量大小、硬件资源配置、网络状况等。针对您提到的情况,这里有几个可能的原因和建议:
数据量过大:您提到的数据量为700GB,这确实是一个非常大的数据量。根据文档片段4中的描述,当导入的数据量小于Memtable时,旁路导入没有优势。因此,对于如此大的数据量,旁路导入的优势可能没有完全发挥出来。此外,文档片段8中提到,如果数据文件大小为TB以上,建议使用旁路导入以提高效率。虽然您的数据量接近这个阈值,但仍然需要注意其他因素的影响。
硬件资源配置:文档片段4中提到,全量旁路导入适用于CPU和内存都不是特别充裕的场景。如果您的测试环境中CPU和内存资源较为充足,那么旁路导入的效率可能会受到影响。建议检查测试环境的硬件资源配置,确保有足够的资源支持高效的数据导入。
网络状况:旁路导入通过连接RPC端口进行数据传输,网络状况对导入效率有很大影响。如果网络带宽较低或者网络延迟较高,都会导致导入速度变慢。建议检查网络状况,确保网络连接稳定且带宽足够。
数据文件切分:您提到将700GB的大文件切分成100个小文件进行导入,速度逐渐变慢。这可能是由于随着导入过程的进行,系统资源逐渐紧张,导致后续文件的导入速度变慢。建议尝试调整切分后的文件大小,找到一个合适的平衡点,既不会因为文件过大而导致导入效率低下,也不会因为文件过小而频繁切换文件导致额外的开销。
并行度设置:文档片段8中提到,可以通过增加并行度来提高导入效率。您可以尝试调整--thread
参数和--parallel
参数的值,以充分利用多核CPU的计算能力,提高导入速度。
综上所述,700GB的大表旁路导入耗时3天确实较长,但考虑到数据量巨大、硬件资源配置、网络状况等因素,这种情况并非完全不合理。建议您根据上述建议进行优化,以提高导入效率。如果问题依然存在,建议联系OceanBase的技术支持团队获取进一步的帮助。
检索到的文档如下:
可以参考小助手的建议排查下,加并行试下呢,例如
obclient [test]> LOAD DATA /*+direct(true,1024) parallel(32) */ INFILE '/backup/csv/bmsql_order_line.csv' INTO TABLE bmsql_order_line FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';
我的语句和这个类似
LOAD DATA /*+direct(false,1024,full) parallel(64) */ INFILE ‘/backup/csv/bmsql_order_line.csv’ INTO TABLE bmsql_order_line FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘"’ LINES TERMINATED BY ‘\n’;
根据您提供的 LOAD DATA
语句和文档中的信息,我们可以分析一下可能导致导入效率低下的几个原因,并提出相应的优化建议。
并行度设置:
PARALLEL(64)
,这表示使用64个线程并行加载数据。根据文档片段2,PARALLEL
的建议取值范围是 0 到租户的最大 CPU 数。如果您的测试环境中 CPU 核数较少,设置过高的并行度可能会导致资源竞争,反而降低效率。PARALLEL
的值。例如,如果您的 CPU 核数为 32,可以尝试将 PARALLEL
设置为 32 或更低。数据文件切分:
Hint 设置:
direct(false, 1024, full)
,这表示使用直接路径加载数据,但不启用旁路导入。根据文档片段9,旁路导入通过并行处理技术优化 LOAD DATA
的数据导入速率。如果您的表没有主键,数据写入顺序可能与原文件中的顺序不同。direct
设置为 true
,例如:direct(true, 1024, full)
。硬件资源配置:
网络状况:
调整并行度:
LOAD DATA /*+direct(true, 1024, full) parallel(32) */ INFILE '/backup/csv/bmsql_order_line.csv' INTO TABLE bmsql_order_line FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';
将 PARALLEL
调整为与 CPU 核数相匹配的值。
调整数据文件大小:
启用旁路导入:
direct
设置为 true
,启用旁路导入。监控系统资源:
top
、iostat
、vmstat
等)监控 CPU、内存和磁盘 I/O 的使用情况,确保资源充足。检查网络状况:
ping
和 iperf
等工具检查网络带宽和延迟。根据文档库中的信息,700GB的大表旁路导入耗时3天确实较长,但考虑到数据量巨大、硬件资源配置、网络状况等因素,这种情况并非完全不合理。建议您根据上述优化建议进行调整,以提高导入效率。如果问题依然存在,建议联系OceanBase的技术支持团队获取进一步的帮助。
更多信息请查看:
(小助手的答复已结束,如未能解决您的问题,请继续提问并等待其他同学的回复,谢谢!)
看样子你应该是分了多次执行旁路导入,目前旁路导入的hint里面如果指定full的话,表示全量旁路导入,全量旁路导入的逻辑里面,每次都会带上已有的数据重新排序后,再整体写入,所以会越往后越慢。
要绕的话有两个办法:
或者使用obloader完成全量旁路导入,应该会更稳定一些