點(diǎn)擊上方“IT那活兒”公眾號，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！??！

眾所周知，當(dāng)一個程序需要傳輸數(shù)據(jù)的時候，它肯定會想盡辦法占用掉設(shè)備的資源，但是，隨著對DataX深入使用可以發(fā)現(xiàn)，DataX并不會全力吃掉資源，所以究竟DataX是如何做到限速的？傳輸緩慢到底是限速原因還是其他原因？本文來一起探討下。

Channel類里實(shí)現(xiàn)限速：

statPush整個流程的描述：

• 判斷byteSpeed（bps）和recordSpeed（tps）是否都大于0？如果不是，則退出；
• 根據(jù)當(dāng)前的byteSpeed和設(shè)定的byteSpeed對比，求出睡眠時間（公式：currentByteSpeed * interval / this.byteSpeed- interval;）
• 根據(jù)當(dāng)前的recordSpeed和設(shè)定的recordSpeed對比，求出睡眠時間（公式：currentRecordSpeed * interval / this.recordSpeed - interval;）
• 取休眠時間最大值；
• Thread.sleep(sleepTime)來休眠；
• 實(shí)現(xiàn)限速。

首先我們知道，傳輸受兩個因素影響：

• 網(wǎng)絡(luò)本身的帶寬等硬件因素造成的影響；
• DataX本身的參數(shù)。

3.1 網(wǎng)絡(luò)本身的帶寬等硬件因素造成的影響

此部分主要需要了解網(wǎng)絡(luò)本身的情況，即從源端到目的端的帶寬是多少（實(shí)際帶寬計(jì)算公式），平時使用量和繁忙程度的情況，從而分析是否是本部分造成的速度緩慢。以下提供幾個思路：

• 可使用從源端到目的端scp，python http,nethogs等觀察實(shí)際網(wǎng)絡(luò)及網(wǎng)卡速度；
• 結(jié)合監(jiān)控觀察任務(wù)運(yùn)行時間段時，網(wǎng)絡(luò)整體的繁忙情況，來判斷是否應(yīng)將任務(wù)避開網(wǎng)絡(luò)高峰運(yùn)行；
• 觀察任務(wù)機(jī)的負(fù)載情況，尤其是網(wǎng)絡(luò)和磁盤IO，觀察其是否成為瓶頸，影響了速度。

3.2 DataX本身的參數(shù)

1）全局

Json：
{
   "core":{
        "transport":{
            "channel":{
                "speed":{
                  "channel": 2, 此處為數(shù)據(jù)導(dǎo)入的并發(fā)度，建議根據(jù)服務(wù)器硬件進(jìn)行調(diào)優(yōu)
                  "record":-1,此處解除對讀取行數(shù)的限制
                  "byte":-1,此處解除對字節(jié)的限制
                  "batchSize":204每次讀取batch的大小
                }
            }
        }
    },
    "job":{
            ...
        }
    }

2）局部

提升job內(nèi)Channel并發(fā)有三種配置方式：

• 配置全局Byte限速以及單Channel Byte限速，Channel個數(shù) = 全局Byte限速 / 單Channel Byte限速。
• 配置全局Record限速以及單Channel Record限速，Channel個數(shù) = 全局Record限速 / 單Channel Record限速。
• 直接配置Channel個數(shù)。

配置含義：

• job.setting.speed.channel : channel并發(fā)數(shù)；
• job.setting.speed.record : 全局配置channel的record限速；
• job.setting.speed.byte：全局配置channel的byte限速。

• core.transport.channel.speed.record：單channel的record限速；
• core.transport.channel.speed.byte：單channel的byte限速。

Json：
"setting": {
            "speed": {
                "channel": 2,
                "record":-1,
                "byte":-1,
                "batchSize":2048
            }
        }
    }
}

DEFAULT_JVM = "-Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=%s/log" % (DATAX_HOME)

注意事項(xiàng)：

當(dāng)提升DataX Job內(nèi)Channel并發(fā)數(shù)時，調(diào)整JVM堆參數(shù)，原因如下：

• 當(dāng)一個Job內(nèi)Channel數(shù)變多后，內(nèi)存的占用會顯著增加，因?yàn)镈ataX作為數(shù)據(jù)交換通道，在內(nèi)存中會緩存較多的數(shù)據(jù)。
• 例如Channel中會有一個Buffer，作為臨時的數(shù)據(jù)交換的緩沖區(qū)，而在部分Reader和Writer的中，也會存在一些Buffer，為了防止jvm報內(nèi)存溢出等錯誤，調(diào)大jvm的堆參數(shù)。
• 通常我們建議將內(nèi)存設(shè)置為4G或者8G，這個也可以根據(jù)實(shí)際情況來調(diào)整。
• 調(diào)整JVM xms xmx參數(shù)的兩種方式：一種是直接更改datax.py；另一種是在啟動的時候，加上對應(yīng)的參數(shù)，如下：python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" XXX.json。

Channel個數(shù)并不是越多越好，原因如下：

• Channel個數(shù)的增加，帶來的是更多的CPU消耗以及內(nèi)存消耗。
• 如果Channel并發(fā)配置過高導(dǎo)致JVM內(nèi)存不夠用，會出現(xiàn)的情況是發(fā)生頻繁的Full GC，導(dǎo)出速度會驟降，適得其反。

備注：

結(jié)語：