- 一. DataX优化概述
- 1.1 网络带宽等硬件因素困扰
- 1.2 DataX本身的参数调优
- 1.2.1 全局
- 1.2.2 局部
- 1.2.3 Jvm 调优
- 二.DataX优化案例
- 2.1 mysql表切分
- 参考:
当觉得DataX传输速度慢时,需要从上述四个方面着手开始排查。
- 网络本身的带宽等硬件因素造成的影响;
- DataX本身的参数;
- 从源端到任务机;
- 从任务机到目的端;
此部分主要需要了解网络本身的情况,即从源端到目的端的带宽是多少(实际带宽计算公式),平时使用量和繁忙程度的情况,从而分析是否是本部分造成的速度缓慢。
以下提供几个思路。
- 可使用从源端到目的端scp,python http,nethogs等观察实际网络及网卡速度;
- 结合监控观察任务运行时间段时,网络整体的繁忙情况,来判断是否应将任务避开网络高峰运行;
- 观察任务机的负载情况,尤其是网络和磁盘IO,观察其是否成为瓶颈,影响了速度;
datax 安装目录的conf 目录下的 core.json 文件。
{ "core":{ "transport":{ "channel":{ "speed":{ "channel": 2, ## 此处为数据导入的并发度,建议根据服务器硬件进行调优 "record":-1, ##此处解除对读取行数的限制 "byte":-1, ##此处解除对字节的限制 "batchSize":2048 ##每次读取batch的大小 } } } }, "job":{ ... } }1.2.2 局部
实际运行每个人物的json配置文件
"setting": { "speed": { "channel": 2, "record":-1, "byte":-1, "batchSize":2048 } } } }
channel增大,为防止OOM,需要修改datax工具的datax.py文件。
如下所示,可根据任务机的实际配置,提升-Xms与-Xmx,来防止OOM。
tunnel并不是越大越好,过分大反而会影响宿主机的性能。
DEFAULT_JVM = “-Xms1g -Xmx1g -XX:+HeapDumponOutOfMemoryError -XX:HeapDumpPath=%s/log” % (DATAX_HOME)
python datax.py --jvm="-Xms3G -Xmx3G" ../job/test.json
-Xms3G 表示JVM的初始值为3G
-Xmx3G 表示JVM可使用的最大值为3G
这样做的好处是给定一个大的内存,让同步数据处理起来更快。
也可以避免内存的抖动。
如果源端是mysql的话,可以使用mysql的切分,并行处理。
{ "reader": { "name": "mysqlreader", "parameter": { "username": "root", "password": "abc123", "column": [ "id", "sale_date", "prod_name", "sale_nums" ], "splitPk": "id", "connection": [ { "table": [ "fact_sale" ], "jdbcUrl": [ "jdbc:mysql://10.31.1.122:3306/test" ] } ] } },
可以看到日志里面根据spilit进行切分了
[15:14:00] 2021-11-24 15:14:08.179 [job-0] INFO JobContainer - jobContainer starts to do split ... [15:14:00] 2021-11-24 15:14:08.179 [job-0] INFO JobContainer - Job set Channel-Number to 2 channels. [15:14:00] 2021-11-24 15:14:08.194 [job-0] INFO SingleTableSplitUtil - split pk [sql=SELECt MIN(id),MAX(id) FROM fact_sale] is running... [15:14:00] 2021-11-24 15:14:08.219 [job-0] INFO SingleTableSplitUtil - After split(), allQuerySql=[ [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (1 <= id AND id < 78762161) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (78762161 <= id AND id < 157524321) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (157524321 <= id AND id < 236286481) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (236286481 <= id AND id < 315048641) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (315048641 <= id AND id < 393810801) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (393810801 <= id AND id < 472572961) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (472572961 <= id AND id < 551335120) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (551335120 <= id AND id < 630097279) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (630097279 <= id AND id < 708859438) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where (708859438 <= id AND id <= 787621597) [15:14:00] select id,sale_date,prod_name,sale_nums from fact_sale where id IS NULL [15:14:00] ].参考:
- https://www.cnblogs.com/hit-zb/p/10940849.html
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)