filebeat作為日誌採集agent, 是需要部署到生產伺服器上的.不理解filebeat的工作機制,不了解filebeat在實際生產使用中的記憶體使用將會給你帶來意想不到的麻煩.
有些文章說filebeat記憶體消耗很少,不會超過100m, 這簡直是不負責任的胡說,假如帶著這樣的認識把filebeat部署到生產伺服器上就等著哭吧.
filebeat在空載情況(沒有日誌可採集)下的確不會有大的記憶體開銷,但在有大量的日誌需要採集時,filebeat的記憶體占用是沒有固定值的, 那有沒有理論值呢?答案是有, 為啥這麼說,看下面公式:
bytes_each_log * spool_size * m + a*n
其中, bytes_each_log是單條日誌大小, spool_size是配置檔案裡配置項, m是單條日誌在記憶體裡的溢價係數(>1), n表示採集的檔案個數,a為常數.
spool_size的預設值是2048, 好多人估計都不會配置這個項,也會因此埋下禍根(oom):
假設忽略a*n部分的記憶體開銷, 單條日誌的記憶體溢價為3, 一旦出現單條日誌大於50kb且有瞬間爆發量的時候, filebeat的記憶體占用將大於300mb,是不是有點嚇人!如果出現了極端情況,單條日誌》10m,即使filebeat會截斷到10m那也是20gb!!是不是腿都軟了!!!
filebeat在實際使用過程中記憶體》300m,甚至15gb的情況浣熊都遇到過, 記憶體超過300m幾乎經常遇到,基本都是因為客戶沒有按照吩咐的去做導致的; 15gb的那次有點意外和驚喜, 客戶在自己的日誌檔案裡打了大量的二進位制檔案(後來知道真相的我眼淚掉下來...), 大量的二進位制檔案觸發了10mb規則,還好吃掉15gb記憶體後filebeat因oom退出了,沒有帶來嚴重的損失.
那怎麼樣才能避免以上記憶體災難呢?劃重點了,快快拿出小本本記錄:
(1)每個日誌生產環境生產的日誌大小,爆發量都不一樣, 要根據自己的日誌特點設定合適的spool_size值;什麼叫合適,至少能避免記憶體》200mb的災難;
(2)在不知道日誌實際情況(單條大小,爆發量), 務必把spool_size設定上,建議128或者256;
最後分享張實踐:
單條日誌為45kb, spool_size為2048的記憶體開銷,陡坡下是spool_size調整為128的效果.
shell 快速實踐多服務filebeat部署
作為乙個非資深運維和非資深liunx的指令碼的人員,你可能只負責開發,或者做大資料相關運算,不得不接觸伺服器做些工具和元件的小測試,但是遇到hdfs集群,或者yarn集群有20臺 的,怎麼辦?求教別人嗎?會不會遭人家嫌棄?還是自己一台臺的敲命令,或者用shell工具的多視窗模式.進行批量執行,這些都...
類記憶體占用
類所佔記憶體的大小是由成員變數 靜態變數除外 決定的，成員函式 是不計算在內的。成員函式還是以一般的函式一樣的存在。a.fun 是通過fun a.this 來呼叫的。所謂成員函式只是在名義上是類裡的。其實成員函式的大小不在類的物件裡面，同乙個類的多個物件共享函式 而我們訪問類的成員函式是通過類裡面的...
程式占用記憶體分析
堆與棧有什麼區別？一 預備知識 程式的記憶體分配 乙個由c c 編譯的程式占用的記憶體分為以下幾個部分 1 棧區 stack 由編譯器自動分配釋放 存放函式的引數值，區域性變數的值等。其操作方式類似於資料結構中的棧。2 堆區 heap 一般由程式設計師分配釋放，若程式設計師不釋放，程式結束時可能由o...