Estou monitorando um host com a ajuda do Zabbix e notei que o agente do Zabbix começou a usar vários ciclos de 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
Existem cerca de 100 itens monitorados com o agente. Eles também são monitorados em outros hosts idênticos, onde o agente Zabbix não consome muito da CPU. Agentes enviam dados coletados para o proxy Zabbix. A configuração do agente é padrão. A CPU do host tem 8 núcleos (2,4 Gz). O menor valor de tempo para itens monitorados é de 60 segundos.
Eu uso o servidor Zabbix / agent 1.8.11 e não posso atualizar para o 2.2 pelo menos agora.
Eu verifiquei o log de depuração de todos os lados: servidor Zabbix, proxy, agente e não consigo encontrar nenhum problema lá. Apenas verificações usuais recebidas e enviadas o tempo todo.
Eu não sei como investigar mais esta questão e pedir ajuda da comunidade. Como eu poderia rastrear por que o agente está consumindo tanto CPU?
Mais uma coisa que parece estranha para mim são as estatísticas das conexões de rede:
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
Obrigado.
Atualização 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 - IP do servidor Zabbix
10.120.0.3 - IP do host Zabbix
Atualização 2.
Essas conexões TIME_WAIT são do nginx do servidor web.
Atualização 3.
Eu anexei o processo de agente do Zabbix com strace e pareceu que 100% é usado por agentes no read syscall :
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
Atualização 4.
Apenas para esclarecer tudo ... Eu tentei trabalhar com o estado de conexões TIME_WAIT. Por exemplo, tentei diminuir net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait e net.netfilter.nf_conntrack_tcp_timeout_time_wait e ver se isso ajuda. Infelizmente, isso não ajudou.
Conclusão
O problema de carga da CPU do agente Zabbix parecia estar associado ao número de conexões da rede. Se nos conectarmos ao processo zabbix_agentd usando strace, veremos como os ciclos de CPU são usados (coluna de 1-ponto - tempo de CPU gasto rodando no kernel):
% 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
Aqui, a maior parte do tempo da CPU é usada nas chamadas do sistema lidas. Investigações posteriores mostraram que essas chamadas de leitura (duas delas são mostradas abaixo) são tentativas contínuas de ler o arquivo /proc/net/tcp . O último contém estatística de rede, como conexões TCP e UDP, soquetes, etc. Em média, o arquivo contém 70000-150000 entradas.
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>