FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
Yamagi, Kamikaze,

ihr habt euch nicht lächerlich gemacht. Die Probleme, dass manche Leute einfach keine Infos zu nem Problem liefern kennt wohl auch jeder der Entwickler und sie wissen auch, dass ihr die Infos von Dritten bekommen solltet.
Erstmal ist es halt dumm gelaufen, aber ich bin mir ziemlich sicher, dass wir in absehbarer Zeit die Infos bekommen, wenn mal wieder jemand mit dem Problem auftaucht.

Das ihr die Mail rausgehauen habt war richtig so, auch wenn das Resultat dann in Frust gegangen ist. Gute Arbeit von euch, danke.

CU

Martin
 
Hier die abschließenden Worte von Mark Linimon, welche er heute morgen auf freebsd-current@ geschrieben hat:
On Mon, Jan 21, 2008 at 09:09:48AM +0100, Dominic Fandrey wrote:
> Herewith I apologize for starting this thread. It caused a lot of useless
> noise on your lists and while our members have spent months intensively
> discussing the topic, they are now very reluctant about acquiring the
> information necessary to find the source of their problems.

Unfortunately this doesn't solve anyone's problems :-(

If we haven't opened up the lines of communication about how to get
the specific information that is needed to debug complex problems,
then the complex problems will remain unsolved.

One of the subthreads that was spawned was actually quite productive,
and has led to some ideas about how some of more expert users can
help to work with less expert users on issues like this. (We can
conclude that submitting them to the PR database is only effective
if it happens to catch the attention of a committer on the way in).

IMHO that subthread alone made the whole thread worthwhile -- despite
the rest of the noise. I hope we can build on the postive momentum
and interest from several new contributors.

mcl
Zum Vergrößern anklicken....
 
Ich habe keine Ahnung ob es was hilft, wenn ja, reiche ich die Werte nach:

Ich habe jetzt - ja, nur dafür - FreeBSD-7.0RC1 installiert, mit allen patches die freebsd-update liefert. Allerdings ist das System nur virtualisiert. Ich habe gegenüber einer gleichwertig virtualisierten FreeBSD-6.2 Maschine deutlich Performanceverlust (gefühlt). Bringt das was, soll ich die Werte hier posten?
 
Wurden auch alle Ports neu gebaut? Aufgrund von Änderungen im Threading sind Programme die über die Compat6x Libraries laufen ziemlich lahm.
 
@juedan:
Ich habe deinen aktuellen Artikel über FreeBSD 7 in der FreeX gelesen, puuh, man erkannte leicht negative Schwingungen :) aber der Schluss war ganz Ok. Die LDAP-passwd Anglelegenheit musste natürlich erwähnt werden...

:>
 
Dann kommen jetzt die üblichen Fragen, SCHED_4BSD oder SCHED_ULE? In GENERIC steht immer noch SCHED_4BSD, der meiner Meinung nach aber unter 7.x schlecht funktioniert.

Zu den Scheduler Einstellungen erfährst du alles mit dem Kommando:
# sysctl kern.sched

Ich hatte früher Probleme mit moused, als ich moused deaktiviert und Xorg direkt auf das Device zugreifen ließ, wurde es deutlich besser. Die moused Probleme sind, für mich, aber inzwischen wieder behoben.
 
Ist ein GENERIC Kernel. Und 4BSD aktiv.

Ok, ich werde (evtl. am WE) mal SCHED_ULE auspropieren. Auch werde ich es mal ohne moused versuchen. Wobei (IMHO) ich denke man sollte die Performance-Probleme mit GENERIC bzw. einer Standardinstallation melden. Denn der soll ja schließlich großflächig eingesetzt werden...
 
Am Woe gibt es einen Bugathon, wer helfen will ist aufgerufen dies zu tun.

from Mark Linimon <linimon@lonesome.com>
reply-to freebsd-bugbusters@freebsd.org,
to freebsd-stable@freebsd.org,
cc linimon@freebsd.org,
date Jan 25, 2008 7:38 PM
subject upcoming bugathon this weekend

If you're interested in helping out on our PR database problems, please
see my posting on freebsd-bugbusters@:

<http://docs.FreeBSD.org/cgi/mid.cgi?20080125182651.GA9914>

We're having a bugathon this weekend, with the agenda being mostly
to figure out where we are, who would like to help, and coming up
with ways that they can do so.

Followups to freebsd-bugbusters@, please.

mcl
Zum Vergrößern anklicken....
Hier noch die verlinkte Email:
Date: Fri, 25 Jan 2008 12:26:52 -0600
From: linimon@lonesome.com (Mark Linimon)
To: freebsd-bugbusters@FreeBSD.org
Cc: linimon@FreeBSD.org
Subject: agenda for this weekend's Bugathon
Message-ID: <20080125182651.GA9914@soaustin.net>

Next in thread | Raw E-Mail | Index | Archive | Help

