Re: [FRnOG] [TECH] Loadbalancing CPU & Adresse IP paire...

2016-04-29 Par sujet Valérie P 
Merci François et merci Vincent pour vos pistes, je vais regarder ça entre
aujourd'hui et lundi je pense :)

Bonne journée,

Valérie

2016-04-28 23:53 GMT+02:00 Francois Romieu :

> Valérie P  :
> [...]
> > Premier message sur la liste, j'espère vous fournir directement les
> > informations attendues et que certains d'entre vous jouent parfois avec
> du
> > système/chiffrement. ;)
>
> Oui mais plutôt tendance raton laveur.
>
> [...]
> > Avez-vous déjà observé un tel comportement? Vous auriez des pistes pour
> > mieux comprendre ce qu'il se passe?
>
> Au pif:
> - Le traitement par lot qui est effectué en contexte softirq peut être
>   interrompu avant épuisement complet de son budget et reporté à une
>   invocation ultérieure de ksoftirqd s'il provoque le réveil d'un
> processus.
>   Ca n'explique pas pourquoi ksoftirqd consomme plus dans un cas que dans
>   l'autre.
> - Si l'application n'utilise véritablement qu'un seul socket (IPSec => UDP,
>   ça peut être plausible, vérifiez ce que fait Strongswan) et que la carte
>   réseau ne présente qu'une seule file de réception, à taux de paquets
> élevé,
>   il vaut mieux effectuer la ventilation des trames depuis un seul
> processeur
>   (i.e.: appliquer un masque restrictif au /proc/irq/xx/smp_affinity
> kivabien)
>   et ne pas forcément multiplier à outrance les processeurs en charge du
>   traitement protocolaire réseau (cf
> /sys/class/net/eth0/queues/rx-Y/rps_cpus).
>   Peut-être - de plus en plus au pif - que le changement de parité de
>   l'adresse IP du serveur ventile deux fois plus les trames reçues avec
>   comme conséquence une augmentation de la contention sur la ligne de cache
>   du verrou de la socket schtroumpf.
> - ethtool -k ethX ?
> - perf top ?
>   Si crépage de chignon pour la même ligne de cache on peut s'attendre à
>   retrouver en tête un spinlock_machinchose (ou un passant innocent qui
> paie
>   pour les autres)
>
> --
> Ueimor
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Loadbalancing CPU & Adresse IP paire...

2016-04-28 Par sujet Francois Romieu 
Valérie P  :
[...]
> Premier message sur la liste, j'espère vous fournir directement les
> informations attendues et que certains d'entre vous jouent parfois avec du
> système/chiffrement. ;)

Oui mais plutôt tendance raton laveur.

[...]
> Avez-vous déjà observé un tel comportement? Vous auriez des pistes pour
> mieux comprendre ce qu'il se passe?

Au pif:
- Le traitement par lot qui est effectué en contexte softirq peut être
  interrompu avant épuisement complet de son budget et reporté à une
  invocation ultérieure de ksoftirqd s'il provoque le réveil d'un processus.
  Ca n'explique pas pourquoi ksoftirqd consomme plus dans un cas que dans
  l'autre.
- Si l'application n'utilise véritablement qu'un seul socket (IPSec => UDP,
  ça peut être plausible, vérifiez ce que fait Strongswan) et que la carte
  réseau ne présente qu'une seule file de réception, à taux de paquets élevé,
  il vaut mieux effectuer la ventilation des trames depuis un seul processeur
  (i.e.: appliquer un masque restrictif au /proc/irq/xx/smp_affinity kivabien)
  et ne pas forcément multiplier à outrance les processeurs en charge du
  traitement protocolaire réseau (cf /sys/class/net/eth0/queues/rx-Y/rps_cpus).
  Peut-être - de plus en plus au pif - que le changement de parité de
  l'adresse IP du serveur ventile deux fois plus les trames reçues avec
  comme conséquence une augmentation de la contention sur la ligne de cache
  du verrou de la socket schtroumpf.
- ethtool -k ethX ?
- perf top ?
  Si crépage de chignon pour la même ligne de cache on peut s'attendre à
  retrouver en tête un spinlock_machinchose (ou un passant innocent qui paie
  pour les autres)

-- 
Ueimor


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Loadbalancing CPU & Adresse IP paire...

2016-04-28 Par sujet Vincent Bernat 
 ❦ 28 avril 2016 17:37 +0200, Valérie P  :

