資訊專欄INFORMATION COLUMN
點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！
前 言
眾所周知，當一個程序需要傳輸數(shù)據(jù)的時候，它肯定會想盡辦法占用掉設備的資源，但是，隨著對DataX深入使用可以發(fā)現(xiàn)，DataX并不會全力吃掉資源，所以究竟DataX是如何做到限速的？傳輸緩慢到底是限速原因還是其他原因？本文來一起探討下。
限 速
statPush整個流程的描述：
調 優(yōu)
首先我們知道，傳輸受兩個因素影響：
此部分主要需要了解網(wǎng)絡本身的情況，即從源端到目的端的帶寬是多少（實際帶寬計算公式），平時使用量和繁忙程度的情況，從而分析是否是本部分造成的速度緩慢。以下提供幾個思路：
Json：
{
"core":{
"transport":{
"channel":{
"speed":{
"channel": 2, 此處為數(shù)據(jù)導入的并發(fā)度，建議根據(jù)服務器硬件進行調優(yōu)
"record":-1,此處解除對讀取行數(shù)的限制
"byte":-1,此處解除對字節(jié)的限制
"batchSize":204每次讀取batch的大小
}
}
}
},
"job":{
...
}
}提升job內Channel并發(fā)有三種配置方式：
配置含義：
Json：
"setting": {
"speed": {
"channel": 2,
"record":-1,
"byte":-1,
"batchSize":2048
}
}
}
}DEFAULT_JVM = "-Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=%s/log" % (DATAX_HOME)當提升DataX Job內Channel并發(fā)數(shù)時，調整JVM堆參數(shù)，原因如下：
Channel個數(shù)并不是越多越好，原因如下：
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://m.hztianpu.com/yun/129097.html
摘要：主機監(jiān)控個人認為對于主機的監(jiān)控是最重要的。在實際監(jiān)控時可以有意識地驗證這一點。另外還有兩個線程池空閑使用率小關注，最好確保它們的值都不要低于，否則說明已經(jīng)非常的繁忙。此時需要調整線程池線程數(shù)。 showImg(https://segmentfault.com/img/bVbgpkO?w=1280&h=720); 胡夕，《Apache Kafka實戰(zhàn)》作者，北航計算機碩士畢業(yè)，現(xiàn)任某互金...
摘要：與大數(shù)據(jù)體系交互上報運行統(tǒng)計數(shù)據(jù)自帶了運行結果的統(tǒng)計數(shù)據(jù)，我們希望把這些統(tǒng)計數(shù)據(jù)上報到元數(shù)據(jù)系統(tǒng)，作為的過程元數(shù)據(jù)存儲下來。基于我們的開發(fā)策略，不要把有贊元數(shù)據(jù)系統(tǒng)的嵌入源碼，而是在之外獲取，截取出打印的統(tǒng)計信息再上報。一、需求 有贊大數(shù)據(jù)技術應用的早期，我們使用 Sqoop 作為數(shù)據(jù)同步工具，滿足了 MySQL 與 Hive 之間數(shù)據(jù)同步的日常開發(fā)需求。 隨著公司業(yè)務發(fā)展，數(shù)據(jù)同步的場景越...
閱讀 4317·2023-01-11 11:02
閱讀 4848·2023-01-11 11:02
閱讀 3945·2023-01-11 11:02
閱讀 5647·2023-01-11 11:02
閱讀 5136·2023-01-11 11:02
閱讀 6467·2023-01-11 11:02
閱讀 5860·2023-01-11 11:02
閱讀 5078·2023-01-11 11:02
