Empfehlung Scheduler für Server - FreeBSD7.0

[worel]

Hallo!

Nachdem viele Server, Xeon/Opteron etc., ja auch mit mehreren Cores daherkommen stellt sich für mich die Frage, ob auch darauf der SCHED_ULE genutzt werden soll?

Das scheue ich ein wenig, da natürlich freebsd-update mit einem selfbacked Kernel nicht läuft. Ich habe die ganze Sache noch nicht so weit verfolgt, aber ist der standard Scheduler in FreeBSD 7.0 wirklich so mies?

Was kann man nun also empfehlen. Natürlich sollte die ganze Sache vor allem STABIL laufen. Na gut, wenn die Performance 25% und besser ist, das wäre evtl. ein Kriterium für ULE.

Eine Frage noch zu freebsd-update:
Wenn der Kernel ansich irgendeinen Vogel hat, kann man das wirklich NUR durch einspielen eines kleinen Patches korrigieren? Es wird ja dann auch nicht nochmal mit neuem Patch kompiliert, so dass die Änderungen am bestehenden Kernel korrigiert werden könnten. Wie geht das also? Für einen wissenden eine evtl. komische Frage, aber derzeit versteh ich das nicht ganz.

lg

 

[Styx]

Nachdem viele Server, Xeon/Opteron etc., ja auch mit mehreren Cores daherkommen stellt sich für mich die Frage, ob auch darauf der SCHED_ULE genutzt werden soll?

Da du ja in einem anderen Thread gesagt hast, dass du aus der Debian-Ecke kommst, wundert es mich doch stark, dass du 7.0 auf einem Server einsetzen willst, zumal es noch nicht mal fertig ist. Ich würde auf einem Produktivserver derzeit nur 6.3 einsetzen. FreeBSD 7 würde ich nicht vor 7.1 verwenden. FreeBSD ist noch nicht ausgereift, 6.3 schon.

Das scheue ich ein wenig, da natürlich freebsd-update mit einem selfbacked Kernel nicht läuft. Ich habe die ganze Sache noch nicht so weit verfolgt, aber ist der standard Scheduler in FreeBSD 7.0 wirklich so mies?

Nö, ist er nicht. Der Eindruck wird nur vermittelt, da ULE unter FreeBSD 7.0 schneller ist als der Standardscheduler, der seit vielen Jahren sehr ordentlich und sauber seinen Dienst tut. ULE ist wohl besser geeignet für DualCore-Systeme, was nicht heißt, dass der BSD-Scheduler da mies ist. Unter 6.3 läuft es zB absolut einwandfrei.

Was kann man nun also empfehlen. Natürlich sollte die ganze Sache vor allem STABIL laufen. Na gut, wenn die Performance 25% und besser ist, das wäre evtl. ein Kriterium für ULE.

Das hängt stark vom Rechner ab und was du eigentlich damit machen möchtest. Auf meinem Desktop-PC (AMD X2 64, 2 GB RAM) liegen sowohl der Standard-Scheduler als auch ULE gut, wobei ULE "gefühlt" einen Tick schneller ist. Gemessen habe ich es aber nicht. 25% hätte ich allerdings deutlich gemerkt, denn ich arbeite sehr speicherintensiv.

 

[Kamikaze]

Nach meiner Einschätzung läuft SCHED_4BSD unter 7.0 deutlich schlechter. Das System hat sich stark geändert und 4BSD wurde nicht dafür entwickelt. Nach meiner Einschätzung läuft unter 7.x ULE deutlich besser, während ich den unter 6.x nie verwenden würde.

 

[Yamagi]

Nun, sagen wir mal so, es kommt darauf an. SCHED_4BSD leidet unter FreeBSD 7.0 mehr denn je darunter, dass er mit mehreren CPUs schlicht überfordert ist. Außerdem berechnet er Prioritäten sehr unvorteilhaft, was bei Interruptthreads und Kernelprozessen - von beiden macht 7.0 sehr stark gebrauch - weh tut.

Jetztendlich kommt es drauf an, und zwar auf mehrere Kriterien. Einmal ist SCHED_ULE kein Standardscheduler. Er läuft stabil und ist eindeutig nicht mehr experimentell, er wird sogar als Tuningmaßnahme empfohlen. Allerdings hat man sich dennoch dafür entschieden ihm ein weiteres Testpublikum zu geben, bevor er der Standardscheduler wird. Dies wird wohl mit 7.1 der Fall sein. Es besteht also zumindest die theoretische möglichkeit, dass SCHED_ULE noch Fehler hat, die in SCHED_4BSD schon vor mehr als 20 Jahren entfernt wurden. Außerdem ist SCHED_ULE nicht in jedem Workload schneller. Bei schlichten Compilerorgien ist er zum Beispiel mit SCHED_4BSD gleich auf oder sogar minimal langsamer. Anders als bei Datenbanken, wo man bis zu 150% Leistungssteigerung sehen kann.

