Nagios 4.4.1 大约一周后爬行速度变慢,并且 CPU 使用率经常达到 100%

Nagios 4.4.1 大约一周后爬行速度变慢,并且 CPU 使用率经常达到 100%

我们正在 Ubuntu 16 Server 上运行新的 Nagios Core 服务器。一切都运行良好,直到今天,突然间,网站变得非常慢。查看 top 命令结果,我们发现 nagios 或 *.cgi 进程(Web UI)的使用率始终保持在 99-100%。没有任何变化。我们还发现轮询延迟急剧增加。我们之前遇到过一次这种情况,并决定删除安装,构建新的编译并部署为新版本。那是几周前的事了,现在我们又回到了同样的情况。还有其他人遇到过这种情况并有解决办法吗?谢谢。

top - 11:33:30 up 7 days, 22:38,  1 user,  load average: 2.00, 1.91, 1.41
Tasks: 161 total,   2 running, 154 sleeping,   0 stopped,   5 zombie
%Cpu(s): 31.1 us,  3.3 sy,  0.0 ni, 63.3 id,  2.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12174388 total,  7690680 free,  1430508 used,  3053200 buff/cache
KiB Swap:  4067324 total,  4067324 free,        0 used. 10267768 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
27230 nagios    20   0  782008 767708   2752 D  87.7  6.3 189:32.12 nagios
16175 www-data  20   0  781988 136336  68412 R  48.5  1.1   0:01.46 status.cgi
16174 sysadmin  20   0   41776   3836   3248 R   0.3  0.0   0:00.01 top
31422 www-data  20   0  296772  11440   3424 S   0.3  0.1   0:00.15 apache2


top - 11:33:33 up 7 days, 22:38,  1 user,  load average: 2.00, 1.91, 1.41
Tasks: 161 total,   2 running, 154 sleeping,   0 stopped,   5 zombie
%Cpu(s): 24.9 us,  0.8 sy,  0.0 ni, 28.4 id, 45.9 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12174388 total,  7550296 free,  1570912 used,  3053180 buff/cache
KiB Swap:  4067324 total,  4067324 free,        0 used. 10127412 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16175 www-data  20   0  922568 413956 205436 R 100.0  3.4   0:04.48 status.cgi
27230 nagios    20   0  782008 767708   2752 D   2.0  6.3 189:32.18 nagios
  323 root      20   0       0      0      0 D   1.0  0.0   0:24.04 jbd2/dm-0-8
    1 root      20   0   37792   5980   4144 S   0.0  0.0   0:10.31 systemd

在此处输入图片描述

答案1

我最终通过与 Nagios 网站上的社区合作解决了这个问题。解决方案如下:

1) 根据 Githib 的建议,下载、编译并安装了 Nagios 的工作版本。Nagios 版本 (4.4.1) 中有一个错误,会导致主机/服务处于软状态,从而导致重新检查的频率更高。

維護分公司:https://github.com/NagiosEnterprises/na... 树/维护

2) 重命名retention.dat和status.dat文件也是必要的,因为它们每个文件的大小都超过8GB。大概是解析这些文件导致了所有的延迟。

从那时起,它已经运行了几个星期,性能没有任何下降。我希望这对其他人有所帮助。

相关内容