記憶體估算
您需要足夠的記憶體來緩衝活動的讀取器和寫入器。 您可以透過假設您希望能夠緩衝 30 秒並將您的記憶體需求計算為 write_throughput*30 來對記憶體需求進行粗略估計。
作業系統
Kafka 可以在任何 unix 系統上執行良好，並且已經在 Linux 和 Solaris 上進行了測試。
我們已經看到在 Windows 上執行的一些問題，Windows 目前不是一個受支援的平臺，儘管我們很樂意改變它。
不太可能需要大量的作業系統級調整，但有三個潛在的重要作業系統級配置：
檔案描述符限制：Kafka 將檔案描述符用於日誌段和開啟的連線。 如果broker託管許多分割槽，請考慮broker至少需要 （number_of_partitions）*（partition_size/segment_size） 來跟蹤除broker建立的連線數之外的所有日誌段。 我們建議至少 100000 個允許的broker程序檔案描述符作為起點。 注意： mmap（） 函式添加了對與檔案描述符 fildes 關聯的檔案的額外引用，該檔案描述符上的後續 close（） 不會刪除該檔案。 當沒有更多對映到檔案時，將刪除此引用。
程序可能擁有的最大記憶體對映區域數（又名 vm。max_map_count）。 請參閱 Linux 核心文件。 在考慮broker可能擁有的最大分割槽數時，您應該密切關注這個作業系統級別的屬性。 預設情況下，在許多 Linux 系統上，vm。max_map_count 的值大約為 65535。每個分割槽分配的每個日誌段需要一對 index/timeindex 檔案，每個檔案佔用 1 個對映區域。 換句話說，每個日誌段使用 2 個 區域。 因此，每個分割槽至少需要 2 個對映區域，只要它承載單個日誌段。 也就是說，在broker上建立 50000 個分割槽將導致分配 100000 個對映區域，並可能導致broker在具有預設 vm。max_map_count 的系統上崩潰並出現 OutOfMemoryError（對映失敗）。 請記住，每個分割槽的日誌段數取決於段大小、負載強度、保留策略，並且通常往往不止一個。
最大套接字緩衝區大小：可以增加以實現資料中心之間的高效能資料傳輸，如此處所述。
磁碟與檔案系統
我們建議使用多個驅動器來獲得良好的吞吐量，並且不要與應用程式日誌或其他作業系統檔案系統活動共享用於 Kafka 資料的相同驅動器以確保良好的延遲。 您可以將這些驅動器 RAID 組合到一個卷中，也可以格式化並將每個驅動器安裝為自己的目錄。 由於 Kafka 具有複製功能，因此也可以在應用程式級別提供 RAID 提供的冗餘。 這種選擇有幾個權衡。
如果您配置多個數據目錄，多個分割槽將被分配到多個數據目錄。 並且每個分割槽將完全位於其中一個數據目錄中。 如果資料在分割槽之間沒有很好地平衡，這可能會導致磁碟之間的負載不平衡。
RAID 可能在平衡磁碟之間的負載方面做得更好（儘管它似乎並不總是如此），因為它在較低級別平衡負載。 RAID 的主要缺點是它通常會嚴重影響寫入吞吐量的效能並減少可用磁碟空間。
RAID 的另一個潛在好處是能夠容忍磁碟故障。 然而，我們的經驗是，重建 RAID 陣列是 I/O 密集型的，它有效地禁用了伺服器，因此這並沒有提供多少真正的可用性改進。
應用與快取重新整理管理
Kafka 總是立即將所有資料寫入檔案系統，並支援配置重新整理策略的能力，該策略控制何時使用重新整理將資料強制從作業系統快取中移出到磁碟上。 可以控制此重新整理策略以在一段時間後或在寫入一定數量的訊息後強制將資料寫入磁碟。 此配置中有多種選擇。
Kafka 最終必須呼叫 fsync 才能知道資料已被重新整理。 當從任何未知的 fsync‘d 日誌段的崩潰中恢復時，Kafka 將透過檢查其 CRC 來檢查每條訊息的完整性，並重建隨附的偏移索引檔案作為啟動時執行的恢復過程的一部分。
請注意，Kafka 中的永續性不需要將資料同步到磁碟，因為故障節點將始終從其副本中恢復。
我們建議使用完全禁用應用程式 fsync 的預設重新整理設定。 這意味著依賴作業系統完成的後臺重新整理和 Kafka 自己的後臺重新整理。 這為大多數用途提供了所有領域中最好的：無需調整配置、出色的吞吐量和延遲，以及完全恢復保證。 我們通常認為複製提供的保證比同步到本地磁碟更強，但是偏執狂仍然可能更喜歡同時支援應用程式級 fsync 策略。
使用應用程式級重新整理設定的缺點是它的磁碟使用模式效率較低（它使作業系統重新排序寫入的餘地較小）。並且它會引入延遲，因為大多數 Linux 檔案系統中的 fsync 會阻止寫入檔案，而後臺重新整理會執行更細粒度的頁面級鎖定。
一般來說，您不需要對檔案系統進行任何底層調整，但在接下來的幾節中，我們將討論其中的一些內容，以防萬一。
理解Linux作業系統的快取重新整理行為
在 Linux 中，寫入檔案系統的資料儲存在頁面快取中，直到必須將其寫出到磁碟（由於應用程式級 fsync 或作業系統自己的重新整理策略）。 資料的重新整理由一組稱為 pdflush 的後臺執行緒完成（或在 2。6。32 後的核心中“重新整理執行緒”）。
Pdflush 有一個可配置的策略，用於控制可以在快取中維護多少髒資料以及必須將其寫回磁碟前多長時間。此處描述了此策略。當 Pdflush 跟不上寫入資料的速度時，它最終會導致寫入過程阻塞寫入中產生的延遲，從而減慢資料的積累速度。
您可以透過執行檢視作業系統記憶體使用的當前狀態
> cat /proc/meminfo
這些值的含義在上面的連結中有描述。
與程序內快取相比，使用 pagecache 有幾個優點，用於儲存將被寫出到磁碟的資料：
I/O 排程程式會將連續的小寫操作批處理為更大的物理寫操作，從而提高吞吐量。
I/O 排程程式將嘗試重新排序寫入以最小化磁碟磁頭的移動，從而提高吞吐量。
它會自動使用機器上的所有空閒記憶體
檔案系統選擇
Kafka 使用磁碟上的常規檔案，因此它對特定檔案系統沒有硬性依賴。 然而，使用最多的兩個檔案系統是 EXT4 和 XFS。 從歷史上看，EXT4 有更多的使用，但最近對 XFS 檔案系統的改進表明，它具有更好的 Kafka 工作負載效能特徵，而不會影響穩定性。
比較測試是在具有大量訊息負載的叢集上執行的，使用各種檔案系統建立和掛載選項。 Kafka 中受監控的主要指標是“請求本地時間”，表示追加操作所花費的時間。 XFS 帶來了更好的本地時間（160 毫秒對 250 毫秒 + 最佳 EXT4 配置），以及更低的平均等待時間。 XFS 效能在磁碟效能方面的變化也較小。
一般檔案系統建議
對於任何用於資料目錄的檔案系統，在 Linux 系統上，建議在掛載時使用以下選項：
noatime：該選項禁止在讀取檔案時更新檔案的 atime（上次訪問時間）屬性。 這可以消除大量的檔案系統寫入，尤其是在引導消費者的情況下。 Kafka 根本不依賴 atime 屬性，因此禁用它是安全的。
XFS檔案系統建議
XFS 檔案系統具有大量的自動調整功能，因此它不需要在預設設定中進行任何更改，無論是在檔案系統建立時還是在安裝時。 唯一值得考慮的調整引數是：
largeio：這會影響 stat 呼叫報告的首選 I/O 大小。 雖然這可以在更大的磁碟寫入上實現更高的效能，但實際上它對效能的影響很小或沒有影響。
nobarrier：對於具有battery-backed快取的底層裝置，此選項可以透過禁用定期寫入重新整理來提供更高的效能。 但是，如果底層裝置表現良好，它將向檔案系統報告它不需要重新整理，並且此選項將不起作用。
EXT4檔案系統建議
EXT4 是適用於 Kafka 資料目錄的檔案系統選擇，但是要從中獲得最大效能需要調整幾個掛載選項。 此外，這些選項在故障情況下通常是不安全的，並且會導致更多的資料丟失和損壞。 對於單個 Broker 故障，這不是什麼大問題，因為可以擦除磁碟並從叢集重建副本。 在多次故障的情況下，例如斷電，這可能意味著底層檔案系統（以及資料）損壞且不易恢復。 可以調整以下選項：
data=writeback：Ext4 預設為 data=ordered，這對某些寫入設定了強順序。 Kafka 不需要這種排序，因為它對所有未重新整理的日誌進行非常偏執的資料恢復。 此設定消除了排序約束，似乎顯著減少了延遲。
禁用日誌：日誌是一種權衡：它使伺服器崩潰後重新啟動更快，但它引入了大量額外的鎖定，從而增加了寫入效能的差異。 那些不關心重啟時間並希望減少寫入延遲峰值的主要來源的人可以完全關閉日誌。
commit=num_secs：這會調整 ext4 提交到其元資料日誌的頻率。 將此設定為較低的值可減少崩潰期間未重新整理資料的丟失。 將此設定為更高的值將提高吞吐量。
nobh：當使用 data=writeback 模式時，此設定控制額外的排序保證。 這對於 Kafka 應該是安全的，因為我們不依賴於寫入順序並提高了吞吐量和延遲。
delalloc：延遲分配意味著檔案系統在物理寫入發生之前避免分配任何塊。 這允許 ext4 分配較大的範圍而不是較小的頁面，並有助於確保資料按順序寫入。 此功能非常適合吞吐量。 它似乎確實涉及檔案系統中的一些鎖定，這增加了一些延遲差異。
