Follow

Je co-galère à trouver pourquoi un serveur que je co-administre s'est mis subitement à bloquer son processeur à une fréquence basse. Le serveur est lent depuis des mois, et on est un peu désespérés.

J'ai décrit le problème ici superuser.com/questions/165227 (en anglais).

(ce serveur sert à héberger un chatons.org affinitaire)

Merci d'avance <3.

· · Web · 8 · 31 · 4

@octalish pour la forme, y a-t-il une grosse différence de performances si tu désactives les mesures contre les vulnérabilités Spectre/Meltdown?

(juste pour tester, il n'est évidemment pas conseillé de tourner en production sans contre-mesures)

@octalish
Est-ce que t'as vérifié s'il chauffe? C'est peut-êtne une protection matérielle?

@octalish intel_pstate=disable acpi=force peut-être ?

@octalish Et aussi : modprobe sbs, speedstep-lib, acpi-cpufreq

@octalish Tu peux lancer sensors ? (lm-sensors) J’ai eu le cas d’une sonde thermique défaillante qui indiquait constamment 95°C provoquant un bridage de sécurité sans raison une fois.

@breizh Tout a l'air largement bon :

acpitz-acpi-0
Adapter: ACPI interface
temp1: +27.8°C (crit = +105.0°C)
temp2: +29.8°C (crit = +105.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +38.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +38.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +36.0°C (high = +100.0°C, crit = +100.0°C)

@octalish

faudrait tenter un truc du genre
echo -n 2001000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

avec la bonne fréquence et le bon num de cpu pour voir comment il chouinne qu'il veut pas.

@herve_02 Déjà tenté, rien ne chouine, la valeur est settée mais ça ne fonctionne pas non plus.

@octalish
alors ça dépasse mes compétences.

j'ai peut être un idée. Il y a quelques temps, pour mitiger la faille melt down et spectre, une mise à jour du noyal a fait perdre de la performance.

on est certain que le proc ne tourne pas à son max et que c'est pas le system qui est achement lent ?

@octalish Des pistes comme ça, je sais pas si c'est possible de transférer la prod sur un serveur de secours le temps des tests mais:


Différent-e-s distro/release/microcode intel (paquet intel-microcode sur les .deb)/noyau ? Haswell datant de 2013 les microcodes des distro de 2014~2015 doivent être les plus adaptés/testés (Buster c'est 2019, tester avec le paquet microcode de la release précédente éventuellement) ? Avec le temps lis microcodes/pilotes sont moins bien testés sur les anciennes acrhi, la priorité étant sur les nouveaux modèles (j'ai ça avec un pilote GPU Intel SandyBridge) et il y a donc des risques de régression laissé de côté.

Qu'est-ce que ça donne dans le bios par curiosité, ça permettrait peut être d'identifier rapidement si c'est un problème système ou matériel ?

Et un petit troll en complément (désolé), Skylake est la génération qui a suivit Haswell et comme les problèmes ont du commencer avant : https://www.pcmag.com/news/former-intel-engineer-explains-why-apple-switched-to-arm

@popolon Pour le BIOS ; je n'ai pas d'accès physique à la machine, donc ça devrai attendre, mais c'est effectivement une bonne piste (je ne sais pas si il y a accès à l'info de la fréquence actuelle du CPU cela dit).

Merci pour l'idée sur les microcodes ; (j'imagine que changer de microcode demande un reboot également).

@octalish

Effectivement, ça dépend des BIOS, très probablement, celui d'un PC x86 de bureau que j'ai (carte Asus) permet de voir ça et de régler différents paramètres (surchargés par Linux après le boot), les bios plus standard de serveur permettent au moins de voir certains paramètres comme température etc, je pense que la fréquence aussi, à vérifier. Je me pose la question avec les TPM comme on peut bloquer certaines action du système depuis le BIOS, si ça ne serait pas une autre possibilité ? Je lance des pistes, mais c'est peut être pas du tout ça.

dans le paquet l'installation fait (dans le script postinst), un update-initramfs, et ça n'est chargé qu'au boot suivant.

Il y a plusieurs versions en deb pour Debian, ce qui est pas mal :
https://packages.debian.org/search?keywords=intel-microcode

Pour la doc:
https://wiki.debian.org/fr/Microcode

La version en anglais est un peu plus complète : https://wiki.debian.org/Microcode

Et la doc d'ArchLinux est encore plus complète;

https://wiki.archlinux.org/title/Microcode

@popolon En fait… Je n'ai aucun paquet intel-microcode d'installé. Ça peut être un souci ça ?

@popolon installé intel-microcode ; redémarré…

🎉 !

Ça semble redevenu normal ; fréquence du processeur n'est plus cantonnée aux 800MHz où elle était bloquée.

Je croise les doigts et surveille, mais MERCI à tou·tes pour votre aide et vos idées !

<3 @kicou @metaphys @hypra @breizh @herve_02 @arthurlutzim @kaulian <3

@octalish
T'as utilisé quelle commande pour passer au governor performance ? cpufreq-set ?

@octalish j'ai pas creusé mais est-ce que tu pourrais essayer `cpufre-set -g performance` et `cpufred-get` (si tu as cpufreqd qui tourne). Est-ce que vous avez ltp installé ? Est-ce que powertop affiche des choses ?

@arthurlutzim je l'ai installé :

root@yourte:~# cpufreqd-get

Name (#1): Performance High
Active on CPU#: 0, 1, 2, 3
Governor: performance
Min freq: 2600000
Max freq: 2600000

[…]

(mais ça ne change rien)

@arthurlutzim Non pas pareil, moi je ne suis pas bloqué sur un governor. Je peux changer le governor et j'utilise bien le driver intel_pstate… Mais juste tous ces paramètres n'ont pas d'effet sur la réalité et les outils continuent à parler d'une fréquence de ~200MHZ ou 800MHz selon l'outil…

@octalish tu as tenté de demarrer sur un livecd pour voir si soucis os ou materiel ?

Sign in to participate in the conversation
La Quadrature du Net - Mastodon - Media Fédéré

Mamot.fr est une serveur Mastodon francophone, géré par La Quadrature du Net.