AWS EC2 安裝 Kibana X-Pack 插件的內存不足問題
最近在學習 ELK，為了嘗試和練手，我申請了 AWS EC2 micro instance （一年免費使用的主機），內存為 1G.
在安裝 ElasticSearch, Logstash, Kibana 的過程中，整個過程還是比較順利，但是也遇到了一個非常頭疼的問題，就是 Kibana 的 X-Pack 無論如何也安裝不上，一直卡在 "Optimizing and caching browser bundles..."，顯示如下。
[root@ELK kibana]# bin/kibana-plugin install x-pack Attempting to transfer from x-pack Attempting to transfer from https://artifacts.elastic.co/downloads/kibana-plugins/x-pack/x-pack-5.6.3.zip Transferring 119488769 bytes.................... Transfer complete Retrieving metadata from plugin archive Extracting plugin archive Extraction complete Optimizing and caching browser bundles...
然後整個主機無響應，在 AWS 控制臺觀察到安裝時的CPU使用率多達到 100%，在AWS 控制臺重啟實例，重新安裝並使用 top 命令觀察，發現1G內存基本被耗盡 （957128k used），弄到淩晨也無法入睡（top - 00:32:22 up 4 min）。
top - 00:32:22 up 4 min, 2 users, load average: 0.92, 0.55, 0.24 Tasks: 84 total, 2 running, 82 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 1.4%sy, 0.0%ni, 0.0%id, 97.9%wa, 0.0%hi, 0.0%si, 0.7%st Mem: 1017296k total, 957128k used, 60168k free, 80k buffers Swap: 0k total, 0k used, 0k free, 2052k cached
如果同時還有其他命令窗口，輸入命令時會出線錯誤提示： fork: Cannot allocate memory
第一個想法是觀察並停止內存使用比較多的服務來釋放空間，最後連 amazon-ssm-agent，sendmail 都停止了，但依舊無法解決。當時真的有個沖動去購買一個內存大的主機，但是多大的內存才合適，我並沒有底，弄得太晚只能睡覺去了。第二天，在地鐵上，下班後不斷的搜索 X-Pack 相關的指導，最終從一篇安裝 的經驗中得到提示。
“你可能會等待不知道多久才成功：（所以建議調大虛擬機的內存和處理器的核數）”原文鏈接 [1]
經過檢查，發現虛擬內存 (swap) 空間為 0，但 CPU 使用率並不高，所以可以采用以時間換空間的辦法（CPU時間換內存空間），增加虛擬內存，這便是第二個方案。
第二方案的具體步驟如下：（我增加了 4 G 虛擬內存）
- 檢查內存
[root@ELK kibana]# free -m
total used free shared buffers cached
Mem: 993 224 768 0 13 163
-/+ buffers/cache: 47 945
Swap: 0 0 0
- 生成 swap 使用的文件
[root@ELK swap]# dd if=/dev/zero of=swap_4G bs=1024000 count=4000
4000+0 records in
4000+0 records out
4096000000 bytes (4.1 GB) copied, 62.7646 s, 65.3 MB/s
[root@ELK swap]# mkswap swap_4G
Setting up swapspace version 1, size = 3999996 KiB
no label, UUID=39c72236-feb2-4dd6-bc5d-d2906891de3f- 加載 swap
[root@ELK swap]# swapon swap_4G
swapon: /opt/swap/swap_4G: insecure permissions 0644, 0600 suggested.
[root@ELK swap]# chmod 600 swap_4G- 成功
[root@ELK swap]# free -m
total used free shared buffers cached
Mem: 993 930 62 0 14 838
-/+ buffers/cache: 77 915
Swap: 3906 0 3906- 如果需要在重啟開機時自動加載，則加入到 /etc/fstab 文件，如：
[root@ELK swap]# vi /etc/fstab
#
LABEL=/ / ext4 defaults,noatime 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/opt/swap/swap_4G swap swap defaults 0 0
加載 SWAP 成功後再次安裝 Kibana X-Pack plugin，大功告成，整個安裝過程耗時20分鐘左右
[root@ELK kibana]# bin/kibana-plugin install x-pack
Attempting to transfer from x-pack
Attempting to transfer from https://artifacts.elastic.co/downloads/kibana-plugins/x-pack/x-pack-5.6.3.zip
Transferring 119488769 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Extracting plugin archive
Extraction complete
Optimizing and caching browser bundles...
Plugin installation complete
安裝過程中也通過 top 觀察 CPU 和內存狀態。swap 空間的使用超過 1.5G，swap 服務kswapd0 也啟動，但 CPU 使用率並不高，說明從內存與文件系統上的虛擬內存(swap) 的數據遷移消耗的計算資源並不多，這種時間換空間的辦法是很有效的。
top - 22:09:20 up 10 min, 2 users, load average: 1.80, 1.26, 0.59
Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.1%us, 1.0%sy, 0.0%ni, 0.0%id, 95.8%wa, 0.0%hi, 0.0%si, 1.0%st
Mem: 1017292k total, 949620k used, 67672k free, 812k buffers
Swap: 3999996k total, 1532452k used, 2467544k free, 11904k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2801 root 20 0 2514m 620m 2188 R 6.0 62.4 3:13.32 node
633 root 20 0 0 0 0 S 1.0 0.0 0:04.16 kswapd0小結：
- 在內存受限的情況下，可以采用時間換空間的辦法來改善；反之亦然，在計算資源要求很高時，可以增加內存，比如核心交易系統可以在啟動時將盡量多的內容預先加載在內存並預分配空間。
- 采用此方法，可以利用好雲資源，而不是一味的用錢解決問題，做到最經濟實用。
- 平時對一些技術基礎進行深入的理解和測試練習，可以更快的預知到問題所在，快速解決。
引用：[1]: https://segmentfault.com/a/1190000010981283
AWS EC2 安裝 Kibana X-Pack 插件的內存不足問題