nicht angemeldet
was macht die datenbank wieder schnell?
Hallo!
Wir haben hier eine Adabas D auf einem Pentium II 350 laufen (Win NT4) und so langsam merken wir das System nähert sich seinem Performancemaximum.
Da finanzielle Mittel (wie immer und überall) nicht im Übermaß vorhanden sind interessiert es mich, ob hier jemand Erfahrungen bei der Performancesteigerung eines vergleichbaren Systems hat.
Bringt ein schnellerer Prozessor (Pentium III 700 stände z.B. zur Verfügung) evtl. schon dauerhaft das gewünschte? Reicht mehr RAM? Kommt es eventuell nur auf die Zugriffszeiten der Festplatte(n) an?
Danke!
Dominique Stender
-
hallo,
Wir haben hier eine Adabas D auf einem Pentium II 350 laufen (Win NT4) und so langsam merken wir das System nähert sich seinem Performancemaximum.
Da finanzielle Mittel (wie immer und überall) nicht im Übermaß vorhanden sind interessiert es mich, ob hier jemand Erfahrungen bei der Performancesteigerung eines vergleichbaren Systems hat.Bringt ein schnellerer Prozessor (Pentium III 700 stände z.B. zur Verfügung) evtl. schon dauerhaft das gewünschte? Reicht mehr RAM? Kommt es eventuell nur auf die Zugriffszeiten der Festplatte(n) an?
unser datenbank-server war bis vor kurzem ein p-120!!! und da war die datenbank nicht mal SO klein...
als er aber mal auf dem zahnfleisch lief, haben wir ein wenig mehr ram reingesteckt und schon lief es wieder....
ram sollte also auf alle fälle sehr viel bringen, proz. vielleicht sogar gar nicht mal SO viel (kommt aber sicher auch auf den umfang der db an)gruß
jens-
Hallo nochmal.
Ach so ja, das Thema Umfang der DB... es dürften mittlerweile so um die 6gig sein, jedes jahr kommen 2-3 dazu.
Ich habe gerade einen Hinweis darauf gefunden, daß ca 15%-20% der Prozessorzeit mit Datenbanksuche verbraucht werden, der Rest geht im Code des Programmes drauf.
Da der Prozessor aber wahrscheinlich eh ungefähr 80% der Responsezeit auf Daten wartet würde ein schnellerer Prozessor meiner Meinung nach nicht all zu viel bringen (Wartezeit auf Daten würde prozentual noch weiter steigen). Der Umfang der Datenbank schließt aus, sie komplett im RAM zu halten (Solid State ist leider zu teuer ;) ), bleibt eine schnellere Festplatte, evtl. Raid.Oder ist irgendwo ein Denkfehler?
Gruss,
Dominique Stender
-
6gig????? wooow.. na GANZ so groß war(en) unsere (immerhin der komplette datenbestand von kleinen städten) dann doch nicht :)))
hm.. aber du hast recht, ram bringt es nicht unbedingt (wobei ich trotzdem kräftig ram aufrüsten würde! auch wenn der komplette datenbestand nicht in den ram paßt... aber je mehr reingeht, desto schneller ist er letztendlich). ansonsten wäre ne sauschnelle platte von vorteil, ob's raid sein soll.. hm.. geschwindigkeit hat doch IMHO nix mit raid zu tun, oder irre ich mich da? raid war doch "nur" ein system um plattencrashs abzufangen?
also: ram (am besten bis zum anschlag) + hochleistungsplatte wäre das erste was ich aufrüsten würde.
wobei es trotzdem irgendwann zu ende sein wird.. ich meine 6gig bisher und pro jahr 2-3 dazu? kann man da nicht alte sachen auslagern? weiß ja nicht um was es da geht.
gruß
jens-
ich meine 6gig bisher und pro jahr 2-3 dazu? kann man da nicht alte sachen auslagern?
Auch in diese Richtung ging meine Anmerkung zum Thema "SQL tunen".
Wir betreiben eine (wachsende) historische Kursdatenbank mit 3.5 GB Daten&Indexen.
Es gibt dabei auch Zugriffe, welche die gesamte Datenbank zum "Versand" in ASCII-Format auslesen müssen.
Aber die (wesentlich häufigeren) Zugriffe auf die Tagesdeltas erfolgen gar nicht mehr auf die Datenbank selbst, sondern auf konfigurierbar-mundfertige Dateien, die nachts in entsprechenden Produktionsläufen erstellt werden.
Cacheing ist nicht immer nur eine Hardware-Angelegenheit, sondern oftmals auch ein Thema der geeigneten Softwarearchitektur. -
Hallo nochmal,
hm.. aber du hast recht, ram bringt es nicht unbedingt (wobei ich trotzdem kräftig ram aufrüsten würde! auch wenn der komplette datenbestand nicht in den ram paßt... aber je mehr reingeht, desto schneller ist er letztendlich).
Wie ich heute Morgen erfahren hab (bin ja 'nur' webmaster, nich SysAdmin) hat der DB Server bereits ein halbes Gig RAM...
ansonsten wäre ne sauschnelle platte von vorteil, ob's raid sein soll.. hm.. geschwindigkeit hat doch IMHO nix mit raid zu tun, oder irre ich mich da? raid war doch "nur" ein system um plattencrashs abzufangen?
Ist so nicht ganz richtig. Bei einem raid werden mehrere Platten vom raidcontroller so verbunden, daß die Dateien auf alle platten gleichzeitig verteilt werden, was dann logischerweise einen Geschwindigkeitszuwachs in MB/s ergibt.
also: ram (am besten bis zum anschlag) + hochleistungsplatte wäre das erste was ich aufrüsten würde.
wobei es trotzdem irgendwann zu ende sein wird.. ich meine 6gig bisher und pro jahr 2-3 dazu? kann man da nicht alte sachen auslagern? weiß ja nicht um was es da geht.
Es geht um das onlinearchiv der Aachener Zeitung... also alte Sachen auslagern wäre nicht im Sinne der Sache :)
Danke!
Dominique Stender
-
ansonsten wäre ne sauschnelle platte von vorteil, ob's raid sein soll.. hm.. geschwindigkeit hat doch IMHO nix mit raid zu tun, oder irre ich mich da? raid war doch "nur" ein system um plattencrashs abzufangen?
Ist so nicht ganz richtig. Bei einem raid werden mehrere Platten vom raidcontroller so verbunden, daß die Dateien auf alle platten gleichzeitig verteilt werden, was dann logischerweise einen Geschwindigkeitszuwachs in MB/s ergibt.Analog kann man auch wieder die Datenbank (bzw. die Dateisystemstruktur, welche deren Datencontainer beinhaltet) tunen, also beispielsweise eine häufig angesprochene Tabelle über mehrere physikanische Platten "streifen", damit mehrere parallele Zugriffe nicht im Positionieren des Plattenkopfes ersticken usw.
Tabelle und Index auf verschiedene Platten zu legen ist ja wohl selbstverständlich.
-
-
-
-
-
Bringt ein schnellerer Prozessor (Pentium III 700 stände z.B. zur Verfügung) evtl. schon dauerhaft das gewünschte? Reicht mehr RAM? Kommt es eventuell nur auf die Zugriffszeiten der Festplatte(n) an?
Versuch es erstmal mit RAM. Prozessoren werden hauptsächlich durch Grafik ausgelastet, "nomrale" und "sinnvolle" Anwendungen wie Datenbanken brauchen eher Speicher als Rechenpower. (es sei denn sie sind von Microsoft, dann fressen sie alle Ressourcen).
Gruß
Cruz -
Bringt ein schnellerer Prozessor (Pentium III 700
stände z.B. zur Verfügung) evtl. schon dauerhaft
das gewünschte?Solange weder "dauerhaft" noch "das gewünschte" klar
definiert sind, ist diese Frage schwer zu beantworten.
(Ich denke "5 Jahre" würde Dir ja reichen, weil Du
anschließend den Pentium 700 abschreiben würdest.)Reicht mehr RAM? Kommt es eventuell nur auf die
Zugriffszeiten der Festplatte(n) an?Es kommt mit 90+% Wahrscheinlichkeit nicht "nur" auf
ein einziges Element an.Performance Tuning ist so ziemlich das komplexeste
Thema, das ich kenne.
Da geht es darum, etablierte, funktionierende Verfahren
zu hinterfragen - das ist für den Entwickler dieser
Verfahren bitter. (Ich habe das beim Tuning der Such-
maschine dieses Forums-Archivs hier gemerkt: Mein
Code war wunderbar lesbar, aber entsetzlich langsam.)Durch das Wachstum der Datenmenge wird das Auffinden
von Daten nicht zwingend deutlich langsamer - durch eine
Architektur der Datenbank, welche lineare statt logarith-
mische Suchzeiten provoziert, aber sehr wohl.
Häufiges Einfügen und Löschen von Daten degeneriert
auch eine gute, indexbasierte Infrastruktur mit der
Zeit spürbar: So, wie Du Deine Festplatte durch Defrag-
mentierung wieder flotter bekommst, so kann auch eine
Reorganisation Deines (großen) Datenbestandes einiges
bringen.Was ich damit sagen will: Zuallererst würde ich eine
Performanceanalyse machen.
Wie aufwendig das ist, das hängt davon ab, wie komplex
Deine Datenbank ist und wie gut Du Dich auf unterster
Ebene (also tiefer als SQL) darin auskennst.Ein neuer Rechner kann Dir Faktor 2 alle 18 Monate
bringen. Wieviel RAM etwas bringt, kannst Du durch
Messung der entsprechenden Ressourcennutzung im
Betriebssystem feststellen (swap rates etc.).
Aber eine algorithmische Verbesserung der Zugriffspfade
kann mehrere Zehnerpotenzen an Tempo bringen, wenn der
ursprüngliche Entwurf nicht gezielt auf die heutigen
Anforderungen ausgelegt war.
Ein einziges CREATE INDEX kann mehr bringen als der
teuerste Rechner, den Du bezahlen kannst.Oracle empfiehlt in seinem Performance-Handbuch,
zuallererst die SQL-Anweisungen zu tunen.
Es gibt einfach nichts, wo man vergleichbare Geschwindig-
keitsfaktoren gewinnen, aber auch verlieren kann, wie bei
der Formulierung von 4GL-Anweisungen.