У меня есть сервер Ubuntu 14.04, который иногда выпускает "NOHZ: ошибки 08 дюймов local_softirq_pending к журналу dmesg. Это запустилось после обновления до ядра 4.4; ранее это работало без проблемы о 3,16 ядрах. Вот выборка от конца журнала:
[ 7.805258] audit: type=1400 audit(1484883362.092:11): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/sbin/dhclient" pid=1636 comm="apparmor_parser"
[ 10.605443] igb 0000:c1:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 10.605545] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 19.219187] ixgbe 0000:02:00.1 p4p2: NIC Link is Up 10 Gbps, Flow Control: None
[ 19.219368] IPv6: ADDRCONF(NETDEV_CHANGE): p4p2: link becomes ready
[ 52.010390] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 52.089283] init: plymouth-upstart-bridge main process ended, respawning
[ 2857.027773] perf interrupt took too long (2542 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 7195.391731] perf interrupt took too long (5012 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[37277.461862] perf interrupt took too long (10050 > 10000), lowering kernel.perf_event_max_sample_rate to 12500
[239795.500056] NOHZ: local_softirq_pending 08
[579047.644110] NOHZ: local_softirq_pending 08
[837865.916051] NOHZ: local_softirq_pending 08
Это - производственный хост базы данных с 32 ядрами под достойным объемом загрузки.
Я задаюсь вопросом, должен ли я быть обеспокоен этими сообщениями, и раз так как я мог бы пойти об устранении проблемы.
Ядро детализирует здесь:
[ 0.000000] Linux version 4.4.0-59-generic (buildd@lcy01-32) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #80~14.04.1-Ubuntu SMP Fri Jan 6 18:02:02 UTC 2017 (Ubuntu 4.4.0-59.80~14.04.1-generic 4.4.35)
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.4.0-59-generic root=UUID=5db4a2c8-24f4-409b-b437-6120682cc518 ro noautogroup transparent_hugepage=never nomdmonddf nomdmonisw
Добавьте nohz=off
к параметрам ядра во время начальной загрузки для отключения его.
Эта опция заставляет RCU пытаться ускорить льготные периоды, чтобы позволить центральным процессорам вводить dynticks-состояние-ожидания более быстро. , С другой стороны, эта опция увеличивает издержки dynticks-неактивной проверки, особенно в системах с большими количествами центральных процессоров.
Вы, кажется, затронуты полужирной частью.
[еще 119] чтение...