Although I haven't spent as much time on it as I would have liked to,
there is now a preliminary attempt at this at:

http://wiki.freebsd.org/Bugathons/January2008

You'll note that the text has links to several new pages:

http://wiki.freebsd.org/BugBusting/Volunteers (signup for people
interested working on either PRs or working with users having
problems; it's a prototype)

http://wiki.freebsd.org/MarkLinimon/ActionItems (some things I've
already signed up to do, based on a lot of ideas from last week)

http://wiki.freebsd.org/KernelBugTriage (written by rwatson)

http://wiki.freebsd.org/BugBusting/Resources (factored out of
some other pages)

http://wiki.freebsd.org/Bugbusting/TipsAndTricks

I'm especially hoping that everyone interested will take a look
at these last 2 pages and become familiar with them. In particular,
I hope that people will become familiar with the email postings
as listed at the top of Resources.

I'll be around most of this weekend on #freebsd-bugbusters. Please
feel free to stop in and chat :-)

mcl
Zum Vergrößern anklicken....
 
Hallo :)

Ich hab mir vor ein paar Tagen 7 auf den Desktop gezogen.
Wenn ich jetzt "> cat /dev/zero > /tmp/muell" mache ist der rechner nicht mehr zu gebrauchen, ich bin mir jetzt nicht sicher ob dies das selbe Problem ist, da ja die Festplatte vollends ausgelastet ist (ca. 80M/s), und die CPU zeigt sich auch seehr unbeindruckt, taktet nichteinmal hoch. Bei einem "> cat /dev/zero > /dev/null" geht die CPU zwar hoch, aber alles rennt wie Tier.

Sagt was dazu, vielleicht is es ja das Problem.
 
Hey ich sagte auch, ich hätte das Problem mit dd. Daten habe ich auch gepostet. Mir gehts nicht drum zu sagen "ERSTER" aber ein "endlich jemand" liesst sich bisi gemein :D
Edit: Egal, bisl unerwachsen mein Post hier :D
 
Zuletzt bearbeitet:
Dazu muss ich sagen, dass offene Programme (die nichts mehr von der Festplatte holen) flüssig laufen. Nur wenn auch nur der kleinste Zugriff gemacht werden will dauert das 20sek.
 
Da bringste mich auf was, ich spiel mal Musikk dabei.

EDIT: Hmm, bei mir spielt die Musik recht gut weiter. Nur wenn der Buffer leer is gibts ne recht kleine Pause...

Dazu muss ich sagen, die hardware kann Einiges ab:

2048M RAM
2 x 2.8Ghz AMD Dualcore

..
 
Zuletzt bearbeitet:
Weil ich mit dem Basis-GCC42 beim Versuch, VirtualBox zu bauen, im Linken folgenden Fehler erhalte:

Code: 
kBuild: Linking VBoxSVC
/root/work/src/vbox/out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x19): In function `__static_initialization_and_destruction_0(int, int)':
/root/work/src/vbox/src/VBox/Main/linux/server.cpp:706: undefined reference to `_298'
/root/work/src/vbox/out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x38): In function `__static_initialization_and_destruction_0(int, int)':
include/VirtualBoxBase.h:944: undefined reference to `_298'
/root/work/src/vbox/out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x60): In function `__static_initialization_and_destruction_0(int, int)':
/root/work/src/vbox/src/VBox/Main/linux/server.cpp:310: undefined reference to `_298'
/root/work/src/vbox/out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/linux/server.o(.text+0x88): In function `__static_initialization_and_destruction_0(int, int)':
/usr/include/c++/4.2/bits/stl_vector.h:133: undefined reference to `_298'
kmk: *** [/root/work/src/vbox/out/freebsd.x86/release/obj/src/VBox/Main/VBoxSVC/VBoxSVC] Error 1

dieser Fehler taucht mit der alten GCC34 z.B. nicht auf. Mit GCC43 baut der gar nicht wg. mehrerer Sourcecode-Fehler.

Deshalb trau ich dem GCC42 kein bisschen über den Weg.

Und das hier:
Code: 
#ll /boot/kernel.gcc42/kernel /boot/kernel.gcc43/kernel
-r-xr-xr-x  1 root  wheel  - 9366154 30 Jan 17:53 /boot/kernel.gcc42/kernel
-r-xr-xr-x  1 root  wheel  - 8380587 31 Jan 12:09 /boot/kernel.gcc43/kernel

#du -sh /boot/kernel.gcc42 /boot/kernel.gcc43
113M    /boot/kernel.gcc42
109M    /boot/kernel.gcc43

bei identischen Kernel-Configs natürlich.

Und weil ich beim Kompilieren mit GCC43 viele, viele Warnings dieser Art erhalten habe:
Code: 
inlining failed in call to '<ALLESMÖGLICHE>': call is unlikely and code size would grow
 
