主页 / server / 问题 / 922751
Accepted
John Virgolino
Asked: 2018-07-20 11:52:29 +0800 CST

Nagios 4.4.1 在大约 1 周后缓慢爬行，CPU 使用率经常达到 100%

  • 772

我们正在 Ubuntu 16 服务器上运行一个新的 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

在此处输入图像描述

linux

1 个回答

  1. Best Answer

    我最终通过在 Nagios 网站上与社区合作部分解决了这个问题。这是解决方案：

    1) 根据他们的建议，从 Githib 下载、编译和安装 Nagios 的工作版本。Nagios (4.4.1) 版本中存在一个错误，该错误会导致主机/服务保持软状态，从而导致更频繁地进行重新检查。

    维护分支：https ://github.com/NagiosEnterprises/na ... tree/maint

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

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

    • 0

相关问题