Mein Tipp: Probiere es aus. Nur das wird zu einem klaren Ergebnis führen können.

 

[worel]

Bisher habe ich nur auf Desktop Systemen mit FreeBSD experimentiert.

Server war bisher immer Debian (oder SLES *würg*)
(Arbeitgeber denkt aber über Wechsel nach, zumindest bei neuen Systemen)

Mir ist natürlich auch aufgefallen, dass die Treiberunterstützung unter 7.0 schon wieder eine komplett andere ist als unter 6.2, wie es sich mit 6.3 verhält kann ich nicht sagen.

Die Frage ist, ob ein neuer HP/IBM etc. Server mit einem 6.3 zusammenspielt.

Das Produktionsrelease von 7.0 würdet ihr also nicht auf einem Produktivserver einsetzen (elieber auf 7.1 warten)? Ich meine, Raketensilos oder ein AKW werden damit von mir nicht gesteuert... ;-)

Um nochmal zum Scheduler zurückzukommen:
Auch unter 6.3 hat ein neuer Server vielleicht 8 Kerne. Ist da der Einsatz von 6.x überhaupt noch sinnvoll? Besagtes überfordert sein mit mehreren Kernen etc.
Oder spielt sich die Geschichte wirklich nur auf 7.0 Ebene ab. D.h. dass der 4BSD Scheduler unter 6.x super funktioniert, auch mit mehreren CPU Cores?

 

[Styx]

Das Produktionsrelease von 7.0 würdet ihr also nicht auf einem Produktivserver einsetzen (elieber auf 7.1 warten)? Ich meine, Raketensilos oder ein AKW werden damit von mir nicht gesteuert... ;-)

Nicht? Also jetzt bin ich enttäuscht! @Yamagi und Kamikaze: Bitte sperrt den User worel, da er die Mindestanforderung (Serveradmin eines kleinen Atomkraftwerkes) für eine Usermitgliedschaft in diesem Forum nicht erfüllt!

Ne aber im Ernst: Wenn du zu Hause einen kleinen Fileserver hast, weil du eine Musiksammlung zentral lagern willst, kannst du gerne auch 7.0 verwenden. Ich habe hier in der Firma auch "nur" zwei kleine Server. Der eine ist so eine Art "Allround-Server" mit Routerfunktion, einen Apache und einer MySQL in einer Jail und ein paar kleinen Funktionen der andere ist ein Fileserver, wo die ganzen Geschäftsdaten drauf liegen. Auch wenn wir kein Atomkraftwerk sind und auch keine Raketensilos betreiben, will ich - gerade was den Fileserver anbelangt - keine unnötigen Risiken eingehen. Wenn die Daten auf dem Fileserver weg sind, ist die Firma pleite und ich meinen Job los. (Dann kannst du gerne auch dein Atomkraftwerk explodieren lassen, ist mir dann egal! ) Natürlich gibt es Backups, aber man muss es ja nun nicht heraus fordern

Aber wie Yamagi schon sagte: teste es selber aus!

 

[worel]

Passt jetzt nicht zum Topic, interessant ist es allemal.

Was wird denn nun wirklich für hochsensitive Systeme eingesetzt?

Ich meine, die Schauermeldungen von Kraftwerken die aufgrund eines Windows Virus(!) einen Ausfall hatten wurden ja schon mal gemeldet. Das kann es ja nun echt nicht sein.

Ist wohl vieles davon proprietär, von irgendwelchen Herstellern die kein Mensch kennt.

Aber vielleicht will man oft gar nicht wissen dass ein Windows 98 Rechner in einem AKW die Kühlung steuert

 

[Yamagi]

Wirklich hochsensitive Systeme, wie zum Beispiel die Steuerung eines Atomkraftswerks? Ich weiß, das sie im KKW Brunsbüttel Windows für den nicht nuklearen Teil einsetzen. Der nukleare Teil läuft auf VMS, allerdings sind die Abschaltsysteme rein mechanisch. EIn Computerausfall betrifft also nicht die Abschaltung.

