FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
meeb schrieb:
Habe hier einen Pentium M 1.6 Ghz und 512mb RAM. System ist ein FreeBSD 7.0-CURRENT. Das Ganze läuft meist in einem Ion mit ein paar KDE-Apps und insgesamt sehr performant. Sobald ich allerdings irgendetwas kompiliere brauche ich im Grunde nicht mehr versuchen mit dem System noch etwas anderes zu machen..
Zum Vergrößern anklicken....
JUHU! Endlich mal jemand, der meine Beobachtungen bestätigen kann.
 
Bei mir (FreeBSD 6.2; P4, 2.4GHz, 1 GB Ram, Matrox 6E040L0, noch ATA) ergeben sich folgende Werte:

Code: 
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
          100 48789 50.0 39858 13.7 42301 15.9 107446 93.3 620828 93.6 41498.9 92.6

Deine Platte ist leicht langsamer, benötigt aber weniger CPU-Leistung. Dein Sequential Input Block ist sehr hoch im Vergleich zu den übrigen Werten.

Die ubench Resultat liegen wohl im Rahmen des üblichen, vielleicht leicht darunter. Vermute mal das -Current da noch eine Rolle spielt.

Ingesamt also nichts Bedenkliches.

In deiner dmesg taucht öfters ITHREAD auf. Ist dies -Current bedingt?

mousaka
 
Zuletzt bearbeitet:
Man sollte wohl herausfinden ob das Problem durch die CPU Last oder durch die HD Last verursacht wird.

Der Befehl

# dd bs=1m < /dev/random > /dev/null

ist ganz gut um die cpu zu beschäftigen. Analog kann man die Festplatte gut mit mit

# dd bs=1m < /dev/zero > tmpfile

auslasten.
 
Ich bin kein Freund von dd und habe auch keine Ahnung davon. In meiner Ideenlosigkeit habe ich vorhin

# dd if=/dev/randon of=/tmp/testfile.dat

benutzt, um ein wenig Plattenlast zu erzeugen. Ist der Befehl in der Form ungeeignet?
 
Damit erzeugst du viel Last auf CPU und auf HD Seite. Es geht ja darum herauszufinden ob es an der CPU Last oder an der HD Last liegt, also solltest du in den Tests nur eins belasten.
 
Kamikaze schrieb:
# dd bs=1m < /dev/random > /dev/null
Zum Vergrößern anklicken....
Bleibt alles bestens, das System reagiert weiterhin fröhlich vor sich hin, ich kann Fenster wechseln, Menüs aufrufen, Eingaben machen.

Kamikaze schrieb:
# dd bs=1m < /dev/zero > tmpfile
Zum Vergrößern anklicken....
Da geht gar nichts mehr. Im ersten Versuch konnte ich noch die Tabs der Konsole (KDE-Konsole) durchschalten und Fenster wechseln, nach einem zweiten Versuch fror die Oberfläche völlig ein. -> CTRL-ALT-Backspace. Nach einem erneuten Start von Xorg und dem o.g. dd-Befehl wieder kein Start weiterer Anwendungen, auch das KDE-Menü kommt auf Mausklick nicht.

Werkeln tut FreeBSD hier auf ad12s2, einem im IDE-Mode laufendes SATA-Device.
 
Noch eine Besonderheit. Starte ich KDE und fange an zu kompilieren, bleibt das System relativ flüssig. Starte ich dann mein TV-Programm (mplayer oder xawtv), fängt es an zu ruckeln wie sonstwas. Beende ich die TV-Anwendung wieder, bleibt das System inperformant.
 
Also anscheinend gibt es irgendeinen Flaschenhals im Treiber für den ATA Controller, der dir massivern Ärger bedeutet. Warum das Problem nach dem Boardwechsel nicht verschwunden ist , ist mir schleirhaft, es sei denn es sind mehrere Chipsätze betroffen. Vielleicht hast du auch ein kaputtes IDE Kabel und der BUS wird mit Fehlern zugemüllt, die dein System überfordern. Hast du das Kabel schon mal getauscht?

Der SMART Status der Festplatte enthält vielleicht auch Hinweise.
 