Zuletzt bearbeitet:
Leute, wir verlassen hier langsam den Pfad einer sachlichen Diskussion und nähern uns gefährlich nah dem Prinzip des FUD an. Ersteinmal muss gesagt werden, dass der GCC 4.3 eine Entwicklungsversion ist. Die ganze Entwicklungslinie 4.3.0 befindet sich in aktiver Entwicklung, hat bekannte Fehler, macht Probleme und ist nicht zur produktiven Nutzung freigegeben. Was beschwerst du dich eigentlich, dass der Kernel mit dieser Version nicht bauen will, das ist völlig normal und es wird unter GNU/Linux nicht anders sein. Das einzige was du daraus ableiten könntest wäre die Notwendigkeit einige Bugreports an die GCC-Entwickler zu schreiben.

Nun, das Virtualbox unter FreeBSD nicht funktioniert, ist nun ja auch nicht neues. Es baut nicht von sich aus und selbst wenn man es schafft am Ende ein ausführbares Binärimage zu erhalten, wird dies nicht funktionieren. Dies liegt schlicht daran, dass die Entwickler sich noch nicht an FreeBSD gemacht haben, im Virtualbox-SVN befinden sich ledigliche grobe Ansätze. Das betrifft vor allem das Kernelmodul.
Das der GCC42 andere Fehler wirft als der GCC34 ist auch völlig normal. Schließlich ist der 4.2 neuer und er soll - so die offizielle Propaganda, welche ich nicht beurteilen kann - standardkonformer sein und akzeptiert viele Konstrukte die vorher völlig in Ordnung waren nicht mehr. Hier müsste man also seinen Sourcecode anpassen und nicht auf den Compiler schimpfen oder über FreeBSD.
Dem GCC42 nicht zu trauen ist übrigens auch so eine Sache, dass der GCC nun nicht unbedingt der beste Compiler da draußen ist, ist ja nun nichts neues. Aber er tut seine Arbeit recht brauchbar, funktioniert und wird jeden Tag millionenfach eingesetzt. Fast alle Linuxdistributionen arbeiten mit GCC 4 und mal ehrlich, FreeBSD hätte ihn kaum importiert, wenn er wirklich schrottig wäre. Außerdem hätte er die dann doch recht lange und aufwendige Testphase nicht überstanden.

Also, wenn ihr diese Diskussion wirklich noch fortführen möchtet, bitte zurück zum Thema.
 
Zuletzt bearbeitet:
Yamagi schrieb:
Leute, wir verlassen hier langsam den Pfad einer sachlichen Diskussion und nähern uns gefährlich nah dem Prinzip des FUD an.
Zum Vergrößern anklicken....

Was ist unsachlich daran, einen experimentellen Versuch zu starten? Wer sagt denn, dass der Code/Binaries, den/die der GCC42 produziert wirklich 100%ig ist/sind? Soll ich die Kernel-Binary irgendwo mal hochladen, dass Ihr die testen könnt, ohne die bauen zu müssen (ist ein GENERIC-Kernel mit ULE-Scheduler)?

Ersteinmal muss gesagt werden, dass der GCC 4.3 eine Entwicklungsversion ist. Die ganze Entwicklungslinie 4.3.0 befindet sich in aktiver Entwicklung, hat bekannte Fehler, macht Probleme und ist nicht zur produktiven Nutzung freigegeben.
Zum Vergrößern anklicken....

Und? Habe ich gesagt, dass die Leute dies auf Ihren Primär-Servern tun sollen? Es ist ein Experiment.

Was beschwerst du dich eigentlich, dass der Kernel mit dieser Version nicht bauen will,(...)
Zum Vergrößern anklicken....

Wo liest Du, dass ich mich beschwere, dass der Kernel nicht unter GCC43 baut? Hoffe doch mal, dass es aus meinem Posting ersichtlich wurde, dass der Kernel sehr wohl unter GCC43 baut, und momentan aktiv hier läuft. Werden halt nur viele Warnings produziert.

Nun, das Virtualbox unter FreeBSD nicht funktioniert, ist nun ja auch nicht neues.
Zum Vergrößern anklicken....

Korrekt, es funktioniert noch nicht. Es geht auch mehr darum, ob man es überhaupt bauen kann. Mit dem GCC34 ging dies, aber mit dem GCC42 im Base-System nicht mehr, der halt die ganzen "Unresolved ..."-Fehlermeldungen produziert, welche ich für einen üblen Bug im GCC42 halte.

Vielleicht haut der GCC42 einen Bug rein, der genau diese Perfomance-Probleme verursacht?
 
Vielleicht haut der GCC42 einen Bug rein, der genau diese Perfomance-Probleme verursacht?
Zum Vergrößern anklicken....
Das halte ich für extrem unwahrscheinlich, weil Die Probleme dann in RELENG_6 nicht auftreten würden. Außerdem zeigt ein Lockprofiling, dass es andere, deutlich wahrscheinlichere Theorien gibt.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben