Utilizarea procesorului ca un procent simplu nu poate transmite complexitatea unui procesor și memorie cu mai multe nuclee, fire multiple, unități de execuție multiple. Aproape sigur CPU este de fapt blocat pe memorie sau cache. Iar procesele care au datele lor se vor lupta pentru unitățile de execuție.
Acest procesor are doar 16 nuclee. Tratându-l ca și cum ar avea 32 va degrada la un moment dat performanța grav, așa cum ați descoperit. Chiar și cu SMT 2. Poate că puteți obține numărul de fire la 125% din nuclee (20), dar 175% (28) îl împinge. Mai ales cu alte lucruri care rulează. Înapoi firele.
Asigurați-vă că calculați munca utilă efectuată pe fir pe secundă. Experimentează, schimbând câte o variabilă. Poate încercați procesoare cu diferite configurații de cache și număr de nuclee, dacă aveți acces la acestea.
Măsurați cât de blocat sunteți cu contoarele de monitorizare a performanței. Nu va funcționa într-un VM, dar merită încercat pe Linux. De la Gregg pe care l-am legat mai devreme:
perf stat -a -- somn 10
Viteza maximă teoretică pe Xeons este de 4 sau 5 instrucțiuni pe ciclu. Nu veți obține asta, dar < 1.0 IPC este în plus blocat în memorie.
Cu siguranță înțelegeți codul aplicației și punctele fierbinți. Ce funcții petrec cea mai mare parte a timpului pe procesor? Ce cod de asamblare este afectat cel mai tare? Ce unități de execuție de pe procesorul dvs. lucrează cel mai mult pentru a procesa aceste operațiuni?
Grafice de flacără sunt bune pentru vizualizarea funcțiilor CPU. Ați menționat EL 8, care are scule flamegraph ambalate.
yum install perf js-d3-flame-graph
# la nivel de sistem, 99 Hz, timp de 60 de secunde
perf script flamegraph -a -F 99 sleep 60
O înțelegere la nivel de dezvoltator a programului este necesară pentru a interpreta pe deplin rezultatele. Cu simboluri sau cod sursă, rapoartele perf pot fi adnotate într-o experiență de tip debugger.
