replica.fetch.max.bytes
每個partition都分配乙個buffer給replica,如果分配1m,如果有1000個partition就需要1g的記憶體需求考慮有充足的記憶體
fetch.message.max.bytes
同樣的考慮也適用於consumer，對於大檔案需要確保有充足的記憶體接收，大檔案可能需要較少的partition或者更多的記憶體
當系統的負載過大需要增加broker時，kafka不會自動將資料載入到該broker
需要手動執行
建立想要移動的topic list
topics-to-move.json儲存為json檔案，我們這裡是topics-to-move.json, ],
"version":1
}
執行 --generate將產生推薦的列表
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181--topics-to-move-json-file topics-to-move.json
--broker-list "4"
--generate
執行完成螢幕將顯示推薦的資訊
current partition replica assignment, ,,,
,]},,]
}
校驗資訊並且儲存json檔案，這裡是expand-cluster-reassignment.json
執行動作
bin/kafka-reassign-partitions.sh \--zookeeper localhost:2181 \
--reassignment-json-file expand-cluster-reassignment.json
--execute
最後驗證結果
bin/kafka-reassign-partitions.sh \--zookeeper localhost:2181 \
--reassignment-json-file expand-cluster-reassignment.json
--verify
監聽gc log，gc暫停時間過長可能使zookeeper session超時，需要增加
zookeeper.session.timeout.ms
大檔案首先考慮以下幾點，減少資訊的大小
壓縮 compression.codec
或者compressed.topics支援壓縮資訊
如果共享儲存系統可用使用它比使用kafka傳送大檔案效能更快（nas,hdfs,s3），將大檔案發在共享儲存，利用kafka傳送訊息
在producer端將大資訊拆分成1k的小segment,利用partiton key傳送到同乙個partition,在consumer端可以還原它
如果仍然需要傳送大檔案到kafka,調整如下幾項
message.max.bytes
broker可以接收的最大message,需要小於fetch.message.max.bytes否則consumer不能訊息它
log.segment.bytes
kafka log檔案的最大值，必須大於最大message的值
replica.fetch.max.bytes
必須大於message.max.bytes，保證replica可以複製成功否則將丟失資料
fetch.message.max.bytes
必須大於
message.max.bytes，保證可以訊息
message.max.bytes < log.segment.bytes (保證可以儲存）
message.max.bytes < replica.fetch.max.bytes （保證可以複製）
message.max.bytes <
fetch.message.max.bytes(保證可以訊息）
kafka producer是將資訊發入buffer，當buffer滿時傳送資料，然後重新填充buffer
它有兩個非常重要的指標latency,
throughput，對應kafka 引數就是batch.size,linger.ms
batch.size
當資料大小到達時傳送資料到broker,你可以增加該值但是它可能永遠不會滿，但是它會在滿足其他條件的情況下傳送（超時）
linger.ms
利用時間來控制傳送間隔，你可以調大它保證很好的throughput,但是latency會很大
這裡說明一下因為我翻譯的是cloudera的文件，可能再這裡引數名和apache的不一樣
所以這裡以我的理解應該是這兩個引數
cloudera的兩個引數名分別是
queue.buffering.max.ms -> linger.ms
send.buffer.bytes -> batch.size
kafka 每乙個partition有乙個leader,需要保證leader在broker之間的balance,配置auto.leader.rebalance.enable＝true (更改）
cloudera推薦乙個partiton單獨乙個物理磁碟，乙個partiton乙個consumer
consumer的數量應該等於topic partiton的數量，同乙個consumer group中的consumer會折分到不同的partition這樣可以得到更好的效能
replica.high.watermark.checkpoint.interval.ms
調整該引數可以保證讀取有更好的效率，它可以儲存你讀取的檢查點，使你不會讀取之前讀過的資料，如果每個讀取都儲存chekpoint那麼你永遠不會丟訊息，
但是throughput很低
kafka 需要開啟大量檔案需要調linux limit
高效能與可擴充套件
效能低主要是由於i o操作導致的延遲，導致了等待 cpu很閒，處理速率卻上不去 解決辦法 減少i o操作 加入快取來緩解i o操作 讓出主線程，開啟單獨執行緒來處理i o操作 主線程就能處理更多的iis請求 把大面積的資料 比如某字段中儲存了1w個字串，並且select了多行.omg 壓縮後儲存到磁...
UI 效能因素考慮
瀏覽器的最大併發連線數一般在4到6之間，首先了解影響載入的效能因素 2 發出的請求太多 3 請求相應不及時 針對這些因素，一般會考慮減少請求次數 1 對靜態檔案設定快取事件 2 頁面設計盡量簡潔 3 合併檔案 html，js，css，再細緻一點 1 頁面實現按需載入 分時載入 2 頁面提交，考慮非同...
kafka效能測試
版本0.10.1.1 kafka broker的jvm預設是使用1g的記憶體 bin kafka producer perf test.sh topic test pati3 rep2 throughput 500000 num records 1500000 record size 1000 pr...