SCHED_ULE tuning

[Kamikaze]

Ich arbeite im Moment auf einem Rechner mit bloß 256MB Ram. Da wird bei einem Portupgrade oder beim Arbeiten mit Eclipse viel Ausgelagert (oft über 500MB).

Ich habe jetzt mit dem Sysctl Parameter kern.sched.interact herumgespielt. Wenn ich den Wert auf 100 erhöhe, werden bei einem Portupgrade selbst Mausbewegungen extrem rucklig übernommen. Wenn ich den Wert auf 0 senke, wird das Verhalten deutlich besser. Vor allem Tastatureingaben erfolgen mit deutlich weniger Verzögerung als das beim Standardwert 30 passiert. Der Preis dafür ist, dass das Portupgrade länger dauert, da es bei bedarf gnadenlos aus dem Speicher gekickt wird.

Auch der Moused wird sofort komplett in den Swap ausgelagert, wenn ich die Maus mal 'ne Sekunde lang nicht bewege, trotzdem bleibt das System aber trotz des massiven Speichermangels gut verwendbar.

Hat jemand anderes ähnliche Erfahrungen gemacht?

 

[Yamagi]

Noch nicht, aber danke für die Erfahrung. Vielleicht gibt mir das einen neuen Ansatz herauszufinden, wieso Plattenaktivität das System in den Tod reißen kann.

 

[Kamikaze]

Ich denke mal, dass HD-IO nicht so viel CPU-Zeit oder Arbeitsspeicher zieht, es sei denn du verwendest verschlüsselte oder komprimierte Partitionen. Es könnte natürlich sein, dass sich zu schnell zu viele Soft-Updates im Speicher sammeln, aber das wäre schon ein ziemlich fatales Problem.

 

[Elwood]

Wobei das Swappen natürlich auch gewisser Stress für die Platte ist und Zeit braucht

 

[Kamikaze]

Ich vermute mal, dass Yamagi's Rechner nicht an dem gleichen Speichermangel leidet wie meiner.

 

[Yamagi]

Nein, darum ging es nicht. Ich bin immer noch an den in FreeBSD-Allgemein so groß und breit diskutierten Performanceproblemen dran. Ich habe eine Vermutung wo das Problem liegen könnte, muss das aber erst noch einmal weiter evaluieren. kern.sched.interact könnte dabei helfen den Scheduler ein für alle mal auszuschließen. Der Logik nach kann er nicht Schuld sein, aber ich hätte es halt gern handfest bewiesen.

Für dich hier sicher uninteressant, aber Jeff Roberson hat eine neue Version des sched_ule in der Pipeline, welche anders als die aktuelle Variante die Topologie der Prozessoren im System beachtet. Die Auswirkungen sind durchaus interessant: http://people.freebsd.org/~kris/scaling/mysql-16cpu.png

 

[Endorphine]

[...]Jeff Roberson hat eine neue Version des sched_ule in der Pipeline, welche anders als die aktuelle Variante die Topologie der Prozessoren im System beachtet. Die Auswirkungen sind durchaus interessant: http://people.freebsd.org/~kris/scaling/mysql-16cpu.png

Wie kann man sich das vorstellen, ist das eine Art NUMA-Awareness für AMD K8/K10 Multi-Sockel Systeme? Und woher bezieht der Scheduler seine Topologie-Kenntnisse?

 

[Yamagi]

Ließ am besten selbst: http://jeffr-tech.livejournal.com/17426.html

 

[Endorphine]

Ließ am besten selbst: http://jeffr-tech.livejournal.com/17426.html

Danke. Klasse, auf genau sowas warte ich schon, seit das Gerücht auftauchte, dass Intel simultanes Multithreading ("Hyperthreading") einführen möchte.

Erstaunlich, dass erst jetzt die Quadcores scheinbar so wenig ausgenutzt werden (oder gar Performance verlieren), so dass endlich Dinge wie NUMA-Awareness im Scheduler implementiert werden.

Schade nur, dass man mit einfachen Single-Sockel Dualcores ohne Hyperthreading (o.ä.) nicht davon profitieren wird, sondern erst ab Quadcore oder Multi-Sockel Systemen, wo nicht alle Kerne gleichberechtigt sind.