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

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

    声明: 作者:Yongfeng01 出处:http://www.cnblogs.com/yongfeng01 转载需声明出处。
  • 相关阅读:
    几个华为5300交换机故障的意思和可能产生的原因
    怎么让win7右下角只显示时间不显示日期 ?(可行)
    Linux下LDAP统一认证解决方案
    教你如何禁用U盘、屏蔽USB端口的三种方法
    开机自动启动一个新建文件夹
    端口
    输//ip提示找不到应用程序
    java单向加密算法小结(2)--MD5哈希算法
    java单向加密算法小结(1)--Base64算法
    Git初探--笔记整理和Git命令详解
  • 原文地址:https://www.cnblogs.com/Yongfeng001/p/8030355.html
Copyright © 2020-2023  润新知