FreeBSD 6.2/AMD64: Leistungseinbruch

E

Eisenfaust

Well-Known Member
Hallo.
Vielleicht kann mir einer der Experten weiterhelfen.

ich arbeite mit zwei verschienden Hardwareplattformen mit FreeBSD 6.2-PRE in der jeweils aktuellsten Version und mit nahezu identischer Konfiguration, soweit das möglich ist. Meine Labormaschine ist eine i386-Maschine, die andere eine amd64-Maschine.

i386: P4 Prescott, 3.0 GHz, 1MB 2nd Level Cache, HT (eingeschaltet), 2GB DDR400 RAM, Mainboard ASUS P4P800. 2x ATA100 Platten, WD, a 130 GB, am selben Controller, kein RAID 0. SMP-Kernel.

amd64: Athlon64 3500+ (Winchester), 2,2 GHz, 512KB Level 2 Cache, 2GB DDR400-ECC RAM, Mainboard ASUS A8N32-SLI, 2x Hitachi T7K250 SATA II a 250 GB, RAID 0 am nForce4 Controller. UP Kernel.

Die AMD64 Maschine läuft als __reine__ 64Bit Maschine, keine 32Bit Kompatibilität.

Beide Rechner sind derzeit mit FreeBSD 6.2-PRE konfiguriert, cvsupdate heute, make buildworl auch heute. Der i386 Rechner hat einen SMP Kernel, um HT nutzen zu können, die amd64 Box einen UP Kern.
Wenn ich auf beiden Maschinen ein make -j2 buildworld installworld starte, benötigt die i386 Maschine ca. 60 Minuten, die amd64 Kiste über 90 Minuten. Das Bild ändert sich nicht signifikant mit make ohne -j-Option und i386 mit UP Kernel ohne HT.
Generell stelle ich seit ca. 2 Monaten fest, daß der amd64 Port auf meinem Rechner zunehmend 'langsamer' wird.
Das Problem läßt sich auch nicht durch Wechsel des Schedulers beheben. Lobte man zur zeit von FreeBSD 6.0 noch SCHED_ULE, wird ab version 6.2 wieder SCHED_4BSD favorisiert, weil SCHED_ULE ganz offenbar mit SMP Systemen Probleme bereitet. In meinem Falle, unter amd64, ist es aber umgekehrt, SCHED_4BSD läßt die Maschine ruckeliger erscheinen als mit SCHED_4BSD.

Obwohl mein Laborrechner die deutlich ältere und leistungsschwächere Hardware hat, ist diese Maschine __deutlich__ schneller! Während auf der i386 Platform noch MySQL, cups laufen, ist der amd64 Kasten von solchen Diensten 'befreit' - und dennoch wesentlich langsamer! Auch eine Neuübersetzung aller Ports hat nichts an diesem verzerrten Bild geändert!

Da ich nicht ganz neu mit FreeBSD bin und gewissermaßen beobachten konnte, wie sich von cvsupdate zu cvsupdate die Leistung der 64Bit Version 'verschlechterte', will ich hier fragen, wer ebenfalls solche Beobachtungen gemacht hat. In den offiziellen Mailinglisten kriegt man hierzu oft nur lapidare Bemerkungen zurück, man habe etwas falsch gemacht. Wenn ich beschreiben würde, was ich alles schon zur Optimierung ausprobiert habe, würde keiner die lange eMail lesen.

Mich enttäuscht im Moment sehr, daß der vielgelobte SCHED-ULE nun auch schon zum Problemfall geworden ist und man wieder auf den betagten und inadäquaten SCHED_4BSD zurückfällt. Wie jüngst zu lesen war ist scheinbar auch die Netzwerkleistung unter FBSD 6.X UP/SMP weit abgeschlagen hinter FreeBSD 4.11 und Linux Kernel 2.6.15.

Grüße ...
 
Vielleicht hat dein Laborrechner eine schnellere Festplatte. Wenn es dir auf Performance ankommt, solltest du auch prüfen ob die AMD64 Box ohne ECC schneller läuft (sollte der Fall sein).
 
Seit wann ist eine betagte WD ATA100 PATA Platte (3 Jahre minimum alt) schneller als eine Hitachi T7K250 SATA II, 1/2 Jahr alt?

Ich werde ECC einmal abstellen, Danke für den Tipp. Technisch gesehen dürfte das allerdings keinen Einfluß nehmen, der im Bereich des 'Fühlbaren' liegt - es sei denn, Hardware und FreeBSD haben ein problem, dann impliziert dies, daß sämtliche Opteron Profihardware mit noch langsameren reg ECC Speicherbänken unter dieser Problematik zu leiden hat.

