Valérie P <lago...@gmail.com> : [...] > 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/
