Re: Shells, Linux, GNU

Moin,

On Thu, Apr 03, 2003 at 11:52:16AM +1000, Peter Ross wrote:
> On Wed, 2 Apr 2003, Andreas Braukmann wrote:
>
> > > FreeBSD (-stable) kennt nur Userland-Threads. Das
> > > führt dann etwa dazu, daß man eine hochbelastete mysql-In-
> > > stanz unter FreeBSD nicht sinnvoll auf einer Mehrprozessor-
> > > maschine betreiben kann. Hier hat zur Zeit Linux die Nase
> > > vorn.
> >
> > Ha. Da lobe ich mir den Multi-Prozess-Ansatz von Postgres.
> > Das ist zwar unmodern und skaliert auch nicht wirklich gut
> > fuer einzelne komplexe (evtl. sinnvoll parallelisierbare)
> > Operation, aber im Multi-User-Betrieb machen sich mehr Pro-
> > zessoren praktisch linear bemerkbar; natuerlich nur, solange
> > das IO-Subsystem mithalten kann. Das widerum wird bei Free-
> > BSD noch durch den Giant-Lock gebremst (meine Postgres-
> > Kiste hat aber immerhin einen aac(4)); wie da der Stand der
> > Dinge auf der Linux-Seite ist, weiss ich nichtmal genau.
> > Jedenfalls sehne ich mich beim Kunden gerade nach "mehr I/O-
> > Bandbreite".
>
> Oben ist von -STABLE, also 4.x die Rede. Redest Du auch davon oder setzt
> Du 5.x ein?

Ich setze beides ein. Das -current-System ist ein reines Spiel^W
Entwicklungssystem, das sich nicht im Produktionseinsatz befindet.

> Wenn ja, waere -STABLE nicht die bessere Loesung fuer Dich?

Ich hab gerade nicht genug Hardware da, um wirklich vergleichbare
-current/-stable-Systeme fuer Experimente verwenden zu koennen.
Mich wuerde z.B. schon interessieren, ob die Fortschritte im SMP-
Bereich (bei 5.x) im Mittel nicht sogar die Performance-Nachteile
gegenueber RELENG_4 ausgleichen koennen. Daher auch der Hinweis
auf den -Treiber aac(4) in meiner -current-Kiste. aac(4) ist der
erste Disk-Subsystem-Treiber, der gaenzlich ohne den Giant-Lock
auskommt, d.h. er kann in mehreren Kernel-Threads gleichzeitig
aktiv sein, ergo sollte er real von mehreren CPUs profitieren
koennen.

> Speziell File-I/O scheint nach meinem Eindruck (nur lesend, nicht selbst
> mit -CURRENT arbeitend) noch ein ernsthaftes Problem bei -CURRENT zu sein.

Naja. Dann erschlaegt man das halt mit Hardware ;-) Mir ging es
bei meinen aufgeschriebenen Gedanken ja nur um das Verhalten unter
Last; sprich wir vergleichen "relative" Performance-Unterschiede.
Ob ein -current also zur Zeit (absolut gesehen) ein paar mehr CPU-
Zyklen als ein -stable oder ein Linux verbraet, ist mir das rela-
tiv egal (auf einem Testserver sowieso ;-)).

> Speziell bei mysql, wovon sich meine Firma gerade Richtung Postgres
> verabschiedet,

Viel Spass. Bei groesseren Projekten, komplexeren DB-Schemata,
groesseren Datenbestaenden warten interessante[tm] Ueberraschungen.
Wenn man das alles bewaeltigt hat, weiss man endlich *was* MySQL
dem Entwickler fuer (eigentlich wenig wuenschenswerte) Freiheiten
laesst.

> sind wir uns nicht sicher, ob so ab und an (ein, zwei Mal
> im Monat) auftretende "Haenger" (Mysql hoert auf, Abfragen abzuarbeiten,
> weitere Prozesse "stauen" sich an) nicht auf Probleme mit dem SMP
> zurueckzufuehren sind.

Hmm. Das glaube ich auch nicht. Derartige Probleme treten auf von
mir betreuten FreeBSD-MySQL-/Web-Servern auch (wenn auch sehr selten
auf). Darunter sind sowohl UP- als auch SMP-Kisten mit unterschied-
lichen Betriebssytem- und MySQL-Versionsstaenden. Irgendwie scheint
sich MySQL intern zu verklemmen.

> Der Kernel ist Linux 2.4.18, gekocht nach Debian-Rezept.

Das plattformuebergreifende Auftreten solcher Probleme deutet dann
ja endgueltig auf ein Problem in der haengenden Software.

2.4.18/Debian-Rezept laeuft auch auf den PostgreSQL-Servern im
Produktionsbetrieb beim Kunden (Dell 2550, 2*PIIIs/1.2 GHz,
Perc IIIDi RAID, 4 * IBM 10k UPM, RAID 0+1). Der Dell Perc IIIDi
und der Netraid 4M (Adaptec 5400) stammen aus derselben Controller-
Familie; wobei der 5400 das Top-Modell ist und im RAID-5-Betrieb
Vorteile gegenueber den kleineren Modellen (der Perc IIIDi muesste
ca. dem Adaptec 3200S entsprechen) haben soll. (Keine eigenen Tests
verfuegbar.)

Ich habe gerade mal ein paar bonnie++-Laeufe auf die Warm-Standby-
Maschine beim Kunden und meine -current-Box losgelassen Das Ergeb-
nis sieht so aus, dass die Ergebnisse nicht wirklich einfach ver-
gleichbar sind (was zu erwarten war). Deshalb spare ich mir die
spekulative Wiedergabe an dieser Stelle :-/

-andreas

-- 
sick.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message