linux: veel system time na wijzigen cpufreq/scaling_max_freq

[thunder7]

Mijn vraag

Ik heb een workstation die 24x7 processen draait op 100% load.
Overdag maakt dat te veel herrie, dus om 07:30 doe ik

code:

#!/bin/bash
ls /sys/devices/system/cpu/*/cpufreq/scaling_max_freq | while read cpu_freq
do
   echo "2800000" > $cpu_freq
done

en dan om 17:30 weer

code:

#!/bin/bash
ls /sys/devices/system/cpu/*/cpufreq/scaling_max_freq | while read cpu_freq
do
   echo "3500000" > $cpu_freq
done

waarbij 3.5 GHz inderdaad de 'normale' maximale turbo-frequentie is. Het is een dual xeon E5-2696 V2 systeem, met een all-core turbo van 3.1 GHz.

Dit werkt goed, de temperatuur komt kennelijk net onder de grens dat het bios de cpu-fans op maximaal zet en het geluid blijft beschaafd. De performance op 2.8 GHz t.o.v. 3.1 GHz is ook prima.

Maar: na 17:30 is er een sterk verhoogd percentage system-time (zo'n 20-24 %) volgens top.
Na een reboot is dat weer weg, dus het lijkt een gevolg van het spelen met dat maximum frequentie-bestand.
Het lijkt ook alsof de performance niet helemaal terug komt waar het moet zijn, maar dat is lastig te meten.

Het is een HP Z620, 2x E5-2696 V2, 384 Gb geheugen, ssd, en hij draait 48 WCG/Boinc processen.
OS is Ubuntu 18.04 lts.

Iemand enig idee wat die system time is, of hoe ik er zelfs maar achter kom wat er in die tijd precies gebeurt?

Om het extra spannend te maken:

pidstat -u laat bij geen enkel proces meer dan 0,04% system time zien, en het totaal van die processen komt zeker niet aan de door top genoemde 20-24%.

[ Voor 7% gewijzigd door thunder7 op 02-10-2020 20:23 ]

[Hero of Time]

Waar had je je informatie vandaag om de frequentie te zetten? Ik zie iig op de Archi wiki (https://wiki.archlinux.org/index.php/CPU_frequency_scaling) nog andere methoden dan handmatig. Wellicht geven die betere resultaten?

[_JGC_]

In plaats van klooien met de frequentie kan je ook de intel_pstate module gebruiken en daarbij turbo boost uitschakelen als je stilte wilt.

[thunder7]

Dat gaan we maandagmorgen maar eens proberen dan...

[thunder7]

OK, de snelheid gaat prima omlaag en omhoog, maar ik zie nog steeds verschil tussen mijn workstations.

De 'goede':

code:

top - 18:14:22 up 18 days, 10:06,  1 user,  load average: 82.79, 83.15, 83.23
Tasks: 807 total,  80 running, 725 sleeping,   2 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy, 99.8 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  32055.1 total,  13485.0 free,  10544.2 used,   8025.9 buff/cache
MiB Swap:  16269.0 total,  16269.0 free,      0.0 used.  21041.2 avail Mem

en de slechte:

code:

top - 18:15:24 up 2 days, 21:45,  1 user,  load average: 49,79, 49,95, 49,94
Tasks: 563 total,  49 running, 514 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,1 us,  7,9 sy, 92,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem : 386895,6 total, 347957,8 free,   5802,8 used,  33135,0 buff/cache
MiB Swap:  19323,0 total,  19323,0 free,      0,0 used. 378237,7 avail Mem

7.9% systemtime op een systeem wat verder geen taken heeft dan WCG uitvoeren?
Ik kan me niet goed voorstellen wat er hier speelt. Het systeem heeft veel meer dan genoeg geheugen (384 Gb), / is gemount op een SSD, iotop laat niets bijzonders zien, wie zit daar aan mijn cpu tijd te snoepen?

8% is toch 4 cores, zeg maar.

Iemand enig idee hoe ik er achter kom welk(e) proces(sen) dit veroorzaken?

[Hero of Time]

Heb je al eens met atop gekeken?

[thunder7]

Ik heb geen idee wat ik daarin moet zien eigenlijk.

[Hero of Time]

Dat er totaal >800% CPU tijd in system zit, maar de CPU gebruikende processen (de paar die je nog kan zien), maar 0,01 seconden bezig zijn daarmee.

Oftewel, het komt niet door je zware processen, maar iets anders. Ik ben niet zo bekend met de toetsen en config van atop, maar zoek even op hoe je de cpu's in de lijst kan verbergen of inkorten. Want er is nu een hele hoop dat je niet kan zien omdat er 48 cores individueel worden weergegeven.

[thunder7]

Ik moet wel even nadenken als iemand om een uitdraai van atop vraagt, en dan zegt 'ik ben er niet zo bekend mee'. Die was wat onverwacht. Maar, ik ben bang dat het verbergen van de cpu's in de lijst niet alle helpt, want nu is de lijst vooral de 48 WCG processen:

[Hero of Time]

Het is iig een heel stuk beter dan de bovenste 3. Want die hadden geen system time, een paar anderen zoals je zelf ook kan zien wél.

Hoe makkelijk/moeilijk/ingrijpend is het om je wcg processen te herstarten? Zie je dan nog steeds veel syscpu?

Ik ben niet zo bekend met atop net zoals ik niet bekend ben met top zelf. De toetsen die de verschillende views tonen kan ik nooit onthouden en vind htop veel fijner. Maar atop laat daarentegen veel meer zien over het proces zelf, zoals IO e.d. Het is daarom best een handige tool om eens in te kijken om te zien wat er nou precies gebeurt op je systeem en waar de resources heen gaan.

[thunder7]

Dat zijn losse processen die door de BOINC service gestart wordt n.a.v. een gedownloaded unit. Hoewel het theoretisch vermoedelijk niet onmogelijk is om individuele processen te herstarten, is dat praktisch wel wat lastig. Zo'n proces schrijft eens in de zoveel tijd een checkpoint weg naar schijf, dus de server herstarten kan (maar dan heb je wat rekentijd verspild). Een individueel proces herstarten lijkt me lastig - command line arguments, path, zorgen dat de BOINC-service de PID weet, evt. communicatie tussen BOINC-service en processe (via wat?), kortom, ingewikkeld.

[BCC]

Kan je BOINC niet met signals vertellen dat hij ff moet herstarten?

- blijkbaar niet helaas https://boinc.mundayweb.c...ignals_list_used_in_BOINC

[ Voor 43% gewijzigd door BCC op 06-10-2020 11:32 ]

[Hero of Time]

Als je zo bang bent voor het verliezen van rekentijd, waarom zit je dan eigenlijk constant de snelheid van je CPU te veranderen? Er zijn meer methodes om een stil systeem te krijgen, zonder zo 'ingrijpend' met de clock speed te spelen.

[thunder7]

Er zit m.i. een verschil tussen overdag op werkdagen 20% langzamer gedurende 8 uur i.v.m. het geluid, of 24x7 8% 'weggeven' aan system time. Maar ik zal straks een kijken of het percentage system time reageert op een herstart van de boinc client (en de geassocieerde taken).