Re: geom_*, atacontrol oder Hardware?

--On Freitag, 19. November 2004 22:54 Uhr +0100 Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> On Fri, Nov 19, 2004 at 09:33:36PM +0100, Andreas Braukmann wrote:
>> --On Freitag, 19. November 2004 18:44 Uhr +0100 Oliver Fromme [...] wrote:
>>
>> > Ich würde mal schätzen, auf einer 4-CPU-Maschine hängt
>> > Solaris in der Performance jedes BSD ab.
>>
>> Das duerfte dann immer noch sehr stark vom Applikations-
>> mix abhaengen.
>
> Ja - gerade das PostgreSQL Beispiel wird auf der gleichen 4 CPU
> Maschine mit FreeBSD oder NetBSD deutlich besser abschneiden.

Der - so Bruce Momijan im Rahmen eines "PostgreSQL Internals"-
Workshops - groesste Vorteil von FreeBSD als PostgreSQL-Platt-
form seidas gute Zusammenpassen mit den Eigenschaften des UFS
bzw. UFS2 Dateisystems (unter explizitem Einbezug der Softup-
dates).

Das "alte" Solaris-UFS sei schneckenlahm und es fehlt die
Softupdate-Garantie fuer den Crashfall.
Das versammelte Buendel an "journaling" Dateisystemen schleppe
zuviel overhead mit sich.

Bei Linux stellt es sich so dar, das praktisch nur EXT3 (im
Softupdate-aehnlichem Modues) sinnvoll verwendbar sei; evtl.
noch XFS. (Ich persoenlich hatte leider schon zwei Mal das
Problem, dass PostgreSQL-Datenbanken auf XFS direkt nach
dem Import eines Dumps inkonsistent / kaputt waren.)
EXT3 hat das grosse Problem, dass die Performance unter multi-
user-Last (gleichzeitiges Beschreiben verschiedener Dateien)
extrem in der Performance einbricht.

>> > Solaris, sondern eher an PostgreSQL, das einfach nicht
>> > in der Lage ist, SMP-Systeme vernünftig auszunutzen.
>>
>> Warum? Weil es forkt statt zu threaden?
>
> Weil dessen Art die Kommunikation zwischen den Prozessen abzuwicklen
> auf Solaris nicht sonderlich gut skaliert, während die pthread
> Implementierung von Solaris sehr gut optimiert ist.

Achso. (Ich hab seit Ewigkeiten kein Solaris mehr unter
den Fingern gehabt.)

> Auf FreeBSD skaliert PostgreSQL mit der Anzahl der CPUs deutlich
> besser, dafür hingegen derzeit MySQL nicht.

Stimmt.

>> > (Nichts gegen PostgreSQL -- ich ziehe es jederzeit mysql
>> > vor.)
>
> Bei mir ist es genau umgekehrt - aus einer Vielzahl von Gründen.
> Aber unter anderen auch gerade weil es auf FreeBSD sehr gut mit
> und ohne SMP skaliert, was bei MySQL momentan absolut nicht der
> Fall ist.

Ich befuerchte, hier hast Du Oliver missverstanden. Er
zieht "es" (also PostgreSQL) vor. Du auch, oder? Ich
auch (wenn auch hauptsaechlich aus "Feature"-Gruenden).

>> Wir denken ueber FreeBSD/amd64 (wegen *sehr*viel* RAM)
>> nach. Das bedeutet zwangsweise RELENG_5 als Basis; und
>> bei dem bin ich mit der I/O-Performance (kann es sein,
>> dass geom eine maechtige Bremse ist?) auch noch nicht
>> so recht warm geworden werden.
>
> Das Problem mit FreeBSD-5 und I/O ist der GIANT Lock, der immer
> noch in einigen Bereichen stark zum tragen kommt.

Hmmm. Zu ca. 5.1 Zeiten (jedenfalls vor dem "mandantory
geom"-Einschnitt; hatte ich auf meinem 5.x Datenbank-
Testserver eine nie gekannte I/O-Performance im Falle
von vielen parallelen I/O-Requests. Jedenfalls dann,
wenn ein MPSAFE-Treiber (in meinem Falle aac(4)) die
Platten bediente. Der Einfluss von "GIANT" sollte sich
seit dieser Zeit doch eigentlich verringert haben.

> Selbst wenn du ein IO System GIANT clean hast kann ein IRQ sharing
> mit einem GIANT behafteten immer noch die Performance in den Keller
> ziehen.

Das war und ist gluecklicherweise nicht der Fall.

> Du solltest einfach noch mal mit 5.3 überprüfen ob deine Problem-
> stellen noch auftreten - gerade die großen I/O Systeme sind in
> letzter Zeit stark weiterentwickelt worden.

Das werde und muss ich tun. Ein Port von RELENG_4 auf
amd64 steht wohl kaum in Aussicht ;-) (Neee, die Drachen-
fliege ist zwar eine interessante Studie, aber derzeit
wohl eher keiner Server-Betriebssystem.)

-Andreas

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 20 Nov 2004 - 00:04:04 CET