Nun im ernst. Wenn ein System möglichst ausfallsicher sein soll, verbietet sich 7.0 aus Prinzip. Es ist ja das erste Release dieser Codebasis, und ein paar tausend Installationen irgendwelcher Release Candidates können den Testprozess von 6.3 - mehr als drei Jahre Einsatz der Codebasis auf Millionen Systemen - nicht ersetzen. Das heißt nun aber nicht, das 7.0 schlecht wäre. Es läuft hier - noch im Testprozess - teils merklich runder und auch stabiler als ein 6.3.

 

[worel]

Eine letzte Frage stelle ich jetzt nochmal: der 4BSD Scheduler ist in 6.3 also definitiv imstande, auch mit modernen Multicore Systemen sehr gut und performant umzugehen?

 

[Styx]

Also auf meinem Xeon DualCore hier in der Firma läuft er sehr gut. Wie es mit 8 Prozessoren aussieht, kann ich dir allerdings nicht sagen. Auch hier der Tipp: Testen, testen udn dann vielleicht nochmal testen

 

[Yamagi]

der 4BSD Scheduler ist in 6.3 also definitiv imstande, auch mit modernen Multicore Systemen sehr gut und performant umzugehen?

Einmal davon abgesehen, dass 6.3 in Sachen SMP um weiten hinter einem 7.0 hinterherhinkt, ja. SCHED_ULE unter 6.x ist nicht zu gebrauchen, er hat einfach noch zu viele Fehler und ist nicht wirklich optimiert.

 

[worel]

Warum ist dann der ULE Scheduler dann nicht default in 7.0?
Gibts dafür einen Grund?

Edit: ok, habs quasi gefunden. Was ist der Plan? Default in 7.1?

nochn edit: ... steht ja eh schon alles im Thread ...

Danke für eure Antworten!

 

[Daemotron]

Passt jetzt nicht zum Topic, interessant ist es allemal.

Was wird denn nun wirklich für hochsensitive Systeme eingesetzt?

Man brennt die Funktionalität auf einen IC, nachdem man die Korrektheit der Algorithmen in mindestens zwei voneinander unabhängig durchgeführten Verfahren formal bewiesen hat - inklusive periphärer Chips auf der Platine.

 

[j_t]

@worel: Ich kann definitiv bestaetigen, dass Server von HP der Typen DL320,360,380 und ML370 hervorragned mit FreeBSD 6.x und 7.0 laufen. Natuerlich auch mit SCHED_ULE und 4 bzw 8 Kernen.

 

[worel]

Ich spinne den Faden jetzt mal ein bisschen weiter und frage hiermit:

Gibt es eine Seite im Netz welche sich halbwegs objektiv mit der Performance der verschiedenen Systeme auseinandersetzt? (Win, Linux, Unix, BSD etc.)

Klar, ein 100% direkter Vergleich kann wohl nie stattfinden, aber zur Orientierung bzw. aus stillen der Neugier heraus wäre das schon interessant.

Grundsätzlich ist zu sagen dass der Griff zu FreeBSD natürlich und vor allem dadurch gemacht wird, weil es als höchst stabil und ausgereift gilt. Ob jetzt einige MIPS mehr oder weniger ist da eher sekundär. Nur muss man halt auch einsehen dass die "over all" Performance sich ungefähr an jene anderer Systeme orientieren soll.

 

[AndreasMeyer]

Was wird denn nun wirklich für hochsensitive Systeme eingesetzt?

Technische Details zu einem elektronischen Stellwerk, das von der DB Netz AG in Deutschland eingesetzt wird: Sicherheits-Integritätslevel 4 (SIL 4), handelsübliche AMD 486DX/33 MHz-Prozessoren, wobei zwei Prozessoren unabhängig voneinander (andere Peripherie-Chips etc.) auf das gleiche Resultat kommen müssen, bevor eine sicherheitskritische Aktion durchgeführt wird. Betriebssystem ist Eigenentwicklung und vorwiegend in C geschrieben.

Auch bei hochsensitiven Systemen kocht man nur mit Wasser. Mit der Technik allein baut man noch keine hochsensitive Systeme. Wichtig ist vor allem ein durchdachtes Software-Design, dass der Programmierer sehr sauber arbeitet und die Programmierarbeit von möglichst vielen Augen kontrolliert wird (visuelles Code-Review, Gutachten) sowie alle möglichen erdenklichen Fälle durchgetestet werden.

 

[Kamikaze]

Nein, jede Person dreht die Benchmarks so, wie sie die haben will.