AWS EC2 安装 Kibana X-Pack 插件的内存不足问题

时间:2021-09-26 20:09:21

最近在学习 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. 在内存受限的情况下,可以采用时间换空间的办法来改善;反之亦然,在计算资源要求很高时,可以增加内存,比如核心交易系统可以在启动时将尽量多的内容预先加载在内存并预分配空间。
  2. 采用此方法,可以利用好云资源,而不是一味的用钱解决问题,做到最经济实用。
  3. 平时对一些技术基础进行深入的理解和测试练习,可以更快的预知到问题所在,快速解决。

引用:[1]: https://segmentfault.com/a/1190000010981283