FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
uripui schrieb:
[...]
Vielleicht haut der GCC42 einen Bug rein, der genau diese Perfomance-Probleme verursacht?
Zum Vergrößern anklicken....

Halte ich auch für relativ unwahrscheinlich, da das Usprungsproblem auf meinen Kisten (amd64x2/nvidia-Chipsatz) mit dem besagten gcc nicht auftritt. Ausschließen kann man es natürlich nicht.
 
Dummerweise muss ich meine Aussage irgendwo von vor 3 Seiten revidieren, dass mein Laptop hat diese Probleme nicht, er hat sie.

System ist:

Pentium M 1.6Ghz
Intel GMA 900 Chipsatz
eine ATA-HDD an einem internen SATA-Adapter

Problem ist selbes wie auf dem Desktop,, ein "cat /dev/zero > /tmp/muell" lässt die CPU grade mal auf 1.2Ghz hochtakten, aber alle anderen Festplattenzugriffe brauchen >20Sek.

Vllt ist was am ata-scheduler (wtf.. gibts sowas ?) verkorkst.
 
Ich kann selbst auf meinem neuen Dual Core das System mit dd in die Knie zwingen (hohe bs vorausgesetzt). Aber unter realistischen Bedingungen läuft das System wirklich einwandfrei.

Wer dd einsetzt und damit Probleme hat, dem empfehle ich eine sehr kleine Blocksize zu wählen, zum Beispiel bs=512.
 
also ich habe bei meinem dual core mit cat /dev/null > /tmp/muell eine Last von ca. 5%. Mit dd if=/dev/null of=/tmp/muell immerhin 30%, mit höheren bs z.B. 4096 gehts die lat wieder in den Bereich von 5%.
Acha ja und das Ganze auf ein eli-Dateisystem.
 
Zuletzt bearbeitet:
Während ich irgendwann entnervt aus den Diskussionen auf der Mailingliste ausgestiegen bin hat Yamagi weiter den Kontakt gehalten und selbst auch Ursachenforschung betrieben.

Hinter den Kulissen hat sich inzwischen einiges getan und Yamagi hat mich gebeten sein Statement hier zu veröffentlichen, weil ich derjenige bin, der die Mail an current@ formuliert hat.

Yamagi schrieb:
So, Jungs. Hier kommt nun ein abschließender Bericht von den Auswirkungen unser E-Mail und den kurz- sowie längerfristigen Planungen. Vorweg sei erst einmal gesagt, dass die Mail von den Entwicklern gut aufgenommen und in weiten Teilen als konstruktive Kritik aufgefasst wurde. Man war und ist bemüht die geschilderten Probleme zu beseitigen, in einigen Bereichen haben wir auch nur den letzten Anstoß zu Änderungen gegeben.

SCSI:
Das grundlegende Problem an SCSI ist, dass es nur noch wenig Verbreitung hat und auch nur noch wenige Entwickler es produktiv Nutzen. Das Grundsystem CAM wird so im Prinzip von Scott Long allein betreut, viele Treiber sind sogar ohne Maintainer. Eine Änderung ist dort auch nicht absehbar, allerdings sind viele Probleme - so zum Beispiel die defekte Geschwindigkeitsaushandlung in RELENG_7 - wenigstens bekannt. Wer bei SCSI helfen möchte, müsste entweder selbst den Job des Maintainers eines Treibers übernehmen oder zumindest Hardware oder Geld spenden. Was die hier geschilderten Probleme von Juedan betrifft, bei ihm hat sich ein Entwickler gemeldet um diese Lösen zu können.

Problem Reports:
Die Verarbeitung von Problem Reports wird grundlegend umgestalltet, mitdiskutieren kann man auf freebsd-bugbusters@ oder im IRC (EFNet #freebsd-bugbusters). Es gab bereits einen Bugathon im Januar bei dem 200 uralte PR abgearbeitet wurden, weitere werden folgen. Desweiteren sucht man Freiwillige, die sich an der Abrebitung von PR beteiligen, eine Liste aller bisher rekrutierten Personen gibt es unter http://wiki.freebsd.org/BugBusting/Volunteers. Dort findet sich dann auch beschrieben, wie man sich beteiligen kann. Gespannt sein darf man auch auf die weiteren Vorschläge und Diskussionen von Mark Linimon im Rahmen der BSDCan und des zugehörigen Entwicklertreffens.

Performance:
Performanceprobleme sind schwer zu finden, vor allem weil sie nur manchmal auftreten und von der Hardware unabhängig sind. Besser wäre es, die ganze Geschichte würde auseinanderfallen. Trotzdem gab es hier Fortschritte. Seitens der Entwickler wurde uns mitgeteilt, dass von 7.0-RC1 bis 7.0-RC2 durch unsere E-Mail und die gelieferten Daten 17 große Probleme gefunden und behoben werden konnten. Auch das "dd-Problem" ist den Entwicklern so weit bekannt, es ist allerdings nicht von heute auf morgen behebbar. Begründet liegt es im Aufbau des VFS, welcher in der Vergangenheit aufgrund fehlender Kapazitäten nicht mit dem restlichen System mithalten konnte. Zu 8.0 sind allerdings große Arbeiten am VFS geplant, welche im Moment mit dem Umbau von lockmgr() ihren Anfang gefunden haben. Diese werden dann vermutlich auch das "dd-Problem" lösen.
Abschließend sei hier noch einmal gesagt, dass FreeBSD 7.0 einen Paradigmenwechsel darstellt und es ist den Entwicklern wichtig noch einmal auf ihn hinzuweisen. Bis einschließlich 6.3 war FreeBSD ein Einzelprozessorsystem was auch SMP konnte. Ab 7.0 ist es - in anbetracht der Tatsache, dass SMP-Systeme eine rasant steigende Verbreitung erfahren - ein SMP-System was auch auf Einelzcpu-Maschinen läuft. Mit Optimierungen auf SMP. Es liegt hier in der Natur der Sache, das UP-Maschinen irgendwo Geschwindgkeitseinbrüche hinnehmen müssen. Nicht zuletzt aus diesem Grund hat 6.3 noch bis Ende Januar 2010 Unterstützung und ist überhaupt erst erschienen, sodass es erst einmal uneingeschränkt weiterverwendet werden kann.
Zum Vergrößern anklicken....
 
An dieser Stelle noch einmal vielen Dank an Kamikaze für seinen EInsatz :)

Ich werden den Thread nun schließen. Wieso? Ganz einfach. Alles was gesagt werden musste, wurde gesagt. Etwas wirklich produktives gab es schon auf den letzten Seiten nicht mehr. Außerdem zerfällt es hier in mindestens 5 Teildiskussionen, welche nur noch schwer zu trennen sind. Wenn es noch etwas zu sagen gibt, macht bitte neue Threads auf. So bleibt die ganze Sache übersichtlich und wir kommen vielleicht eher vorran.

Hier auch noch mal vielen Dank an alles, dass wir #409 Beiträge zustandegebracht haben und dabei die Diskussion immer sachlich geblieben ist und nicht zu einen Privatkrieg eskalierte. Dies ist leider nicht mehr selbstverständlich.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben