Zabbix агент - высокая загрузка ЦП

Я слежу за хостом с помощью Zabbix и заметил, что агент Zabbix начал использовать довольно много циклов ЦП:

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 агент не потребляет столько ресурсов ЦП. Агенты отправляют собранные данные на Zabbix прокси. Конфигурация агента по умолчанию. Главный процессор имеет 8 ядер (2,4 ГГц). Наименьшее значение времени для отслеживаемых элементов составляет 60 секунд.

Я использую Zabbix сервер / агент 1.8.11, и я не могу обновиться до 2.2 по крайней мере сейчас.

Я проверил журнал отладки со всех сторон: Zabbix сервер, прокси, агент и не нашел там никаких проблем. Постоянно получаемые и отправляемые обычные чеки.

Я не знаю, как исследовать эту проблему дальше и обратиться за помощью к сообществу. Как я могу отследить, почему агент так сильно загружает процессор?

Еще одна вещь, которая мне кажется странной, - это статистика сетевых подключений:

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 - IP Zabbix сервера 10.120.0.3 - IP Zabbix хоста

Обновление 2.

Эти соединения TIME_WAIT исходят от веб-сервера nginx.

Обновление 3.

Я подключился к процессу агента Zabbix с помощью strace, и оказалось, что 100% используется агентами на 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

Обновление 4.

Просто чтобы все стало понятно ... Я пробовал работать с состоянием соединений TIME_WAIT. Например, я пытался уменьшить net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait и net.netfilter.nf_conntrack_tcp_timeout_time_wait и посмотрите, поможет ли это. К сожалению, это не помогло.

Вывод

Проблема загрузки ЦП Zabbix агента оказалась связана с количеством сетевых подключений. Если мы подключимся к процессу zabbix_agentd с помощью strace, мы увидим, как используются циклы ЦП (1-й столбец - время ЦП, затраченное на работу в ядре):

% 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

Здесь большая часть времени ЦП используется для системных вызовов чтения. Дальнейшее расследование показало, что эти вызовы чтения (2 из них показаны ниже) представляют собой постоянные попытки прочитать /proc/net/tcp файл. Последний содержит сетевую статистику, такую ​​как 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>