# dd bs=1m < /dev/random > /dev/null

lässt das System hier unbeeindruckt weiterarbeiten.

# dd bs=1m < /dev/zero > tmpfile

einige Anwendungen sind hier ebenfalls unbeeindruckt, andere wie z.b. Kate und der Konqueror (insbesondere mit geöffneten Tabs) kacken optisch komplett ab, werden sozusagen unsichtbar (leeres Fenster mit grauen Schlieren wo mal die Menüleisten waren). Mausbewegungen und Wechsel der Arbeitsfläche oder im Ion der aktiven Frames sind unauffällig.
 
Da meeb von ähnlichen Problemen berichtet, schließe ich einen Defekt des Kabel mal aus. Wäre aber auch schon merkwürdig, wenn das IDE-Kabel sowohl im alten, als auch im neuen Rechner defekt wäre. Ich fürchte fast, bei mir kommt eine Mehrzahl von Problemen zusammen.

Erstmal die ATA-Schwäche und das dann noch in Verbindung mit meiner TV-Karte, die auch irgendwelche nachteiligen Auswirkungen auf das System hat. Das TV-Bild läßt sich übrigens schon durch ein wenig Browserbenutzung (z.B. im Konqueror) ins Stocken bringen. Da ist im Prinzip doch so gut wie keine I/O-Last auf dem Platten vorhanden.

Das Fazit wird daher wohl auch bei 7.0 das gleiche bleiben ... taugt auf meiner Maschine für meine Zwecke leider nicht.
 