> Premier message sur la liste, j'espère vous fournir directement les
> informations attendues et que certains d'entre vous jouent parfois avec du
> système/chiffrement. ;)
>
> Je suis en train de faire quelques tests de chiffrement avec la solution
> Strongswan 5.1.2 (version fournie de base) entre deux serveurs Ubuntu 14.04
> en lab.
>
> Les comportements des deux serveurs étaient différents, les CPU de l'un
> étant quasi inutilisés (0,3% en moyenne) quand sur le second serveur la
> moitié des CPU est utilisée (tous les CPU impairs) le sont à 100%. Un top
> montre que ce sont les process ksoftirqd/x qui montent très haut dans les
> tours.
>
> En regardant de près, la seule différente entre les deux chiffreurs est
> située au niveau de leurs adresses IP. Côté "WAN" (ou du côté du trafic
> chiffré), le chiffreur 1 a l'adresse 10.0.0.1, le chiffreur 2 : 10.0.0.2
>
> - En changeant l'adresse du chiffreur 2 pour 10.0.0.3, le taux
> d'utilisation des CPU tombe à 0.3%
> - En changeant l'adresse du chiffreur 1 pour 10.0.0.4, le taux
> d'utilisation des CPU monte à 100% sur la moitié des CPU présents.
>
> J'ai suspecté d'abord irqbalance qui affecteraient des smp_affinities
> différentes aux deux chiffreurs, mais elles sont similaires. J'imagine
> qu'il y a un hash quelque part chez qui le dernier bit de l'adresse IP
> change quelque chose, mais à ce point!
>
> Avez-vous déjà observé un tel comportement? Vous auriez des pistes pour
> mieux comprendre ce qu'il se passe?

Si la carte est multiqueue, le hash se fait sur le couple d'adresses IP
et le protocole (cela se change éventuellement avec ethtool). Pour
savoir si la carte est multiqueue, tu peux vérifier quel est son qdisc
(avec ip l l, mq = multiqueue) ou alors checker avec "cat
/proc/interrupts".

Quel est la carte réseau ? ethtool -i eth0

Ensuite, il faut voir ce que sont les CPU pairs. Tu peux obtenir la
topologie de tes CPU avec:

 grep . /sys/devices/system/cpu/cpu*/topology/*_list

irqbalance va affecter chaque IRQ avec un ou plusieurs CPU. Vérifie
avec :

 grep . /proc/irq/*/smp_affinity_list

Regarde aussi dans /proc/interrupts quelle est la queue la plus
sollicitée.

Ensuite, trouver un lien entre la topologie et l'affinité CPU. Je trouve
très surprenant une telle différence. Le système est-il NUMA (lscpu le
dit) ?

Essaie sans HT ou avec irqbalance désactivé voir si cela change quelque
chose. Regarde aussi avec perf top (installe le paquet de debug pour le
noyau pour y voir plus clair).
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Loadbalancing CPU & Adresse IP paire...

2016-04-28 Par sujet Valérie P 
Bonjour à tou(te)s,

Premier message sur la liste, j'espère vous fournir directement les
informations attendues et que certains d'entre vous jouent parfois avec du
système/chiffrement. ;)

Je suis en train de faire quelques tests de chiffrement avec la solution
Strongswan 5.1.2 (version fournie de base) entre deux serveurs Ubuntu 14.04
en lab.

Les comportements des deux serveurs étaient différents, les CPU de l'un
étant quasi inutilisés (0,3% en moyenne) quand sur le second serveur la
moitié des CPU est utilisée (tous les CPU impairs) le sont à 100%. Un top
montre que ce sont les process ksoftirqd/x qui montent très haut dans les
tours.

En regardant de près, la seule différente entre les deux chiffreurs est
située au niveau de leurs adresses IP. Côté "WAN" (ou du côté du trafic
chiffré), le chiffreur 1 a l'adresse 10.0.0.1, le chiffreur 2 : 10.0.0.2

- En changeant l'adresse du chiffreur 2 pour 10.0.0.3, le taux
d'utilisation des CPU tombe à 0.3%
- En changeant l'adresse du chiffreur 1 pour 10.0.0.4, le taux
d'utilisation des CPU monte à 100% sur la moitié des CPU présents.

J'ai suspecté d'abord irqbalance qui affecteraient des smp_affinities
différentes aux deux chiffreurs, mais elles sont similaires. J'imagine
qu'il y a un hash quelque part chez qui le dernier bit de l'adresse IP
change quelque chose, mais à ce point!

Avez-vous déjà observé un tel comportement? Vous auriez des pistes pour
mieux comprendre ce qu'il se passe?

Merci par avance!

Bonne fin d'après-midi,

Val

---
Liste de diffusion du FRnOG
http://www.frnog.org/