konstante CPU-Last erzeugen

phlox81

dEUs schrieb:

Und dann? Serverdienst, Lastmaschinen, hä? Wie hilft mir das alles konstant eine CPU-Last zu erzeugen?

Du wolltest wissen wie man von ausserhalb Last erzeugt.
Ist natürlich nur sinnvoll, wenn man auch eine Applikation hat, die das als Test benötigt.

Würde nachwievor über die Anzahl der Threads gehen.
Bzw. deren Aufgaben.

rapso

falls du zwei rechner zur verfuegung hast, koennte der testrechner davon einen timecritical thread erzeugen und in kurzen intervalen (z.b. nach 1000 durchlaeufen einer schleife) blocked ein byte per tcp erwarten, ein zweiter rechner koennte dann je nach auslastungswunsch die packete schicken, das sollte dann relativ konstant laufen.

btw. http://msdn2.microsoft.com/en-us/library/ms686342.aspx

pale dog

die vorschläge werden ja immer abenteurlicher

Hab mal ein bisschen rum probert. Solange die CPU Zeit von meinem Prozess über 50% war konnte man es durch ändern der Werte ganz gut einstellen, aber alles was drunter war, hat nur noch kurzzeitige schwankungen und keine konstante CPU Zeit erzeugt.

int main() {
	double m = 20;
	double n = 9;
	while(true) {
		for(int j = 0; j<130; j++){
			if(j == 0) Sleep(1);
			for(long i = 0; i< 500; i++) {
				m += cos(sqrt(m));
				m -= cos(sqrt(m));
				n *= cos(m);
				m += n;
				n -= sin(m + i);
				m -= n;
			}
		}
	}
	std::cout<<m;
}

thordk

wie wärs, nen real time thread zu starten, der entsprechend der nötigen last alle paar system ticks wieder schlafen gelegt wird?

dEUs

@TomasRiker:
Der Speicherverbrauch ist einfach zu extrem. 1,5GB bei 1500 Threads!

@rapso:
Runtertackten und Thread anhalten sind beides keine Optionen.
Das mit dem Paketen versteh ich nicht - wofür die Pakete?

@ha lustig:
Werde ich mal austesten, danke.

@thordk:
Habe so etwas ähnliches schon versucht, werde es aber genau so nochmals testen.

Danke für die rege Beteiligung!

Gerard

probie doch mal ob mal mit vmware, virtual pc, quemu usw. aus

wahrscheinlich kann man da die last einstellen, entwäder läst du dann deine app in der virtuelen umgebung laufen oder in der virtuelen umgebung ein thread der 100% auslastung in der vm erzeugt (aber da die vm eingestelt ist auf eine bestimte last, erzeugt er auf deiner maschiene z.b. nur 50%)

dEUs schrieb:

TomasRiker schrieb:

dEUs schrieb:

klappt nicht.

Mit Sleep(1) kriegt man verschiedene Werte hin, nicht nur nahe 100%.
Z.B. haben 5000 Threads bei mir eine Auslastung von ca. 25% erzeugt. Bei 10000 war die Auslatung dann allerdings schon bei 90%.

Das ist keine Option. Erstens ist das auch nciht konstant und zweitens verbrauchen schon 500 Threads bei mir knapp ein halbes GB virtuellen Arbeitsspeicher!

dann lasse die threads etwas mehr machen als while(true)sleep(1) dann brauchst du keine 500 threads mehr

unter linux erzeuge ich immer last in den ich auch cat /dev/random > /dev/null lesen lasse, ich glaube wenn man die daten vorher durch dd sendet kann man auch einstellen wie viel byte pro sek gelesen werden

ich denke du hast auch ein problem mit den messen, was windows unter cpu last versteht ist wahrscheinlich zu ungenau für dich, wobei ich mich sowieso frage was macht es für ein sin zu sagen "unser applikation läuft gut mit 50% cpu last, diese 50% last müssen aber konstant sein" was in der relaität aber ehr die ausnahme ist

phlox81