Hallo Steve`

schau doch mal als root-User nach, was von mplayer oder xawtv nach dem Beenden sich noch im Speicher tummelt. Schau auch mal mit top nach, ob da irgendeiner der beiden extrem Last erzeugt.
Ich tippe hier auf den Grafiktreiber.

Grüße

Juedan
 
Hi Jürgen,
von beiden Programmen bleibt (sichtbar) nichts im Speicher übrig (ich kenne aber nur top und ps, um das zu überwachsen). Last wird zumindestens beim Abspielen mit mplayer erzeugt, diese liegt so zwischen 35% und 50%. Unter Linux liegt die Last von TvTime zwischen 17% und 30%.

Grafiktreiber ist 'ne Idee, aber momentan mit 'nv' geht es nicht und auch früher mit 'nvidia' ging es nicht. NVidia will momentan auf 7.0-CURRENT nicht.
 
Falls es dir ein Trost ist: ich habe ganz ähnliche Probleme mit 6.2-STABLE. Kaum macht das System mal ein wenig mehr im Hintergrund war es das mit der Performanz. Dann ruckelt sogar der Sound vom OGG-Player. Unter Linux keinerlei solche Probleme. Eine TV-Karte habe ich nicht, die Kabel wurden auch schon gewechselt. Insgesamt läuft die Maschine (Athlon XP 2200+, 1 GB RAM, GF 4TI etc.) unter FreeBSD im Vergleich zu Linux unbefriedigend. Mir ist das genauso unerklärlich wie dir. :)
 
mucknert schrieb:
Falls es dir ein Trost ist: ich habe ganz ähnliche Probleme mit 6.2-STABLE. Kaum macht das System mal ein wenig mehr im Hintergrund war es das mit der Performanz.
Zum Vergrößern anklicken....
Ja, danke, das ist mir ein Trost. Denn es belegt, dass es kein persönliches Pech ist, dass ich derart heftige Performanceeinbrüche unter FreeBSD habe.

Da die Probleme hier auch unter twm auftreten, lasse ich für mich folgendes Fazit zu:
Das Performanceproblem ist grundlegender Natur und tritt zumindestens in bestimmten Hardwarekonstellationen auf. Da sich hier mehrere zu Wort gemeldet haben, scheint es darüber hinaus keine Seltenheit zu sein. Da das Problem seit Jahren besteht, sind die FreeBSD-User entweder toleranter, was sowas angeht, oder der Fehler ist dem Team nicht bekannt, bzw. kann so schlecht dargestellt werden, dass er nicht gefunden wird. Ich hatte vor einiger Zeit schonmal die Fehlerdatenbank durchsucht, aber nichts gefunden. Vielleicht hat jemand anders nochmal Lust, da zu gucken? Vielleicht haben andere bessere Suchbegriffe.

Ansonsten: Ob es sinnvoll wäre, hier nochmal einen PR zu verfassen? Wie können wir das Problem möglichst genau beschreiben und detaillierte Informationen beibringen? Und gibt es hier definitiv jemandem, bei dem das Problem nicht auftritt?
 
Ich selbst habe diese Probleme nicht, mit dem aktuellen -CURRENT habe ich sogar das erste mal seit Jahren wieder das Gefühl, dass FreeBSD ein sehr schnelles Betriebssystem ist. Allerdings kann ich nicht verleugnen, dass FreeBSD nach wie vor (eigentlich schon seit seinen Anfängen) große Probleme mit seinem VFS hat. Seit dem SMPng Projekt zu 5.0 sind sie merklich schlimmer geworden und auch das überholte ATA-Subsystem mit 6.0 hat seinen negativen Beitrag geleistet. Aktuell sieht es so aus, dass ich auf einer Platte an Controller A den Sourcetree lösche und während dessen auf ein ls -lha in einem Verzeichnis mit 10 Dateien auf Platte B an Controller B gerne mal 20 bis 30 Sekunden warten darf. Mit ein bischen Geschick kann man durch Plattenbelastung das System an den Rand des Zusammenbruchs bringen.... Ich weiß leider nicht in wie weit die Pläne noch aktuell sind, nur es gab auf -CURRENT im Rahmen der ZFS-Portierung Anregungen und Diskussionen, wie man das VFS zu 8.0 hin überarbeiten könnte.

Auch wenn ich deine proleme allenfalls im Rahmen des VFS nachvollziehen kann, würde ich dir zu einen PR raten und das Problem vielleicht auf noch einmal -CURRENT anzusprechen. Schaden kann es schließlich nicht und vielleicht bewirkt es was.
 
Da ich momentan aufgrund der o.g. Probleme nicht dauerhaft mit FreeBSD arbeite und auch nicht gewährleisten kann, dass ich immer ein FreeBSD im Zugriff habe, möchte ich selbst auf diesen PR verzichten. Im Fall der Fälle ist nämlich nicht gewährleistet, dass ich genauere Informationen liefern kann; solche PRs schmoren aufgrund der möglicherweise weitreichenden Änderungen und der ungenauen Fehlereingrenzung und -beschreibung vermutlich ganz gerne mal über Monate/Jahre.

Ich fände es daher hilfreich, wenn jemand den PR einreicht, der trotz des o.g. Verhaltens dauerhaft FreeBSD einsetzt und dieser ggf. auf die übrigen User verweisen könnte.
 
FreeBSD 6.2: 3 GHz HT P4, 1 GB Dual Channel RAM, 120 GB SATA HDD

# dd bs=1m < /dev/random > /dev/null
lässt das System hier unbeeindruckt weiterarbeiten.

# dd bs=1m < /dev/zero > tmpfile
einige Anwendungen sind hier ebenfalls unbeeindruckt, andere wie z.b. Konqueror (insbesondere mit geöffneten Tabs) kacken optisch komplett ab, werden sozusagen unsichtbar oder lassen sich gar nicht mehr erst starten.

Von diesem Test abgesehen hab ich NULL Probleme. (Ich persönlich glaube dass der 2. Test die Festplatte SO auslastet das einfach nichts anderes mehr geht und das Verhalten FAST normal ist. HDDs haben keine Scheduler :))

Aber ansonsten: Musik hören, dabei brennen, portupgrade -pa und dutzende geöffnete Fenster lassen mich völlig unberschwert weiterarbeiten.
 
"FAST normal" für FreeBSD. Unter Linux kann ich dieses Verhalten überhaupt nicht bestätigen. Von daher scheint es sich meines Erachtens hier schon um ein Verhalten zu handeln, das es zu korrigieren gilt. Mit Musik, k3b, etc. habe ich auch keine Probleme. Speziell, wenn meine TV-Karte mit mplayer zum Einsatz kommt (braucht für sich schon 30-40% CPU-Last), dann zieht es auch den Mauszeiger in Mitleidenschaft. Ohne TV-Karte gehts noch einigermaßen, das wäre ok für mich.

Auf die TV-Karte möchte ich allerdings nicht verzichten; die Frage ist, ob es ggf. ein Modell gibt, das nicht so leistungsfordernd ist?!
 
Moin Steve`,

