J'ai un serveur Ubuntu 14.04 qui émet occasionnellement des erreurs "NOHZ: local_softirq_pending 08" dans le journal dmesg. Cela a commencé après la mise à niveau vers le noyau 4.4; auparavant, il fonctionnait sans problème sur un noyau 3.16. Voici un extrait de la fin du journal:
[ 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
C'est un hôte de base de données de production avec 32 cœurs sous une charge décente.
Je me demande si je devrais être préoccupé par ces messages et, le cas échéant, comment résoudre le problème.
Détails du noyau ici:
[ 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
Ajoutez nohz=off
aux paramètres du noyau lors du démarrage pour le désactiver.
Grâce à cette option, RCU tente d’accélérer les délais de grâce afin de permettre aux processeurs de passer plus rapidement à l’état dynticks-inactif. D'autre part, cette option augmente les coûts liés à la vérification dynticks-idle, en particulier sur les systèmes dotés d'un grand nombre de processeurs.
Vous semblez être affecté par la partie audacieuse.
Plus de lecture ...