Die Leistungseinbußen sind dramatisch, fühlbar. Ob mit oder ohne ECC nun 10% Leistung flöten gehen, ist irrelevant für mich, dafür wähne ich mich auf der sicheren Seiten, wenn numerische Berechnungen gemacht werden. Unter FreeBSD 6.0 hat die selbe Hardware einen ähnlichen Rechner von DELL mit 1GB DDR2-667 'ausgestochen'. Auf der DELL Maschine konnte ich PathScale und Intel V8 Compiler verwenden, auf dem AMD64 Kasten war nur der gcc 3.4 zur Verfügung mit seinem langsamen f77.

Jetzt ist es genau anders herum.

Witzig: während ich vor 3 Monaten noch mit xine ein AVI ansehen konnte, ohne daß die Maschine ruckelte, ist das heute auf der AMD64 Kiste nicht mehr möglich.

Auf beiden Architekturen ist beobachtbar, daß bei kleiner Last ab und an Sound, Graphik und sogar die Tastatureingabe unterbrochen wird.
Auf der gleichen Hardware ist dies mit einem FreeBSD 6.1 NICHT der Fall.
 
Eisenfaust schrieb:
Witzig: während ich vor 3 Monaten noch mit xine ein AVI ansehen konnte, ohne daß die Maschine ruckelte, ist das heute auf der AMD64 Kiste nicht mehr möglich.

Auf beiden Architekturen ist beobachtbar, daß bei kleiner Last ab und an Sound, Graphik und sogar die Tastatureingabe unterbrochen wird.
Auf der gleichen Hardware ist dies mit einem FreeBSD 6.1 NICHT der Fall.
Zum Vergrößern anklicken....

Ach, das ist nicht normal? :p

