Re: FreeBSD Features und Beschränkungen

Matthias Teege(matthias(at)mteege.de)@2002.05.30 13:04:47 +0000:
> On Thu, May 30, 2002 at 11:08:57AM +0200, Peter Ross wrote:
> > Angeblich wäre die Sache auf einem schnellen PC mit ordentlich Speicher
> > unter Linux wesentlich schneller als auf der Sun.
> >
> > Wie gesagt - das ist Theorie und sollte erst getestet werden, wo uns dann
> > die 2GB-File-Grenze des 2.2er Linux-Kernels auf den Fuß fiel und mich nach
>
> Für mich sieht das eher wie ein schlechter Workaround aus. Das
> wöchentliche Verschieben einer solchen Datenbank wäre mir zu
> gefährlich. Man stelle sich nur einmal vor die Datenbank wird beim
> Reorganisieren geschrottet ohne das es jemand merkt und die Fehler
> werden erst am kommenden Freitag sichtbar. Natürlich kann das auch

workarounds sind halt manchmal notwendig (auch wenn sie nicht schoen
sind ;-)

integritaetsprobleme kann man recht easy umgehen:

find /path/to/db/tree | cpio -o | gzip -2 \
  | ssh user(at)otherhost 'gzip -d | cpio -i /target/path && script.sh'

sollte im falle eines checksum mismatch einfach script.sh nicht
ausfuehren. sinnvoll ist es, ssh compression und pubkey auth aufzusetzen
mit adequater restriction. der transportweg ist auf jeden fall nach
diesem system dreifach gesichert (tcp, ssh und gzip); ist das paranoide
genug? trotzdem wuerde ich's wegoptimieren das kopieren.

> bei der jetzigen Konfiguration auftreten aber Ihr beabsichtigt gerade
> eine Vervielfachung der Komplexität und der möglichen Fehlerquellen.

da hast du recht. ich wuerde es auch auf einer kiste lassen und auf die
pc-muehle nightly backups fahren.

>
> Wenn die Hardware der Datenbank nicht mehr gewachsen ist, wird es
> Zeit für neue (schnellere) Hardware oder eine effizientere Software.

schnellere hardware von sun ist in den meisten produktionsumfeldern
keine wirkliche option fuer die schlipstraeger ($$$).
schnellere software ist meist auch keine option wenn es sich um ein
komplexes system von frontends handelt, die in diesem falle (OO DB)
bestimmt kein standard SQL sprechen. also doch hardware kaufen ;-)
(sorry fuer's drauflosgerate, aber ich hab schon einige solche
szenarien durchgemacht)...

erstmal wuerde ich ueberhaupt die frage stellen, wo das bottleneck denn
sei. im zweifelsfalle tut's ja auch ein gescheites disk-subsystem (neu),
denn wenn die DB (poet kenn ich nicht wirklich) einigermassen gescheit
implementiert ist, dann sollte sie io-bound sein und nicht cpu-bound,
oder?

gruss,
/k

-- 
> UNiX *IS* user friendly. It's just selective about who it's friends are.
WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD
http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.de/
GnuPG:   0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4  A113 B393 6BF4 DEC9 48A6
REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 BF46
REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C  5F 0B E0 6B 4D CD 8C 44
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 10x

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message
Received on Thu 25 Jul 2002 - 14:42:35 CEST