Je confirme ce que te dit Florian, certaines mises à jour du microcode
corrigent soit directement une faille, soit corrigent une faille de
concert avec l'OS (principalement le kernel).
Je te conseille d'utiliser le script spectre-meltdown-checker qui fait
un diagnostic de l'état du système vis à vis de chaque faille.
Tu y découvriras pour chaque faille le ou les pré-requis au niveau du
micro-code et/ou de l'OS:
https://github.com/speed47/spectre-meltdown-checker
Cela te permettra potoentiellement de downgrader le microcode pour
revenir à tes anciennes performances.
A noter, le micro-code se met à jour:
- soit par flashage du BIOS
- soit par chargement du microcode au boot de ta machine:
- via un initrd (prise en compte en début de boot)
- via un service (prise en compte plus tard dans la phase de boot)
De plus, tu as remarqué une dégradation de l'usage CPU mais l'impact
principal de ces correctifs concernent tout ce qui est relatif aux
appels systèmes donc principalement les I/O car à chaque appel système
depuis le user-space, il faut flusher le cache du CPU !
J'ai pu remarqué des pertes de l'ordre de 30% notamment sur les accès
disques en écriture aléatoire.
Ces correctifs sont vraiment vicieux car à chaque correctif, Intel nous
dit que l'impact est de l'ordre de quelques pourcents mais tout les
correctifs cumulés entrainent de sérieuses régréssions des performances
au final.
Cordialement,
--
--------------------------------------
Jean-François Maeyhieux
Atanar Technologies
http://www.atanar.com
--------------------------------------
Le mardi 17 décembre 2019 à 17:50 +0100, Greg a écrit :
> Oui, et en cas d'absence de ces microcodes, les protections ne
> peuvent fonctionner, et donc c'est comme si elles étaient
> désactivées.
>
> Le mar. 17 déc. 2019 à 16:48, Florian Stosse <
> florian.stosse@gmail.com> a écrit :
> > Hello,
> >
> > A tout hasard, est ce que tu appliques également les mises à jour
> > du microcode Intel à la volée lors du boot, avec le paquet intel-
> > microcode ? La différence de performances peut aussi venir de là.
> >
> > --
> > Florian STOSSE | Ingénieur en sécurité informatique
> >
> >
> > Le mar. 17 déc. 2019 à 16:26, Greg
greg-frsag@duchatelet.net a
> > écrit :
> > > Bonjour,
> > >
> > > Les derniers Kernel semblent plus mauvais en terme de
> > > performance.
> > > Un serveur fonctionnait sur un kernel "maison" 4.14, j'ai voulu
> > > le remettre en kernel officiel Debian Buster donc 4.19, les
> > > performances se sont écroulées: hausse de la conso CPU, du load,
> > > et augmentation des temps de réponse PHP de l'ordre de +50% !
> > > Le dernier kernel 5.3 n'apportera aucune solution.
> > >
> > > On peut depuis le 5.2 désactiver les protections contre les
> > > failles de sécurité affectant tous les processeurs modernes (pas
> > > que Intel, mais aussi ARM, AMD et MIPS) avec le paramètre de boot
> > > mitigations=off
> > > C'est mieux, mais je ne retrouve pas les perfs du 4.14 (conso CPU
> > > et temps de réponse).
> > >
> > > Lien vers la doc sur ces paramètres:
> > >
https://linuxreviews.org/HOWTO_make_Linux_run_blazing_fast_(again)_on_Intel_...
> > >
> > > Voilà ce que ça donne sur un serveur en production :
> > >
> > >
> > >
> > >
> > > Savez vous ce qu'il faudrait faire pour retourner au niveau de
> > > perf du 4.14 ?
> > >
> > > Merci !
> > > --
> > > Greg
> > > _______________________________________________
> > > Liste de diffusion du FRsAG
> > >
http://www.frsag.org/
>
>
> _______________________________________________
> Liste de diffusion du FRsAG
>
http://www.frsag.org/
