Bonjour, Merci pour le retour, j'avais effectivement lu sur des forums la même chose (chez un autre hébergeur). Et en effet, les gro et gso sont gérés par la carte NIC Features for eno1: Cannot get device udp-fragmentation-offload settings: Operation not supported tcp-segmentation-offload: on generic-segmentation-offload: on generic-receive-offload: on
L'opération a été effectuée cette nuit, je vais voir si cela est efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) ! Pour info, j'ai quand même eu le retour suivant à la commande ethtool -K eno1 gso off gro off tso off Cannot get device udp-fragmentation-offload settings: Operation not supported Cannot get device udp-fragmentation-offload settings: Operation not supported Alain JUPIN Le 17/12/2018 à 16:42, Yahoo a écrit : > > 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. >> >> -- >> Alain JUPIN >> Lumières d'Ici ... et d'Ailleurs <http://www.jupin.net>
