之前曾經在Raspberry Pi model B上面試過, 但是超級緩慢的I/O根本沒辦法應付node較多時的需求.
以現在的狀況來說, 我要收80個node的資料, rrd資料檔就到1.8GB左右...
而且就算node少, 單核心的CPU光是回應rrdtool的需求就喘了XD
Raspberry Pi 2 model B從ARMv6 900MHz單核心, 一舉升級到ARM Cortex-A7 900MHz 四核心, CPU效能有很大的成長, 記憶體量也加倍 (512MB to 1GB), 至少可以預期httpd/rrdtool的反應會好很多.
但I/O的狀況沒變, 還是SD卡, 而且沒有支援SDXC UHS規格, 所以那些高速卡放到RPi2上面也是無用武之地.
所以, 只能從減少I/O量來下手了, 這時很自然會想到rrdcached.
這次測試用的記憶卡是Adata class10 16GB, 用dd測循序速度大約在10MB/s左右.
給RPi2用的Raspbian裡面套件相當齊全, 不過因為給的RRDtool版本是1.4.6, 所以我還是從頭編了1.4.8版本. 用的flags:
CFLAGS="-march=armv7-a mfpu=vfpv4 -mfloat-abi=hard"
另外Ganglia在套件庫裡給的是3.4版, 所以我也重新編了3.6.1版, 用一樣的CFLAGS.
到這裡的安裝基本上沒什麼問題, 只是要適應一下Raspbian (Debian系) 的差異.
其他需要的東西 (apache2, php, etc.) 都可以用APT直接安裝.
這樣做出來的效果不能說是堪用, 因為I/O雖然用rrdcached做了快取也還是太大, 以80個node來說, RPi2勉強趕得上, 但去看會發現CPU會一直都是100%, 其中大部分都是I/O wait.
這樣的話, 只能再從I/O量的縮減去下手了... 於是我切了一個4GB的分割區, 打算用BtrFS的compression功能來應付.
(掛載參數: compress-force=lzo,noatime)
這時候發現一個糟糕的問題. 做出來的BtrFS可以寫入RRD資料, 但是df與du看到的量是大約相同的, 也就是說, 壓縮沒有產生效果. 做了不少搜尋才發現, 如果程式是用Direct I/O寫入的話, 壓縮不會生效. 所以再來用的爛方法是, 把RRD資料通通打包起來, 再重新寫回去BtrFS裡面, 這時候就可以看到壓縮的效果了.
再深究一點會發現, BtrFS可以用defrag的方式來對現有檔案進行壓縮. 雖然還有個autodefrag的掛載參數可以用, 但實際上, 因為RRDtool是對rrd檔案的小部分作持續性的操作, 在這個情況下, 使用autodefrag會導致Btrfs不斷地做defrag, 反而btrfs-cleaner程序會把CPU跟I/O灌滿. 所以這也不可行.
最後的情況是, 搭配rrdcached+BtrFS LZO壓縮, 能夠讓RPi2在收取80個node的RRD資料時, 把CPU loading壓在平均20%左右, 其中大概有8~10%是 system load, 也就是花在LZO壓縮的時間. 長期使用的效果還需要觀察, 最後也許會用cron定時把BtrFS用autodefrag掛載個10分鐘左右, 維持BtrFS的壓縮率.
整個評估起來, 如果cluster的規模在64個node以下, 這樣用是OK的. 挑選更好的記憶卡應該會有效果, 但我想不會大到哪裡去, 畢竟吃的是隨機存取的速度(或IOPS), 而不是循序存取速度. 如果要應付更大規模, ODROID U3因為具備eMMC的選項, 靠著80~100MB/s的速度與更高的IOPS, 應該可以從根本上解決I/O問題.
No comments:
Post a Comment