|
Bonjour,
ravi que la solution fonctionne,
pour informations supplémentaire, mais je ne pense pas que tu en
es besoin, mais les optimisations sur Linux peuvent aller beaucoup
plus loin, grâce au "SMP affinty", qui permet sur des processeurs
multicœur de répartir la gestion des interruptions entre cœur,
soit en modifiant soit même les valeurs d'IRQ dans /proc/irq (et
en vérifiant dans /proc/interrupts), ou en utilisant le daemon
irqbalance qui permet de faire la répartition des interruptions
entre cœurs.
Dans le cas du réseau, cela peux être intéressant lorsque que le
contrôleur réseau (NIC) à plusieurs file (queue) d'envois (tx) et
de réception (rx), il est alors possible de répartir les
interruptions entre cœurs.
un exemple sur un serveurs qui à une contrôleur réseau avec deux
files :
$ cat /proc/interrupts | egrep "CPU|12[6-9]"
CPU0 CPU1 CPU2 CPU3
126: 21 11003583 5731788 7610247 IR-PCI-MSI
1048577-edge enp2s0-rx-0
127: 4 120315 1111185 196090 IR-PCI-MSI
1048578-edge enp2s0-rx-1
128: 24 1734333 3689960 2396735 IR-PCI-MSI
1048579-edge enp2s0-tx-0
129: 23 1021631 3880657 2893540 IR-PCI-MSI
1048580-edge enp2s0-tx-1
On peux voir, dans mon cas, que pour une file "rx-0" la
répartition est faite sur les 4 cœurs, mais il serait possible de
réserver le CPU0 à rx-0, le CPU1 à rx-1, le CPU2 à tx-0 et bien
sur CPU3 à tx-1.
Enfin pour dire que les solutions d'optimisation sous Linux sont
gigantesques, mais pas toujours très simple à appréhender (je
parle pour moi :) ), et surtout à utiliser dans les bonnes
situations.
Bonne fin d’années à tous.
Loïc
Le 29/12/2018 à 08:53, JUPIN Alain a
écrit :
Bonjour,
Loin de moi l'idée de ne pas vouloir donner de retour, mais
j'attendais que le temps passe pour voir si la solution est
pérenne dans le temps. Et c'est le cas.
A priori, le seul fait d'avoir passé la gestion des tso, gso et
gro par le CPU suffit à résoudre mon problème.
Pour l'uso, il ne semble pas poser de problème, mais il faut dire
qu'hormis le DNS (qui n'est qu'un cache local pour le serveur), je
n'en fais pas usage.
Merci à vous
Le 18/12/2018 à 14:29, Yahoo a
écrit :
Bonjour,
je n'avais pas encore vue cette erreur, mais en modifiant le
gso (generic-segmentation-offload) gro
(generic-receive-offload) et tso (tcp-segmentation-offload:),
tu n'as pas touché a (ufo) udp-fragmentation-offload settings
Tu peux quand même vérifier si les options sont bien à off
avec ethtool -K <int> .
Sinon, pour info, mais c'est sûrement déjà fait, il faut bien
inscrire les modifications au démarrage du serveur, sinon les
modifications seront perdus après "reboot",
pour ma part je les ajoute en post-up dans le fichiers des
interfaces.
Tiens nous au courant si cela à fonctionné.
Loïc
Le 18/12/2018 à 10:26, JUPIN Alain
a écrit :
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.
|