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 <[email protected]>: > Valérie P <[email protected]> : > [...] > > 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/
