Re: geom_*, atacontrol oder Hardware?

On Fri, Nov 19, 2004 at 09:33:36PM +0100, Andreas Braukmann wrote:
> Moin,
>
>
> --On Freitag, 19. November 2004 18:44 Uhr +0100 Oliver Fromme
> <olli(at)lurza.secnetix.de> wrote:
>
> > > > Ich haette z.B. unheimlich gern mal eine 2 oder 4 CPU SPARC-Maschine
> > > > mit viel (min. 4 GB) einem Buendel moderner Platten, um zu schauen, ob
> > > > das nicht eine geeignete Plattform waere, um i386-basierte Post-
> > > > greSQL-Server abzuloesen.
> > > > Und nein: Solaris ist dafuer (wenn man Bruce Momijan und Kollegen
> > > > glauben schenken darf; wovon ich zunaechst einmal ausgehen) keine gute
> > > > Wahl.
> > >
> > > Warum nicht? Solaris ist nicht unbedingt Weltspitze in Performance, das
> > > ist wahr, was ich schaetze, ist die Stabilitaet.
> >
> >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.

> > Daß es in dem
> >oben geschilderten Fall suboptimal ist, liegt nicht an
> >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.
Auf FreeBSD skaliert PostgreSQL mit der Anzahl der CPUs deutlich
besser, dafür hingegen derzeit MySQL nicht.

> Meine Erwaehnung von 2 oder 4 CPUs ruehrt allerdings auch
> eher aus "meinem" (bzw. des Kunden) Query-/Applikations-
> mix (das skaliert mit zunehmender Anzahl der CPUs fuer
> die cpu-lastigen Teile der DB-Bearbeitung sehr gut).
>
> Das Problem der derzeitigen PostgreSQL-Kisten dort liegt
> deutlich sichtbar im I/O-Subsystem. (Vormals Linux 2.4.x;
> derzeit Linux 2.6.8.) Ein FreeBSD 4.x ist auf gleicher
> Hardware gut 30% fixer; 40 bis 45 MByte/s Bandbreite
> zwischen Datenbank und Platte statt 30 bis 34 MByte/s.)
>
>
> >(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.

> 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.
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.
Die Sache wird aber von Version zu Version immer besser.
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.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message