FreeBSD oder Solars für DB-Server?

Solars x86 oder FreeBSD 7.x für großen PG DB-Server
nehmen?

Moin,

Wie einige ja wissen arbeite ich an einer großen Website
wo viele leute gleichzeitig eingeloggt sind und ständig
parallel anfragen an die DB schicken.

Vom reinen Performanceansatz her, würde ich da gerne
einen dedizierten DB-Server aufsetzen. Mein Provider bietet da Maschinen mit RAID Controller und den zugehörigen Platten sowie RAM nach Bedarf (bis zu 16 GByte) auf AMD64 CPU’s (X2 Athlon Doppelkern)

Die Frage ist nun:
Welches OS nehme ich damit ich Postgres im Terrabyte
bereich fahren und diverse Slaves Problemlos spiegel kann?

Es stehen FreeBSD und Solaris zur Wahl.

Vermutlich geht beides ähnlich gut. Wichtiger ist, z.B. das RAID gescheit aufzuteilen. Wenn Du die Chance hast, separate Spindeln für Daten, Index und TX-Log zu nehmen bringt das mehr als die Entscheidung zwischen zwei Nixen.

Andreas

Außerdem: das erste Entscheidungskriterium sollte sein:

Nimm das Unix, das du besser kennst.

Was bringt das beste Unix wenn du nicht weißt wie du das tunen kannst? Damit verlierst du mehr als du gewinnst.

Danke für die Antworten.

Wie es ausschaut wird Solaris mit seinem ZFS
Filesystem überall als das SuperFS in den Himmel
gelobt. Es kann schon RAIDS selber verwalten und
ist 128 Wort-Bit breit. Die grösse das FS lässt
sich im laufenden Betrieb anpassen.

Habe gerade einen Benchmark zwischen OpenSolaris
mit ZFS und FreeBSD 7.x UFS FS gesehen der ziemlich
interessant ist:

Halis way: PostgreSQL 8.1 on ZFS in Solaris

Wie es ausschaut arbeitet man auch schon an der
Clusterfähigkeit, dann lässt sich das ganze noch Spiegeln
und verteilt über mehrere Server ansprechen (z.B in SAN
Umgebungen). Dann würde im Falle von Postgres
einfach jeder DB-Server-Rechner auf das ZFS ClusterFS
zugreifen, dann wäre ein Spiegelung nicht mehr notwendig.

Die Frage ist nur, ob ZFS den konkurrierenden Zugriff
der einzelnen Postmaster untereinander sauber steuert
oder ob Postgres das noch selber lernen muss.

Der Benchmark ist zwei Jahre und die verwendete PostgreSQL Version 2 Majorversionen alt. Außerdem habe ich auf der FOSDEM dieses Jahr einige sehr nette Grafiken bezüglich FreeBSD gesehen … deren neuer Scheduler rockt anscheinend.

Das Betriebssystem spielt halt auch eine große Rolle, nicht nur das Dateisystem. Aber letzten Endes musst du damit umgehen können und ich empfehle sogar ein Windows wenn ich weiß das die Leute nur damit umgehen können.

Selbst wenn Du mit Win gut umgehen kannst, heisst
es noch lange nicht das Du es für sowas wie einen
DB-Server guten gewissen empfehlen kannst.
Genauso gut könntest Du auch MS-DOS empfehlen,
von daher macht sich etwas CrossoverWissen manchmal
bezahlt, spezialisieren kann man sich noch immer.

(Bei Win spielt die Edition = Gewaltiger Preisunterschied,
sowie extra Spezialsoftware (Memmorymanagement)
eine Rolle um die schlimmsten Macken von NTFS und Kernel
zu umschiffen.

ps:
Irgendwann lernt jeder die Höhen und Tiefen eines
Systems kennen, aber immer erst auch dann wenn er
damit arbeitet (ist bei allen Dingen so).

Ich kann es nicht wirklich empfehlen. PostgreSQL läuft unter Windows und das nicht schlecht. Aber die Plattform eignet sich meiner ganz persönlichen Meinung nach nicht als Serverplattform.

Nun, aber wenn jemand nur Windows kennt dann werde ich ihm in jedem Fall Windows empfehlen ehe ich ihm irgendein Unix empfehle. Das war der Sinn meiner Aussage.

Alles klar.

Dann stellt sich jetzt hier eigentlich nur noch die provokante
Frage ob Du auch ein paar Ideen zum Kernthema beisteuern kannst.

Solaris x86 oder FreeBSD 64-Bit für Postgres, wenn man davon
ausgehen kann, daß der Admin Manpages lesen, das System
entsprechend bedienen und auch tunen und mittels Paketfiltern
auch sichern kann.

Hardware: Athlon X2 Dualcore 64-Bit, 2 - 4 GByte RAM und
SCSI Hardware RAID Controller mit 4 Platten (additive
Gesammtkapazität aller Platten 3 Terrabyte).

Ferinstallationssystem: Eine Lara mit Bildübertragung.

Netzwerkanbindung 100 MBits Fast Ethernet zum 62 Gigabit
Backbone des Providers.
Trafficflat.

Das ist dann egal, soviel nehmen sich beide Systeme nicht.

Und die Details kennt dann wirklich der Admin. Z. B. welchen Scheduler man unter FreeBSD nimmt um einen optimalen Durchsatz zu erreichen oder wie man unter Solaris Kernelparameter einstellt. Beide Systeme sind aktuell und werden als Datenbankserver unter hoher Last eingesetzt.

Von daher läuft die Antwort wiederum darauf hinaus: nimm das, was du am besten kennst.

Ok, in diesem Fall wohl eher FreeBSD, denn mit Solaris x86 habe ich nur herrumexperimentiert.

Täusch ich mich oder ist der Kernel von Solaris x86 auch noch recht
frisch? Ich meine daß gab es Jahre nur für deren SPARC CPU’s und
dann gabs von wenigen Jahren das erste x86 Release. Aber so einen
Kernel für Intel anzupassen ist doch nicht ganz so trivial, da braucht
es doch auch eine gewisse Zeit bis alles rund läuft - ist diese
Halbwertszeit denn schon erreicht?

Momentan tendiere ich mehr zu FreeBSD. Vielleicht kommt ja später
eine Solariskiste dazu. Allerdings hat ZFS auch seinen Charme.
Erweiterung des Speicherplatz im FS ohne Downtime durch
hinzufügen einer neuen Platte sowie SW Raid im FS integriert,
das ist nun wirklich nett.

Nun, als wir gegen 2000 mir Solaris sowohl auf SPARC wie auf x86 gearbeitet haben war das damals schon flinker unterwegs als Linux. Seitdem hat es diverse Jahre Zeit zum Reifen gehabt. Ich denke nicht das man da von “neu” sprechen sollte.

Allerdings hat SPARC seine Vorteile die du hier aber nicht ausspielen kannst.

Zum Dateisystem: ich weiß nicht genau wieviel von den Features des ZFS ein normales LVM nicht auch kann - bzw. welche nicht vorhandenen Features du davon brauchst. Das solltest du vielleicht noch vergleichen.

Tatsache ist, das ZFS in den meisten Benches wohl besser
abschneidet als UFS2, da es eine komplette Neuentwicklung ist
und die Anforderungen der Zukunft ausgerichtet wurde. Ich
schätze mal zu Zeiten von UFS2 war noch nicht klar, das wir
in der Zukunft exorbitant hohne Speicherkontingennte benötigen
werden, das es SOLID State Disks ohne Mechanik im großen
Umfang geben wird und das man das RAID Konzept bereits
besser in das FS integriert als es rundherumm baut.
Auch ist es es gut, das die heutigen Hardwarestandards
mit berücksichtigt wurden und der RAM für effizientes
Caching voll einbezogen wird.

Mit ZFS bin ich wirklich in der Lage, ohne das ich Mount
points definieren muss, auf die ich dann gezielt zugreifen
muss, einfach mehr Plattenspeicher “hinzuzufügen”.
Eine Platte rein, schon mehr Platz für Programme,
Files und Co ohne das sich Pfade oder das Programme
angepasst werden müssten.

Alles im allem bin ich mit ZFS wirklich in der Lange unlimitiert
mehr Festplattenspeicher für mein System bereitzustellen,
so wie es die Anforderungen diktieren und das Sytem wird
mit dem Anwachsen des Filepensums auf der Platte nicht
langsamer sondern eher fixer, da die Algorithmen zur
Bereitstellung der Informationen ab mittel bis großen
Datenmengen erst richtig zum Zuge kommen.

Auch denke, ist dieses FS das erste dass SQL Datenbanken
in Ihrer Architektur sehr entgegenkommt und sie weitestgehend
unterstützt (sieht man z.B an den ausgezeichneten FSYNC()
Werten des Postmasters mit Postgres 8.3.x, die weder
mit UFS2/ EXT2/ EXT3/ XFS / NTFS / HFS / HPFS
reinzuholen wären.

NAtürlich muss man sich jetzt aber die Frage stellen, wie man
jetzt Tablespaces mit Postgres vernünftig definieren will,
wenn die DB auf einem derartigen FS läuft. Vermutlich werde
ich hergehen und bestimmte ZFS Volumes nur für die Logs und
den Rest für die Tablespaces definieren.

ps: ZFS mittels FUSE Abstraction auf anderen *Nixen ist wohl
nicht das gelbe vom Ei, momentan läuft es unter Solaris wohl
am besten.

Danke für die ausführlichen Erklärungen, das nenne ich mal informativ.

Dafür musst du aber wiederum ein zweites ZFS definieren um sicherzustellen dass das Dateisystem wirklich auf eine andere Platte schreibt, oder?
Ansonsten weißt du ja nicht welche Platte das Dateisystem aktuell für deine Daten benutzt - diese Information abstrahiert ZFS von dir.

Ja, kann man so sagen.

Ansonsten weißt du ja nicht welche Platte das Dateisystem aktuell für deine Daten benutzt - diese Information abstrahiert ZFS von dir.

Nein, Du kannst ZFS sagen welche Platten es in ein Volume integrieren
soll.

Spannend ist auch das Java API das SUN anbietet, damit lässt sich dann
ZFS vom eigenen Programmseitig steuern. Ist sicher für Internetprovider
die dynamisch Plattenpatz zuweisen müssen eine interessante Sache.

Vielen Dank für die Informationen.

Aber das mit dem dynamischen Erweitern von Speicherplatz habe ich doch im Prinzip mit einem LVM unter Linux auch, oder?
Läuft die Partition langsam voll werfe ich halt eine neue Platte rein, Füge dieser der Volumegroup bei und erweitere das Dateisystem entsprechend.

Oder ist das System sehr ähnlich nur halt über das FS umgesetzt? Wobei dann ja schon einge gewisse Unterstützung seitens des Kernels da sein muss.

Gruß
Sparrow

Auch ZFS macht nicht einfach was es will, sondern was es soll … und natuerlich kann man auch ZFS so planen/konfigurieren, dass die physikalische infrastruktur den anforderungen “entgegenkommt” … bei ZFS redet man dann halt nicht mehr von Platten od. Partitions, sondern von “Pools” … auf diese wuerde man dann entsprechen tablespaces verteilen

Das ist es ja eben, ZFS bringt alle erprobten und von Profis geschätzten
Mechanismen wie SW Raid ins Dateisystem, volles ausreitzen der
modernen Hardware, Programmier API um FS Aufgaben automatisiert
abzubilden sowie unzählige Stellschrauben die Performance immer
weiter zu optimieren.

Sehr große Dateisysteme zu verwalten und beste Ubterstützung für
Relationale DB’s sind so zu sagen dort nicht mal der ERwähnung wert und
werden auch gar nicht groß promotet. Aber Leute die das mal messen
erleben ihr wahres Wunder. Bisher galt immer FreeBSD mit dem FreeBSD
eigenen FS UFS2 als bestgeignet für Postgres, mittlerweile geht
hier Solaris mit ZFS klar in Führung und baut seinen Vorsprung
stetig aus. Ist ja auch irgendwie logisch, denn ZFS ist ein grundneues
Design das den Bedürfnissen von DB-Admins sehr entgegenkommt.

Zumindest waren das laut SUN die Hauptbeweggründe. Es gibt auch
offene Türen für ZFS zu anderen **nixen, aber unter Solaris ist es
halt am ebsten integriert.

:slight_smile:

Ebenso interessant wie die Stärken, wär es die Schwächen von ZFS zu erfahren … “Grund-Neues-Design” hat garnichts zu bedeuten - es ist eher anzunehmen, dass besseres Management ein bisschen performance “frisst” - was wiederum aber nicht so ins Gewicht fällt, weil HW effizienter wird …

Man entscheidet sich ja nicht fuer ZFS aus Performancegründen - nichtmal zweitrangig - da spielen andere features eine Rolle die es mir ermöglichen weitgehends ausfallsichere Systeme zu bauen - oder der enorme Adressraum, der schön ist für große Dateien … aber wie verhält es sich mit vielen vielen kleinen Dateien? Fragen die sich keiner Mehr stellt bei big-is-beautyfull

übrigends - ich persönliche komme mit 32 bit PKs nachwievor wunderbar klar :wink: … es gibt bei mir gerade eine tabelle bei der 64 bit eine überlegung wert sind

Ich bitte um Entschuldigung dafür, dass ich diesen alten Thread wieder ausgrabe, aber vielleicht wird früher jemand über ihn stolpern, daher folgen Information:

Ich hab in einer der letzten Ausgaben der LinuxUser gelesen, dass der Einsatz von ZFS unter Linux dank FUSE möglich ist. Quellen für Ubuntu waren angegeben, also hab ich das ganze direkt mal ausprobiert.

Installation, Einrichtung und Einsatz funktionierten problemlos. Soweit ich testen konnte lief alles stabil. Performance konnte ich nur im Kleinen testen: die war ok, keine Ausreißer.

Soviel nur zur Info. Produktiv werde ich es wohl nicht einsetzen, aber das Ausprobieren war recht spannend.

Gruß
Sparrow

FUSE wird nicht im Kernel sondern - wie der Name schon sagt - im Userspace betrieben. Daher denke ich nicht, dass die Performance an ein “richtiges” Dateisystem heranreicht.

Aber nichts gegen ein paar gute Testergebnisse :wink: