我在Zabbix的帮助下监视主机，我发现Zabbix代理开始使用相当多的CPU周期：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26774 zabbix 20 0 68428 1312 752 R 99 0.0 63:27.67 /usr/sbin/zabbix_agentd 26773 zabbix 20 0 68428 1324 764 R 99 0.0 63:26.33 /usr/sbin/zabbix_agentd 代理商监控的项目大约有100个。 在Zabbix代理程序不占用太多CPU的其他相同主机上也会监视它们。 代理发送收集到的数据到Zabbix代理。 代理configuration是默认的。 主CPU有8个核心（2.4 Gz）。 监控项目的最小时间值是60秒。
我使用Zabbix服务器/代理1.8.11，至less现在我不能升级到2.2。
我从各方检查debugging日志：Zabbix服务器，代理，代理，并找不到任何问题。 只是通常的检查收到和发送所有的时间。
我不知道如何进一步调查这个问题，并寻求社区的帮助。 我怎么能跟踪为什么代理消耗CPU这么辛苦？
还有一件事对我来说很陌生，就是networking连接的状态：
netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 2 CLOSE_WAIT 21 CLOSING 3521 ESTABLISHED 2615 FIN_WAIT1 671 FIN_WAIT2 1542 LAST_ACK 14 LISTEN 256 SYN_RECV 117841 TIME_WAIT
谢谢。
更新1。
netstat -tnp|grep zabbix tcp 1 0 10.120.0.3:10050 10.128.0.15:53372 CLOSE_WAIT 23777/zabbix_agentd tcp 1 0 10.120.0.3:10050 10.128.0.15:53970 CLOSE_WAIT 23775/zabbix_agentd tcp 1 0 10.120.0.3:10050 10.128.0.15:53111 CLOSE_WAIT 23776/zabbix_agentd
10.128.0.15 – Zabbix服务器的IP地址10.120.0.3 – Zabbix主机的IP地址
更新2。
那些TIME_WAIT连接来自web服务器nginx。
更新3。
我使用strace连接到Zabbix代理进程，似乎在read syscall代理使用了100％：
strace -C -f -p 23776 Process 23776 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 2.175528 2515 865 read ------ ----------- ----------- --------- --------- ---------------- 100.00 2.175528 865 total
更新4。
只是为了清楚所有事情…我试图与TIME_WAIT连接状态一起工作。 例如，我试图减lessnet.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait和net.netfilter.nf_conntrack_tcp_timeout_time_wait ，看看是否有帮助。 不幸的是，这并没有帮助。
结论
Zabbix代理CPU负载问题似乎与networking连接数绑定。 如果我们使用strace附加到zabbix_agentd进程，我们将看到如何使用CPU周期（第一列 – 在内核中运行的CPU时间）：
% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 15.252232 8646 1764 read 0.00 0.000000 0 3 write 0.00 0.000000 0 1 open ... ------ ----------- ----------- --------- --------- ---------------- 100.00 15.252232 1778 total
这里大部分CPU时间用于读取系统调用。 进一步调查显示，这些读取调用（其中2个如下所示）是不断尝试读取/proc/net/tcp文件。 后者包含networking统计信息，如TCP和UDP连接，套接字等。平均而言，该文件包含70000-150000个条目。
8048 0.000068 open("/proc/net/tcp", O_RDONLY) = 7 <0.000066> 8048 0.000117 fstat(7, {st_dev=makedev(0, 3), st_ino=4026531993, st_mode=S_IFREG|0444, st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=0, st_size=0, st_atime=2013/04/01-09:33:57, st_mtime=2013/04/01-09:33:57, st_ctime=2013/04/01-09:33:57}) = 0 <0.000012> 8048 0.000093 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f30a0d38000 <0.000033> 8048 0.000087 read(7, " sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode "..., 1024) = 1024 <0.000091> 8048 0.000170 read(7, " \n 6: 0300810A:0050 9275CE75:E67D 03 00000000:00000000 01:00000047 0000000"..., 1024) = 1024 <0.000063>
我认为瓶颈是光盘。 这是我的原因：
你有一个非常繁忙的networking服务器。 Zabbix速度慢，我怀疑是从磁盘读取（也可能是从networking上）。
再次运行strace，并在Zabbix中find文件描述符
然后查找文件描述符是文件还是套接字：
ls -l /prod/<PID_of_straced_process>/fd/<FD_from_strace>
编辑1 ：
您不应该更改TIME_WAIT超时。 小HTTP保持活动或没有HTTP保持活动的问题是增加了延迟和带宽。 相反，你应该增加一点HTTP保持活跃和安装/启用SPDY。
编辑2 ：使用dstat -ta 10并比较其余的第一行。 第一行是自启动以来的平均值。 下一行是平均10秒（最后一个参数）。
编辑3 ：检查你是否丢失了数据包，使用类似smokeping的方法从networking外监视服务器和网站。 在CLOSING，FIN_WAIT1，FIN_WAIT2，SYN_RECV，LAST_ACK中有大量的连接。 我认为你的networking拥挤，或者你有很多短暂的连接（由高的TIME_WAIT / ESTABILISHED比率确认）。 请参阅： http : //en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation
zabbix-agentd通过net.tcp.listen项目读/ proc / net / tcp。 文件大小约为100K（行）* 150bytes = 15MB，如果你有很多tcp.listen监视器项目，这个读取文件操作会消耗很多cpu，数据大小为15MB * item_number。
build议使用net.tcp.port而不是net.tcp.listen来解决这个性能问题。
迟到的答案（可能对某些人有帮助）：
通常情况下，这取决于你对Zabbix的要求，通常是第三方问题或PEBKAC。
禁用检查（并在之后重新启动zabbix服务器）以查看哪一个导致重负载。 相应地分析问题。
即当ODBC导致问题时，我有数据库监视器的几个问题