dEUs schrieb:

@TomasRiker:
Der Speicherverbrauch ist einfach zu extrem. 1,5GB bei 1500 Threads!

mit was erzeugst du denn die Threads?

TomasRiker

Ach, jetzt weiß ich auch, was du meintest, dEUs.
Für jeden Thread muss ja im virtuellen Adressraum ein Bereich reserviert werden. Ich hatte nur den tatsächlichen Speicherverbrauch gesehen. Mit einem 64-Bit-OS ist das kein Problem

man kann ja die stack size kleinerer machen

TomasRiker

Jo, das klappt tatsächlich:

CreateThread(0, 16, threadProc, 0, STACK_SIZE_PARAM_IS_A_RESERVATION, &id);

rapso

dEUs schrieb:

@rapso:
Runtertackten und Thread anhalten sind beides keine Optionen.
Das mit dem Paketen versteh ich nicht - wofür die Pakete?

wenn du einen thread auf critical priority stellst bekommst du 0 reaktion vom rechner, hast du eine blocked socket verbindung, steht der thread und du hast doch noch cpu-zeit fuer andere dinge. und wieviel gewartet wird kannst du dann mit dem anderen pc kontrollieren indem du halt haeufiger daten schickst fuer mehr auslastung und seltener fuer weniger auslastung. der critical priority thread ist deswegen so "nett" weil er vermutlich immer gleich viel rechenzeit dann zieht, egal wieviele normal-priority dinge du startest.
ansonsten kannst du dich nicht drauf verlassen, da abhaengig von IO usw. jedes OS die threads anders scheduled.

dEUs

Und wo ist der Unterschied zu nem Sleep?

thordk

dEUs schrieb:

Und wo ist der Unterschied zu nem Sleep?

sehe keinen. besonders nicht unter "consumer OSes", die sich jeden fitzel möglicher resourcen gleich unter den nagel reissen und wild verteilen.

rapso

dEUs schrieb:

Und wo ist der Unterschied zu nem Sleep?

mit sleep bekommst du wohl nur ne aufloesung von 10ms oder schlechter, bei nem blocked socket koenntest du (iterrupts usw. sei dank) sehr viel feiener die unterbrechungen machen.

thordk

also jetzt mal ganz von der eigentlichen diskussion ab: warum ist es nötig, ein programm unter einer bestimmten cpu last zu testen? läuft es immer nur auf einem bestimmten rechner? solange ein programm ausschließlich von rechenzeit abhängig ist, sind jegliche tests auf last unnötig, da es linear skalieren wird.

pale dog

thordk schrieb:

warum ist es nötig, ein programm unter einer bestimmten cpu last zu testen? läuft es immer nur auf einem bestimmten rechner? solange ein programm ausschließlich von rechenzeit abhängig ist, sind jegliche tests auf last unnötig...

das sehe ich genau so. vielleicht sollte dEUs mal genauer beschreiben, was er testen will...

dEUs

Das System ist äußerst komplex.
Es sind mehrere externe Systeme angeschlossen die Daten liefern (SPS etc). Diese Daten müssen abgespeichert werden. Dafür ist ein Zeitstempel notwendig. Und der wird auf dem Rechner erzeugt. Und wenn der unter Last steht, werden die Zeitstempel zu spät erzeugt und die Daten sind unbrauchbar.

Der Sinn des Tests ist ganz einfach:
"Leute, wenn ihr sinnvolle Daten wollt, dann guckt, dass eure CPU-Auslastung unter x% bleibt. Wenn ihr das nicht gewährleisten könnt, dann holt euch ne dickere Maschine"

rapso

eine sehr seltsame art minspec heraus zu finden, wir haben dafuer immer verschiedene rechner und benchmarken wie es auf denen laeuft, statt ein programm nebenbei kuenstlich last erzeugen zu lassen.

zudem gibt es andere lasten als cpu z.b. stalls wegen HDD die 0 cpu-last haben.

dEUs

Viel Spaß das auf diese Art bei diesem Produkt zu machen