這篇文章是關(guān)于LinkedIn如何用kafka作為一個中央發(fā)布-訂閱日志，在應(yīng)用程序，流處理尔苦，hadoop數(shù)據(jù)提取之間集成數(shù)據(jù)。無論如何行施，kafka日志一個好處就是廉價允坚。百萬級別的TPS都不是很大的事情。因為日志比起數(shù)據(jù)庫或者K-V存儲是更簡單的東西蛾号。我們的生產(chǎn)環(huán)境kafka集群每天每秒處理上千萬讀寫請求稠项，并且只是構(gòu)建在一個非常普通的硬件上。
接下來讓我們做一些壓測鲜结，看看kafka究竟多么牛逼展运。
Kafka in 30 seconds
為了幫助理解接下來的壓測活逆，首先讓我們大概了解一下kafka是什么，以及一些kafka工作的細節(jié)拗胜。kafka是LinkedIn開發(fā)一個分布式消息系統(tǒng)蔗候，現(xiàn)在是 Apache Software Foundation的成員之一，并且非常多的公司在使用kafka埂软。
生產(chǎn)者將記錄發(fā)送到kafka集群锈遥，集群保留這些記錄并將其交給消費者；
kafka一個最核心的概念就是topic（筆者在這里并不打算翻譯它勘畔，無論翻譯成什么都覺得變味了）所灸。生產(chǎn)者發(fā)布記錄到topic，消費者訂閱一個或多個topic咖杂。kafka的topic實際上就是一個分區(qū)后的write-ahead log庆寺。生產(chǎn)者把需要發(fā)布的記錄追加到這些日志后面。消費者訂閱它們诉字。每一個記錄都是一個K-V對懦尝，key主要用于分配記錄到日志分區(qū)。
下圖是一個簡單的示例圖壤圃，生產(chǎn)者如何寫記錄到一個擁有兩個分區(qū)的topic陵霉，以及消費者如何讀這個topic:
上圖展示了生產(chǎn)者如何追加日志到兩個分區(qū)，以及消費者讀取日志伍绳。日志中每條記錄都有一個相關(guān)的條目編號踊挠，我們把它稱為offset。消費者使用offset來描述其在每個日志中的位置冲杀。
這些分區(qū)分區(qū)在集群的各個服務(wù)器上效床。
需要注意kafka與很多消息系統(tǒng)不一樣，它的日志總是持久化权谁，當接收到消息后剩檀，會立即寫到文件系統(tǒng)。消費者讀消息時消息并不會被刪除旺芽。它的保留策略通過配置來決定沪猴。這就允許在數(shù)據(jù)使用者可能需要重新加載數(shù)據(jù)的情況下使用。并且也能節(jié)省空間采章，無論多少消費者运嗜，日志共享一份。
傳統(tǒng)的消息系統(tǒng)悯舟，常常一個消費者一個隊列担租，因此增加消費者，數(shù)據(jù)空間就會成倍增加抵怎。這使得Kafka非常適合普通消息傳遞系統(tǒng)之外的事物翩活，例如充當離線數(shù)據(jù)系統(tǒng)（如Hadoop）的管道阱洪。 這些離線系統(tǒng)可能僅作為周期性ETL周期的一部分在一定時間間隔加載，或者可能會停機幾個小時進行維護菠镇，在此期間冗荸，如果需要，Kafka能夠緩沖甚至TB量級的未消耗數(shù)據(jù)利耍。
kafka也復(fù)制日志到多臺服務(wù)器上蚌本，為了容錯。復(fù)制實現(xiàn)是kafka一個非常重要的架構(gòu)特性隘梨。和其他消息系統(tǒng)相比程癌，復(fù)制不是一種需要復(fù)雜配置的異乎尋常的插件，只能在非常特殊的情況下使用轴猎。 相反嵌莉，kafka的架構(gòu)復(fù)制被假定為默認值：我們將未復(fù)制的數(shù)據(jù)視為復(fù)制因子恰好為1的特殊情況。
生產(chǎn)者在發(fā)布包含記錄偏移量的消息時會收到確認捻脖。發(fā)送到同一個分區(qū)的第一條記錄分配的offset為0锐峭，第二條是1，以此類推可婶。消費者通過offset指定的位置消費數(shù)據(jù)沿癞，并且消費者通過周期性的提交topic（名為__consumer_offsets）從而保存代表消息位置的offset到日志中，達到持久化的目標矛渴。保存這個offset的目的是為了消費者崩潰后椎扬，其他消費者能從保存的位置繼續(xù)消費消息。
kafka簡單介紹到此為止具温，系統(tǒng)這一切都有意義蚕涤。
This Benchmark
對于此次基準測試，我喜歡遵循我稱之為“懶惰基準測試（lazy benchmarking）”的風(fēng)格铣猩。當您使用系統(tǒng)時揖铜，您通常擁有將其調(diào)整到任何特定用例的完美的專有技術(shù)。這導(dǎo)致了一種基準測試剂习，您可以將配置大幅調(diào)整到基準測試，或者更糟糕的是針對您測試的每個場景進行不同的調(diào)整较沪。我認為系統(tǒng)的真正測試不是它在完美調(diào)整時的表現(xiàn)鳞绕，而是它如何“現(xiàn)成”執(zhí)行。對于在具有數(shù)十個或數(shù)百個用例的多租戶設(shè)置中運行的系統(tǒng)尤其如此尸曼，其中針對每個用例的調(diào)優(yōu)不僅不切實際而且不可能们何。因此，我?guī)缀鯃猿质褂梅?wù)器和客戶端的默認設(shè)置控轿。我將指出我懷疑通過一點調(diào)整可以改善結(jié)果的區(qū)域冤竹，但我試圖抵制任何擺弄自己以改善結(jié)果的誘惑拂封。
配置和壓測命令文末會貼出來，所以如果你感興趣的話鹦蠕，在你們的服務(wù)器上也能重現(xiàn)本文的壓測結(jié)果冒签。
The Setup
本次測試，總計6臺服務(wù)器钟病，配置如下：
- Intel Xeon 2.5 GHz processor with six cores
- Six 7200 RPM SATA drives
- 32GB of RAM
- 1Gb Ethernet
kafka集群安裝在其中的3臺服務(wù)器上萧恕，6塊硬盤直接掛載，沒有RAID肠阱。另外三臺服務(wù)器用于Zookeeper和壓力測試票唆。
3臺服務(wù)器的集群不是很大，但是因為我們只測試復(fù)制因子為3屹徘，所以三臺服務(wù)器集群足夠走趋。顯而易見的是，我們能通過增加更多的分區(qū)噪伊，傳播數(shù)據(jù)到更多的服務(wù)器上來水平擴展我們的集群簿煌。
這些硬件不是LinkedIn平常使用的kafka硬件。我們的kafka服務(wù)器有針對性的調(diào)優(yōu)酥宴，能更好的運行的運行kafka啦吧。這次測試，我從Hadoop集群中借用了這幾臺服務(wù)器拙寡，這些服務(wù)器都是我們持久化系統(tǒng)中最便宜的設(shè)備授滓。 Hadoop的使用模式與Kafka非常相似，所以這是一件合理的事情肆糕。
Producer Throughput
接下來的測試是壓測生產(chǎn)者的吞吐量般堆，測試過程中沒有消費者運行，因此所有消息被持久化（稍后會測試生產(chǎn)者和消費者都存在的場景）诚啃，但是沒有被讀取淮摔。
Single producer thread, no replication
- 821,557 records/sec
- 78.3 MB/sec
這第一個測試基于的topic：6個分區(qū)，沒有副本始赎。然后單線程盡可能快的產(chǎn)生5千萬個小記錄（100byte）和橙。在這些測試中關(guān)注小記錄的原因是它對于消息系統(tǒng)來說是更難的情況。如果消息很大造垛，很容易以MB/秒獲得良好的吞吐量魔招，但是當消息很小時反而很難獲得良好的吞吐量，因為處理每個消息的開銷占主導(dǎo)地位五辽。
一個直接的觀察是办斑，這里的壓測數(shù)據(jù)遠高于人們的預(yù)期，特別是對于持久存儲系統(tǒng)。 如果您習(xí)慣于隨機訪問數(shù)據(jù)系統(tǒng)（如數(shù)據(jù)庫或鍵值存儲）乡翅，通常會產(chǎn)生大約5,000到50,000次查詢的最大吞吐量鳞疲，這接近于良好的RPC層可以執(zhí)行的速度遠程請求。 由于兩個關(guān)鍵設(shè)計原則蠕蚜，我們超過了這一點：
- 我們努力確保我們進行線性磁盤I/O尚洽。這些服務(wù)器提供的六塊廉價磁盤的線性總吞吐量為822 MB /秒。許多消息系統(tǒng)將持久性視為昂貴的附加組件波势，認為其會降低性能并且應(yīng)該謹慎使用翎朱，但這是因為它們沒有進行線性I/O.
- 在每個階段，我們都致力于將少量數(shù)據(jù)批量合并到更大的網(wǎng)絡(luò)和磁盤I/O操作中尺铣。 例如拴曲，在新生產(chǎn)者中，我們使用“group commit”類似的機制來確保在另一個I/O正在進行中時發(fā)起的任何記錄被組合在一起凛忿。 有關(guān)了解批處理重要性的更多信息澈灼，請參閱David Patterson寫的"Latency Lags Bandwidth"。
Single producer thread, 3x async replication
- 786,980 records/sec
- 75.1 MB/sec
這次測試和前一次的測試幾乎一樣店溢，除了每個分區(qū)有三個副本（因此寫到網(wǎng)絡(luò)或者磁盤的數(shù)據(jù)是前一次的三倍）叁熔。每個服務(wù)器都從生產(chǎn)者那里為它作為leader分區(qū)執(zhí)行寫操作，以及為其作為follower分區(qū)獲取和寫入數(shù)據(jù)床牧。
本次測試的復(fù)制是異步的荣回，即acks=0。消息只要寫到本地日志即可戈咳，不需要等待這個分區(qū)的其他副本收到消息心软。這就意味著，如果leader崩潰著蛙，可能會丟失最新的一些還未同步到副本的消息删铃。
我希望人們能從中得到的關(guān)鍵是復(fù)制可以更快。對應(yīng)3x復(fù)制踏堡，集群總寫入能力有3倍的退化猎唁，因為每個寫操作要做3次。但是每個客戶端的吞吐量依然表現(xiàn)不錯顷蟆。 高性能復(fù)制在很大程度上取決于我們的消費者的效率诫隅，后面會在消費者部分討論。
Single producer thread, 3x sync replication
- 421,823 records/sec
- 40.2 MB/sec
此次測試和前面的測試一樣帐偎，除了leader需要等待所有in-sync replicas確認收到消息才會返回結(jié)果給生產(chǎn)者逐纬。即acks=all或者acks=-1。這種模式下肮街，只要有一個in-sync replica存在风题，消息就不會丟失判导。
Kafka中的同步復(fù)制與異步復(fù)制沒有根本的不同嫉父。分區(qū)leader總是跟蹤follower副本進度沛硅，監(jiān)控它們是否存在。在所有in-sync replicas確認收到消息之前绕辖，我們永遠不會向消費者發(fā)出消息摇肌。使用同步復(fù)制，我們要等待響應(yīng)給生產(chǎn)者的請求仪际，直到follower副本都已經(jīng)復(fù)制围小。
這種額外的延遲似乎會影響我們的吞吐量。由于服務(wù)器上的代碼路徑非常相似树碱，我們可以通過調(diào)整批處理來更好地改善這種影響肯适，并允許客戶端緩沖更多未完成的請求。 但是成榜，本著避免特殊情況調(diào)整的原則框舔，我沒有這么做。
Three producers, 3x async replication
- 2,024,032 records/sec
- 193.0 MB/sec
我們的單一生產(chǎn)者處理顯然不能壓出三節(jié)點集群的能力上限赎婚。為了增加負載刘绣，重復(fù)前面的異步復(fù)制模式測試流程，但是在三臺不同服務(wù)器上運行三個不同的生產(chǎn)者（在同一臺機器上運行更多進程將無助于我們使NIC飽和）挣输。然后纬凤，我們可以查看這三個生產(chǎn)者的總吞吐量，以更好地了解群集的總?cè)萘俊?/p>
Producer Throughput VS. Stored Data
許多消息系統(tǒng)一個隱藏的危險是撩嚼，只有在他們保存的數(shù)據(jù)在內(nèi)存中才會工作的很好停士。當數(shù)據(jù)備份不能被消費時（數(shù)據(jù)就需要存儲到磁盤上），吞吐量會下降幾個等級绢馍，甚至更多向瓷。這就意味著只有在消費者速度能跟上生產(chǎn)者，并且隊列是空的情況下系統(tǒng)才會運行良好舰涌。一旦消費者落后猖任，沒有消費的消息需要備份，備份可能會使數(shù)據(jù)持久化到磁盤上瓷耙，這就會引起性能大幅下降朱躺。這意味著消息傳遞系統(tǒng)無法跟上傳入的數(shù)據(jù)。這種情況非常嚴重搁痛，消息系統(tǒng)在大部分情況下长搀，應(yīng)該能做到平和的處理隊列中的消息。
kafka總是采用追加的方式持久化消息鸡典，并且對于沒有消費的數(shù)據(jù)源请，持久化的的時間復(fù)雜度是 O(1)。
這次實驗測試，讓我們在一段延長的時間內(nèi)運行吞吐量測試谁尸，并在存儲的數(shù)據(jù)集增長時繪制結(jié)果圖：
如圖所示舅踪，性能并沒有明顯的變化。但是由于數(shù)據(jù)大小所以沒有影響：我們在寫入TB數(shù)據(jù)之后也表現(xiàn)得同樣好良蛮，就像前幾百MB一樣抽碌。
圖中的性能波動主要是因為Linux系統(tǒng)I/O管理批量處理數(shù)據(jù)，周期性的把數(shù)據(jù)flush到磁盤决瞳。LinkedIn的kafka生產(chǎn)環(huán)境上針對這個有一些調(diào)優(yōu)货徙。可以參考kafka Hardware and OS皮胡。
Consumer Throughput
OK痴颊，現(xiàn)在讓我們把注意力轉(zhuǎn)移到消費者吞吐量上來。
請注意屡贺，復(fù)制因子不會影響此測試的結(jié)果祷舀。因為不管復(fù)制因子如何，消費者只能從一個副本讀取烹笔。 同樣裳扯，生產(chǎn)者的確認級別（acks參數(shù)）也無關(guān)緊要，因為消費者只讀取完全確認的消息（所有In-Sync Replicas都已經(jīng)同步的消息才能被消費）谤职。 這是為了確保消費者看到的任何消息在leader切換后始終存在（如果當前l(fā)eader發(fā)生異常需要重新選舉新的leader的話）饰豺。
Single Consumer
- 940,521 records/sec
- 89.7 MB/sec
第一次測試：將在有6個分區(qū)，3個副本的topic中單線程消費5千萬條消息允蜈。
kafka消費者效率很高冤吨，它直接從linux文件系統(tǒng)中抓取日志塊。它通過sendfile這個API饶套，直接通過操作系統(tǒng)傳輸數(shù)據(jù)漩蟆，所以沒有通過應(yīng)用程序復(fù)制此數(shù)據(jù)的開銷。
本次測試實際上從日志初始位置開始妓蛮，因此它在做真正的讀I/O怠李。但是在生產(chǎn)環(huán)境中，消費者幾乎完全從OS頁面緩存中讀取蛤克，因為它正在讀取剛剛由某個生產(chǎn)者產(chǎn)生的數(shù)據(jù)（這些數(shù)據(jù)仍然在緩存中）捺癞。事實上，如果您在生產(chǎn)服務(wù)器上運行相關(guān)命令查看I/O stat构挤，會看到消耗大量數(shù)據(jù)被消費髓介，也根本沒有物理讀取。
讓消費者盡可能cheap筋现，是我們希望kafka做的一件非常重要的事情唐础。首先箱歧，副本也是消費者。所以一膨，讓消費者cheap叫胁，副本也會cheap。其次汞幢，這樣會是處理數(shù)據(jù)不是非常昂貴的操作。因此出于可伸縮性的原因微谓，我們不需要嚴格控制森篷。
cheap字面含義是便宜，但是在這里的含義豺型，我覺得是業(yè)務(wù)邏輯不要太復(fù)雜仲智。
Three Consumers
- 2,615,968 records/sec
- 249.5 MB/sec
重復(fù)上面相同的測試，不同的是有三個消費者并行處理姻氨。三個消費者分布在三臺不同服務(wù)器上钓辆。這三個消費者屬于同一個消費者組中的成員，即它們消費同樣的topic肴焊。
和我們預(yù)期一樣前联，我們看到消費能力線性擴展，幾乎就是單個消費者吞吐量的3倍娶眷，這一點都不令人驚訝似嗤。
Producer and Consumer
- 795,064 records/sec
- 75.8 MB/sec
上面的測試僅限于生產(chǎn)者和消費者運行在不同服務(wù)器。現(xiàn)在届宠，讓我們把生產(chǎn)者和消費者運行在同一臺服務(wù)器上烁落。實際上，我們也是這樣做的豌注，因為這樣的話伤塌，復(fù)制工作就是讓服務(wù)器本身充當消費者。
對于此次測試轧铁，我們將基于6個分區(qū)每聪，3個副本的topic，分別運行1個生產(chǎn)者和1個消費者齿风，并且topic初始為空熊痴。 生產(chǎn)者再次使用異步復(fù)制。 報告的吞吐量是消費者吞吐量（顯然聂宾，是生產(chǎn)者吞吐量的上限）果善。
和我們預(yù)期一樣，得到的結(jié)果和只有生產(chǎn)者時基本相同系谐，前提是消費者相當cheap巾陕。
Effect of Message Size
前面的測試已經(jīng)展示了100字節(jié)大小消息kafka的性能讨跟。對于消費系統(tǒng)來說，更小的消息是更大的問題鄙煤。因為它們放大了系統(tǒng)記賬的開銷晾匠。 我們可以通過在記錄/秒和MB/秒兩者中繪制吞吐量來顯示這一點：
這張圖和我們預(yù)期一樣，隨著消息體越來越大梯刚，每秒我們能發(fā)送的消息數(shù)量也會減少凉馆。但是，如果我們看MB/秒性能報告亡资，我們會看到實際用戶數(shù)據(jù)的總字節(jié)吞吐量隨著消息變大而增加：
總結(jié)：消息體越大澜共，每秒能處理的消息數(shù)量越少，但是每秒能處理的消息體積越大锥腻；消息體越小嗦董，每秒能處理的消息數(shù)量越多，但是每秒能處理的消息體積越惺莺凇京革；
另外我們可以看到，對于10字節(jié)的消息幸斥，我們實際上只是通過獲取鎖并將消息排入發(fā)送來限制CPU - 我們無法實際最大化網(wǎng)絡(luò)匹摇。 但是，從100字節(jié)開始甲葬，我們實際上看到網(wǎng)絡(luò)飽和来惧。
End-to-end Latency
- 2 ms (median)
- 3 ms (99th percentile)
- 14 ms (99.9th percentile)
到現(xiàn)在為止，我們討論的都是吞吐量演顾。但是消息傳遞的延遲情況呢供搀？也就是說，消息傳遞到消費者钠至，需要多長的時間葛虐。此次測試，我們將創(chuàng)建生產(chǎn)者和消費者棉钧，并重復(fù)計算生產(chǎn)者將消息發(fā)送到kafka集群然后由我們的消費者接收所需的時間屿脐。
請注意，Kafka僅在所有in-sync replicas確認消息后才向消費者發(fā)出消息宪卿。因此的诵，無論我們使用同步還是異步復(fù)制，此測試都會給出相同的結(jié)果佑钾，因為該設(shè)置僅影響對生產(chǎn)者的確認西疤，而本次測試是生產(chǎn)者發(fā)送的消息傳遞到消費者的時間。
Replicating this test
如果你想要在你自己的服務(wù)器上休溶，運行這些壓力測試代赁，當然沒有問題扰她。正如我所說的，我大部分情況下只是使用我們預(yù)裝的性能測試工具芭碍，這些工具隨Kafka發(fā)布包一起提供，并且服務(wù)器和客戶端大部分都是默認配置窖壕。
attachment
下面給出本次壓測一些命令忧勿，以及kafka服務(wù)器配置。
benchmark commands
###############################################################
壓測腳本（zk集群地址后的/afei是配置的chroot）:
--zookeeper：10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei
--broker： 10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092
################################################################
創(chuàng)建需要的TOPIC：
bin/kafka-topics.sh --zookeeper 10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei --create --topic TPC-P6-R1 --partitions 6 --replication-factor 1
bin/kafka-topics.sh --zookeeper 10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei --create --topic TPC-P6-R3 --partitions 6 --replication-factor 3
1個生產(chǎn)者-單線程&無副本：
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R1 --num-records 50000000 --record-size 128 --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
執(zhí)行腳本說明：
--num-records表示發(fā)送消息的數(shù)量瞻讽，即5kw條鸳吸；
--record-size表示每條消息的大小，即128字節(jié)卸夕；
--throughput表示吞吐量限制，-1沒有限制婆瓜；
--producer-props后面的都是生產(chǎn)者配置
1個生產(chǎn)者-單線程&3個副本異步寫入：
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records 50000000 --record-size 100 --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
1個生產(chǎn)者-單線程&3個副本同步寫入：
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records 50000000 --record-size 100 --throughput -1 --producer-props acks=-1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
3個生產(chǎn)者-單線程&3個副本異步寫入：
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records 50000000 --record-size 100 --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
- 發(fā)送50億條100個字節(jié)大小的消息
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records 5000000000 --record-size 100 --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
消費尺寸的影響--分別嘗試各種不同字節(jié)大小消息
for i in 10 100 1000 10000 100000;
do
echo ""
echo $i
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records $((1000*1024*1024/$i)) --record-size $i --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
done;
單個消費者消息能力：
bin/kafka-consumer-perf-test.sh --zookeeper 10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei --messages 50000000 --topic TPC-P6-R3 --threads 1
3個消費者消費能力--在3臺服務(wù)器上運行3個消費者:
bin/kafka-consumer-perf-test.sh --zookeeper 10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei --messages 50000000 --topic TPC-P6-R3 --threads 1
生產(chǎn)者&消費者：
bin/kafka-run-class.sh org.apache.kafka.tools.ProducerPerformance --topic TPC-P6-R3 --num-records 50000000 --record-size 100 --throughput -1 --producer-props acks=1 bootstrap.servers=10.0.0.1:9092,10.0.0.2:9092,10.0.0.3:9092 buffer.memory=67108864 batch.size=8196
bin/kafka-consumer-perf-test.sh --zookeeper 10.0.1.1:2181,10.0.1.2:2181,10.0.1.2:2181/afei --messages 50000000 --topic TPC-P6-R3 --threads 1
server config
broker.id=0
port=9092
num.network.threads=4
num.io.threads=8
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600
log.dirs=/grid/a/dfs-data/kafka-logs,/grid/b/dfs-data/kafka-logs,/grid/c/dfs-data/kafka-logs,/grid/d/dfs-data/kafka-logs,/grid/e/dfs-data/kafka-logs,/grid/f/dfs-data/kafka-logs
num.partitions=8
log.retention.hours=168
log.segment.bytes=536870912
log.cleanup.interval.mins=1
zookeeper.connect=10.0.0.1:2181
zookeeper.connection.timeout.ms=1000000
kafka.metrics.polling.interval.secs=5
kafka.metrics.reporters=kafka.metrics.KafkaCSVMetricsReporter
kafka.csv.metrics.dir=/tmp/kafka_metrics
kafka.csv.metrics.reporter.enabled=false
replica.lag.max.messages=10000000