bei mir hab ich 6.2-Stable laufen (PIV HT 3,4GHz, 2GB RAM, Geforce 6600, 2x SATA Platten im RAID1 am Intel onboard Controller). Ich hab bei mir auch das Gefühl, dass plattenintensive Geschichten das System enorm ausbremsen (stärker als unter Windows oder Linux) und hab mittlerweile den Treiber für den SATA-Controller im Verdacht. Auf meinem Notebook (PIII 933MHz mit ner ollen 10GB ATA-Platte) erziele ich mit iozone teilweise bessere Werte, besonders bei random seeks (ebenfalls 6.2-STABLE). Dafür würde auch sprechen, dass ein ähnliches Verhalten mit Windows Vista auftritt, nicht aber mit Win XP oder Linux.

Allerdings schließe ich aus Deinen Äußerungen, dass die Platte bei Dir schon mal getauscht wurde. Der Controller auch? Ansonsten ist mir nur aufgefallen, dass sowohl der Scheduler von Free- als auch von OpenBSD offenbar Probleme mit Prozessen hat, die I/O-Wait verursachen. Das bügelt der Linux-Kernel z. B. wesentlich besser weg, ohne dass es zu Deadlocks kommt (natürlich nur bis zu einem gewissen Maß, aber das System bleibt benutzbar).
 
@ Ogion
Die Platte wurde bei mir im aktuellen System noch nicht getauscht, aber ich hatte schon Performanceprobleme auf einem komplett anderen System (damals noch ohne SATA). Da sich das ganze aber schon über knapp 3 Jahre hinzieht, fällt es im Nachhinein natürlich schwierig, genaue Zeiten zu bestimmen. Vielleicht war damals zu 5.2-STABLE auch noch der Scheduler schuld, während sich die Ursache jetzt mehr in Richtung (S)ATA-Treiber verschoben hat?! Ich weiß es nicht .... aber momentan ist es jedenfalls ganz schön heftig.
 
Da du wissen wolltest bei wem das Problem nicht vorhanden ist:

Ich baue grad die Welt und stecke zusätzlich mein Homeverzeichnis in einen Tarbollen. Amarok und vlc laufen auch und ich merke überhaupt nichts. Ok, also es knackt nichts, es ruckelt nur wenn ich ganz schnell ein Fenster durch die Gegend schiebe.
World of Warcraft würde ich jetzt allerdings trotzdem nicht gleichzeitig spielen :D
Hier ein Screenshot und die dmesg.
Code: 
FreeBSD knirsch.sandbox.net 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed Sep 19 16:15:03 CEST 2007     root@knirsch.sandbox.net:/usr/obj/usr/src/sys/KNIRSCH  i386

amd64 4000+
2gb ram
3x hdd (2 an promise sata karte)
gf 6800 ultra
ne extra soundkarte

Soll ich sonst noch irgendwas angeben?
 

Anhänge

  • screenshot.png
    screenshot.png
    315,3 KB · Aufrufe: 572
  • dmesg.txt
    6,6 KB · Aufrufe: 439
Ok, mir fallen zwei Sachen auf:

a) Du hast einen NVidia-Chipsatz (nForce), ich einen VIA. Haben die anderen Betroffenen auch VIA-Chipsätze? Ich habe noch viel gegoogled und einen recht alten Beitrag (aus Zeiten von 5.x) gefunden, in dem sich auch viele über die miese Performance bei VIA-Chipsätzen beklagt haben.

b) Du hast 2gb RAM, ich habe 1gb. Ich hatte auf einer virtuellen Linuxmaschine auch kürzlich das Problem, dass der Prozessor I/O-waits nicht abarbeiten konnte; eine Erhöhung des Hauptspeichers brachte dann Abhilfe, weil das System nicht mehr ins Swap auslagern mußte
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben