Re: 64 Bit auf WebServer

Alvar Freude <alvar(at)a-blast.org> wrote:
> Oliver Fromme <olli(at)lurza.secnetix.de> wrote:
> > i386 und amd64 sind beide Little-Endian, und die Dateien
> > sind formatkompatibel, soviel ich weiß.

Das sie (leider) nicht formatkompatibel sind, darauf wurde
ja schon hingewiesen.

> dass i386 und amd64 beide Little-Edian sind ist schon klar, nur PPC zum
> Beispiel nicht ;)

In diesem Thread geht es aber speziell um FreeBSD/amd64
vs. /i386.

> Allerdings würde es ja bei jedem Zugriff entsprechend Konvertierungszeit
> kosten, wenn die Byteorder jedes mal angepasst werden muss; das wäre
> dann ja eher ungeschickt bei performance-kritischen Sachen

Ich glaube nicht, daß man davon etwas merkt. Das Byte-
Swapping passiert direkt im Prozessorregister und dürfte
im Vergleich zu Speicherzugriffen oder I/O praktisch ver-
nachlässigbar sein.

TCP/IP und die meisten darauf basierenden Protokolle ver-
wenden ja auch Big-Endian (wird daher ja auch Network-
Byteorder genannt), ohne daß i386-Server deswegen massive
Performanceinbußen erleiden.

> > Das kommt ganz drauf an, wie die betreffende Serverfarm
> > aufgesetzt ist. Es ist z.B. durchaus nicht unüblich, daß
> > die Daten von einem Netzwerk-Massenspeicher kommen (sei es
> > per NFS, iSCSI oder sonstwas).
>
> machte NFS in manchen Szenarien nicht große Probleme? Ich habe da sowas
> dunkel in Erinnerung, kann aber auch sein dass dies nur bei anderen
> Szenarien (nicht Datenbanken) zutrifft.

Ich habe solche Setups unter meinen Fittichen, es macht
keinerlei Probleme.

> Nur dürfen natürlich nicht
> mehrere Server gleichzeitig auf die Daten zugreifen, das geht dann schief!

Das ist natürlich klar. Aber ein Hot-Standby-Server, der
sich bei Bedarf die Datenbankdateien unter den Nagel reißt,
ist durchaus denkbar. Gerade PostgreSQL ist da ja äußerst
robust: Du kannst einfach brutal den Stecker ziehen, dann
die Dateien auf einem anderen Server mounten, und dort das
PostgreSQL wieder starten.

> > Klar, es gibt work-arounds, z.B. das pg_dumpall ausreichend
> > lange vorher laufen lassen, in die neue Datenbank reinfüt-
> > tern, dann die WAL-Journals seit dem Anlegen der Dumps in
> > der neuen Datenbank nachspielen ... Damit minimiert man
> > die Ausfallzeit auch, aber es ist »fummlig« und aufwendig,
> > nach dem Motto: Wieso einfach, wenn's auch komplizert geht?
>
> das ist nicht fummelig, das ist ekelig! ;-)

Nunja. Wenn's dann aber mal funktioniert, hat es schon
diverse Vorteile. Es erfordert halt nur erstmal etwas
Aufwand zum Aufsetzen.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
        -- Chris Torek
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message