Code: 
FreeBSD 6.1-SECURITY #0: Mon Aug 28 05:36:36 UTC 2006
    root@builder.daemonology.net:/usr/obj/usr/src/sys/SMP
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Sempron(tm) Processor 3000+ (1808.81-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x20fc0  Stepping = 0
  Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  Features2=0x1<SSE3>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow>
  AMD Features2=0x1<LAHF>
real memory  = 1073414144 (1023 MB)
avail memory = 1041289216 (993 MB)

Bei der Kiste sollte man meinen, daß sie schnell genug ist, aber diese Probleme des kurzen Anhaltens und Ruckelns kommen mir doch sehr bekannt vor.

Helfen kann ich Dir mangels Kenntnisse nicht aktiv, aber falls Du irgendwelche Fragen zum System hast - lass hören. Vielleicht hilft es Dir ja.
 
Diese Aussetzer sind nicht normal. FreeBSD hat im Moment massive Probleme mit dem Interrupt Handling, wie mir scheint. Wenn unter Null Last bei einem simplen Platten-Sync Sound, Graphik und auch die Tastatureingabe stockt, ist das verdächtig - zumal der Tastaturtreiber GIANT LOCKED ist.

Bei mir passiert es häufig, daß, wenn ich in vi (in einem xterm) oder in Thunderbird einen Text eingebe und länger auf einer Taste zwecks Wiederholung bleibe, die Eingabe stockt. Das ist dann so, als hätte man die Taste losgelassen. Es ist nie der gleiche Zeitraum, in dem das passiert, also ist es nicht systematisch, so als wenn alle 10 Zeichen gestoppt werden würde. Unter FreeBSD 4.11 ist unter gleicher Hardware dieses Problem nicht, auch eine Ubuntu Live CD macht bei mir auf der gleichen hardware keine Probleme. Mein i386-Rechner hat zwar auch diese Probleme, aber weitaus weniger als auf meiner amd64 Maschine.

FreeBSD 5.3 hatte auf einem 1GHz PIII diese Phänomene auch nicht!

Denkbar ist, daß dies mit dem neuen Interrupt Handling in FreeBSD zu tun hat.

Im Moment ist allerdings meine AMD64 Kiste nahezu unbrauchbar - und die Hardware ist beileibe schneller als ein PIII, auf dem mit FreeBSD 5.X solche Probleme nicht auftraten.
 
Hallo Eisenfaust,

Du scheinst 10x mehr Ahnung davon zu haben als ich, daher ist mein Hinweis vielleicht ziemlich dumm: Kann es sein, dass in dem PRE-Kernel noch viel debugging eingeschaltet ist? Ich meine mich zu erinnern, dass erst mit RELEASE das debugging überall abgeschaltet ist... Falls das der Fall wäre, würde das zumindest einen gewissen Performance-Verlust erklären. Müsste sich allerdings mit den richtigen Parametern beim Kompilieren beheben lassen...

Viel Erfolg jedenfalls - und gib bitte bekannt, falls Du Neues herausfindest...

Gruß
SolarCatcher
 
Nein, wenn Du den Kernel bootest, erscheint diese Meldung an allen Treibern, die nicht SMP/Threading-fähig sind - zumindest im Kernel.
 
SolarCatcher schrieb:
Hallo Eisenfaust,

Du scheinst 10x mehr Ahnung davon zu haben als ich, daher ist mein Hinweis vielleicht ziemlich dumm: Kann es sein, dass in dem PRE-Kernel noch viel debugging eingeschaltet ist? Ich meine mich zu erinnern, dass erst mit RELEASE das debugging überall abgeschaltet ist... Falls das der Fall wäre, würde das zumindest einen gewissen Performance-Verlust erklären. Müsste sich allerdings mit den richtigen Parametern beim Kompilieren beheben lassen...

Viel Erfolg jedenfalls - und gib bitte bekannt, falls Du Neues herausfindest...

Gruß
SolarCatcher
Zum Vergrößern anklicken....

Hallo.
Ich erinnere mich daran, daß ich vor Jahren einmal diesbezüglich in den englischen Mailinglisten angefragt hatte und man sagte/schrieb mir, daß es nicht der Fall sei, daß Debugging eingeschaltet wäre. Vielmehr sei dies ausschließlich auf die Kernel-Konfigurationsdatei GENERIC bezogen. Da ich prinzipiell meine Kernel an die hardware angepaßt bauen, fällt das flach (Schlagworte: WHITNESS, INVARIANTS, DDB).

Ich kann nicht ausschließen, daß einige in STABLE verwendete Treiber eben doch Debug-Schalter im Quelltext eingeschaltet haben. Wäre dem so, dürften die FBSD Entwickler aber nicht auf STABLE verweisen, wenn jemand, wie ich seinerzeit mit meinem A8N32-SLI Board, zu neue Hardware verwendet, um mit einer RELEASE betrieben zu werden.

Allerdings lege ich hierfür nicht mehr meine Hand ins Feuer, ich habe in den 10 Jahren mit FreeBSD einen gewissen Qualitätsrückgang erleben dürfen, was die Informationspolitik betrifft. Hieß es vor einem Jahr noch, daß SCHED_ULE der neue, ultimative, beste Scheduler für SMP und auch UP Systeme sei, gibt es neuerdings massive Schwierigkeiten mit einiger Hardware unter SMP, die vor allem mit AMD64 nicht in den Griff zu kriegen sind. Kommentar der FBSD Gilde: ab 6.2 wird der SCHED_4BSD wieder zum Standard erklärt. Jeder Bugreport wird dahingehend überprüft, ob auch wirklich SCHED_4BSD verwendet wird!
Diese Information ist nur dann zu finden, wenn man gezielt in den englischen Foren danach sucht oder die Mailingliste der Entwickler fleißig mitverfolgt. Auf der Website ist dazu nichts zu lesen!
Verzeih, wenn ich meinem Unmut hier etwas Luft verschaffe. Wenn man als 'Power-to-Serve' UNIX firmiert und Anwender auf eine STABLE Version bezüglich eines mangelnden Treibers in RELEASE verweist, darf man eine bessere Informationspolitik erwarten. Insbesondere dann, wenn viele Anwender eine STABLE Version auch im produktiven Einsatz fahren und, wie jetzt, in der endgültigen RELEASE essentielle Änderung in der Kernel-Konfig (SCHEDULER) durchgeführt werden. Soetwas gehört publiziert, und zwar dort, wo sich jeder Administrator schnell informieren kann - und nicht erst durch Studium der neuen GENERIC Dateien bzw. der RELEASE Info.
Irgendwie drängt sich mir der Verdacht auf, daß Mathew Dillon doch recht behalten könnte, als er bezüglich seines Wegganges konzeptionelle Probleme bei FBSD ausmachte.
Im Moment überlege ich ernsthaft, meine 10jährige Partnerschaft mit FreeBSD zu kündigen um eventuell mal einen Blick auf NetBSD zu werfen. Dort haben mir die Leistungswerte nicht geschmeckt. Da ich im naturwissenschaftlichen Bereich arbeite und Lin(S)ux hier dominiert (Compiler, mitlerweile wesentlich bessere Skalierung mit SMP, besser als jedes BSD!, verbesserter TCP/IP Stack, der den von FreeBSD >4.11 sowohl unter UP als auch SMP schlägt), erwäge ich auch diesen Schritt.
Ach ... soviel Potential sinnlos vergeudet ....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben