Bonjour,
Il semble que la carte réseau à du mal à gérer la segmentation
des paquets,
dans ce cas là, il peux être bien de décharger cette opération
au CPU.
d'après les logs ton serveur hébergé, tu est sur une carte NIC
intel (e1000e), qui as du mal a décharger.
Vérifie si ta carte NIC gère le déchargement de la segmentation
de paquets :
ethtool -k <interface>
pour le savoir vérifier les ligne (gso et gro) :
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
si elles sont à on c'est que c'est la carte NIC qui le gére,
essaye de les passer à off pour que ce soit le CPU qui le
gérent
ethtool -K <interface> gso off gro off tso off
(attention cela peux engendre une perte de connexion, à faire
en KVM)
J'ai dèjà eu le soucis sur des serveurs, mais avec
l'utilisation de QoS.
En espérant pouvoir aider
Loïc
Le 17/12/2018 à 14:26, JUPIN Alain a
écrit :
Bonjour,
Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner
Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante,
plus de réponse au ping sur l'IP principale du serveur, d'où le
déclenchement d'un reset "Hard".
Évidemment j'essaye de trouver la cause de ce plantage.
Je n'ai rien trouvé du coté du disque dur (via smartctl).
Mais j'ai ceci dans le log "syslog". Lors du plantage, cette
séquence a débuté à 10h57 (heure du serveur qui est en UTC), à
11h03 j'ai perdu le ping, elle a perdurée jusqu'à 11h08, heure
du reboot par OVH.
Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e
0000:00:19.0 eno1: Detected Hardware Unit Hang:
Dec 17 11:02:33 cygnus kernel: [408638.686407]
TDH <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
TDT <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
next_to_use <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
next_to_clean <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
buffer_info[next_to_clean]:
Dec 17 11:02:33 cygnus kernel: [408638.686407]
time_stamp <10615a7a6>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
next_to_watch <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
jiffies <10615b058>
Dec 17 11:02:33 cygnus kernel: [408638.686407]
next_to_watch.status <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC
Status <40080083>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY
Status <796d>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T
Status <3800>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended
Status <3000>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI
Status <10>
Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e
0000:00:19.0 eno1: Reset adapter unexpectedly
Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port
1(eno1) entered disabled state
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained
carrier
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not
set address: Permission denied
Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC
Link is Up 1000 Mbps Full Duplex, Flow Control: None
Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port
1(eno1) entered blocking state
Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port
1(eno1) entered forwarding state
Par contre, bien que je sois en train d'investiguer, j'ai bien
compris qu'un problème ce produit sur l'interface Ethernet, mais
je ne sais pas quoi précisément.
Avez vous une idée sur ce qui peut être à l'origine de ceci ?
PS : J'attends aussi une réponse d'OVH sur la question.