Агент Zabbix – высокое использование ЦПУ

Я мониторю хост с помощью 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. Конфигурация агента по умолчанию. CPU хоста имеет 8 ядер (2.4 ГГц). Минимальное время для мониторинга элементов составляет 60 секунд.

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

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

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

Еще одна вещь, которая кажется мне странной – статистика сетевых соединений:

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

Процесс 23776 отсоединён
% 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 и посмотреть, поможет ли это. К сожалению, это не помогло.

Заключение

Проблема нагрузки CPU агента Zabbix оказалась связанной с количеством сетевых соединений. Если мы прикрепимся к процессу zabbix_agentd с помощью strace, мы увидим, как используются циклы CPU (1-й столбец – время 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. Последний содержит сетевую статистику, такую как подключения 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>

Я думаю, что узким местом является диск. Вот мои причины для этого:

У вас довольно загруженный веб-сервер. Zabbix медленный, я подозреваю, что это из-за чтений с диска (возможно, также из сети).

Запустите strace снова и найдите дескриптор файла в Zabbix.

Затем узнайте, является ли дескриптор файла файлом или сокетом:

ls -l /proc/<PID_of_straced_process>/fd/<FD_from_strace>

EDIT1:
Вам не следует изменять таймауты TIME_WAIT. Проблема с маленьким HTTP keep-alive или с отсутствием HTTP keep-alive заключается в том, что вы увеличиваете задержку и пропускную способность. Вместо этого вам следует немного увеличить HTTP keep-alive и установить/включить SPDY.

EDIT2:
Используйте dstat -ta 10 и сравните первую строку с остальными. Первая строка – это среднее значение с момента загрузки. Следующие строки – это 10-секундное среднее значение (последний параметр).

EDIT3:
Проверьте, нет ли у вас потерь пакетов, используйте что-то вроде smokeping для мониторинга сервера и сайта снаружи вашей сети. У вас значительное количество соединений в состоянии CLOSING, FIN_WAIT1, FIN_WAIT2, SYN_RECV, LAST_ACK. Я думаю, что ваша сеть перегружена или у вас много соединений с коротким сроком жизни (подтверждено высоким соотношением TIME_WAIT/ESTABLISHED). См. http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation

zabbix-agentd читает /proc/net/tcp для элемента net.tcp.listen. Размер файла составляет около 100K(строк) * 150 байт = 15MB, если у вас много tcp.listen мониторинговых элементов, эта операция чтения файла потребляет много CPU из-за того, что размер данных составляет 15MB*количество_элементов.

Рекомендуется использовать net.tcp.port вместо net.tcp.listen для этой проблемы с производительностью.

Поздний ответ (может быть полезен для некоторых):

Это происходит довольно часто, в зависимости от того, что вы запрашиваете с помощью Zabbix, и обычно это проблема третьей стороны или PEBKAC.

Отключите проверки (и перезапустите сервер zabbix после), чтобы узнать, какая из них вызывает такую большую нагрузку. Проанализируйте проблему соответственно.

Например, у меня были несколько проблем с мониторингом базы данных, когда ODBC вызывал проблему.