PostgreeSQL mit zunehmender Dauer lahm?

    • Tekras
      Tekras
      Black
      Dabei seit: 03.02.2006 Beiträge: 2.789
      Hi,
      hab vor einger zeit auf postgree gewechselt weil es hieß, das diese datenbanken im gegensatz zu aceess datenbanken, nahezu belibig groß werden können ohne deutlich spürbaren performance verlust.

      eigentlich hatte ich vor, eine einzige große sql datenbank zu führen.
      nachdem ich nun aber wieder ca 500k hände importieren wollte hat es mich doch schon sehr verwundert das PT für eine 300 HH File fast 1 1/2 Minuten benötigt(10k in 1 1/2 std, hab heute während meiner arbeit grade mal 50k hände in 8std geschafft ) eine niegelnagelneue acess datenbank benötigt grade einmal 10sek

      sollte man also auch bei postgree regelmäßig neue datenbanken anlegen -und wenn ja - wie groß sollte eine datenbank maximal sein?

      kann man sonst die datenbanken noch pflegen außerhalb von PT und den vacuum optionen?

      danke schonmal für (hoffentlich) eure antworten

      gruß lukas
  • 25 Antworten
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Tekras
      eigentlich hatte ich vor, eine einzige große sql datenbank zu führen.
      nachdem ich nun aber wieder ca 500k hände importieren wollte hat es mich doch schon sehr verwundert das PT für eine 300 HH File fast 1 1/2 Minuten benötigt(10k in 1 1/2 std, hab heute während meiner arbeit grade mal 50k hände in 8std geschafft )
      Bei grossen Datenbanken solltest du dich mit der "postgresql.conf" auseinandersetzen. Einige Parameter können hier die Performance massiv verbessern. Auch darf dein Virenscanner unter keinen Umständen das "data" Verzeichnis von PostgreSQL scannen. Ansonsten kann es a) zu Datenverlust kommen und b) zu massiven Performance Problemen.


      eine niegelnagelneue acess datenbank benötigt grade einmal 10sek
      Die ist ja auch leer.


      sollte man also auch bei postgree regelmäßig neue datenbanken anlegen -und wenn ja - wie groß sollte eine datenbank maximal sein?
      Neue Datenbanken können die Performance verbessern, je nach dem wie PT arbeitet (habe kein PT). Generell ist das anlegen mehrerer Datenbank aber nicht nötig. Wir haben hier eine Pg-Datenbank mit mehreren 100-Millionen Einträgen und die läuft sauber.


      kann man sonst die datenbanken noch pflegen außerhalb von PT und den vacuum optionen?
      Vacuum ist schon mal sehr wichtig. Die Performance einer Pg-Datenbank definiert sich aber hauptsächlich durch eine schnelle Festplatte, viel Speicher und eine saubere Konfiguration (postgresql.conf).
    • Pete70
      Pete70
      Bronze
      Dabei seit: 14.04.2006 Beiträge: 919
      Original von Temar

      Bei grossen Datenbanken solltest du dich mit der "postgresql.conf" auseinandersetzen. Einige Parameter können hier die Performance massiv verbessern. Auch darf dein Virenscanner unter keinen Umständen das "data" Verzeichnis von PostgreSQL scannen. Ansonsten kann es a) zu Datenverlust kommen und b) zu massiven Performance Problemen.

      Da ich massive Performanceprobleme hab: Wie erkenn ich, ob mein Virenscanner das macht? Ich hab den Virebscanner AntiVir. Kann das da passieren?
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Pete70
      Da ich massive Performanceprobleme hab: Wie erkenn ich, ob mein Virenscanner das macht? Ich hab den Virebscanner AntiVir. Kann das da passieren?
      Als Faustregel würde ich sagen, dass er's macht wenn du's nicht per Hand abgeschaltet hast. Kannst ja mal die AntiVir Dienste abschalten und dann schauen, ob es besser wird. Das geht unter Systemsteuerung->Verwaltung->Dienste. Dann ist der AVG ganz aus.

      Bei AntiVir kann man irgendwie nur angeben, dass er die Dateien eines bestimmten Prozesses nicht scannen soll. Bin aber gerade mit Infernogott am basteln an seiner DB und da hat das anscheinend nicht geklappt.
    • TryToGetYou
      TryToGetYou
      Black
      Dabei seit: 22.04.2005 Beiträge: 4.889
      Original von Temar

      Bei grossen Datenbanken solltest du dich mit der "postgresql.conf" auseinandersetzen. Einige Parameter können hier die Performance massiv verbessern.
      Selbes Poblem bei mir, der tracker braucht für ne 100HH file ne ganze Minute, was er am anfang innerhalb von 2 sekunden geschafft hat.

      Frage ist jetzt, welche parameter man wie verändern kann, um die performance zu verbessern und wie eine optimale einstellung aussieht. oder ob die optimale einstellung schon von haus aus gegeben ist?

      btw, mit antivir hab ich versucht, macht keinen unterschied ob an oder aus.
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Rennwurm
      Selbes Poblem bei mir, der tracker braucht für ne 100HH file ne ganze Minute, was er am anfang innerhalb von 2 sekunden geschafft hat.
      Je grösser die Datenbank, desto mehr Speicher benötigt PostgreSQL um die Indexe im Speicher zu halten, die Zugriffspfade zu berechnen und die Ergebnisse zu sortieren. PostgreSQL belegt diesen Speicher aber nicht von selbst, sondern arbeitet immer mit fest eingestellten Werten.


      Frage ist jetzt, welche parameter man wie verändern kann, um die performance zu verbessern und wie eine optimale einstellung aussieht. oder ob die optimale einstellung schon von haus aus gegeben ist?
      Die Standardeinstellungen sind extrem konservativ und taugen nicht für grössere Datenbanken. Was du für eine performante Postgres DB brauchst ist vor allem viel Speicher und eine schnelle Festplatte. Der Prozessor ist nebensächlich, da ihr eh immer nur einen Client habt, der auf die DB zugreift (PT/PA) und die Zugriffe auch immer die selben sind - d.h. die Zugriffspfade ändern sich nicht wesentlich. Erst bei wirklich grossen Datenbanken und vielen unterschiedlichen Zugriffen spielt die Prozessorleistung wieder eine wesentliche Rolle.

      Bevor du loslegst aber noch eine Warnung: Einige der Parameter die du tunen kannst können dazu führen, dass Postgres nicht einmal mehr startet, weil das Betriebssystem nicht die nötigen Voraussetzungen hat (z.B. Anzahl Shared Memory Segments). Desweiteren betreibe ich Postgres nur unter Unix und habe daher von den Tücken des Windows-Betriebs nicht sonderlich viel Ahnung. Die Tuning-Konzepte sind allerdings die gleichen. Bevor du also durchstartest solltest du erstmal ein Backup deiner Datenbank anlegen (obwohl eigentlich nichts passieren kann).

      Um Postgres wirklich flott zu bekommen sollte man es als erstes auf eine eigene Partition verschieben - besser noch auf eine eigene Festplatte. Obwohl moderne Dateisysteme eigentlich relativ wenig fragmentieren, ist das doch ein Faktor der dich schnell mal 10-20% Performance kosten kann. Eine eigene Festplatte ist noch einmal besser, da die Postgres Zugriffe dann von den Windows-Festplattenzugriffen getrennt sind. Möchte man das maximal mögliche rausholen, dann legt man sich ein RAID 0 - oder für mehr Datensicherheit RAID 0+1 Array - an und lässt Postgres darauf werkeln. Aber das ist dann nur noch für Leute interessant, die _wirklich_ grosse Datenbanken haben (100 Millionen Datenbank-Einträge). Trotzdem ist gerade die Festplattenperformance ein entscheidender Faktor beim Postgres Tuning. Das Minimum sollte daher eine eigene Partition sein.

      Wenn du nicht mindestens 1GB Hauptspeicher hast, dann brauchst du eigentlich an dieser Stelle gar nicht mehr weiterlesen. 512 MB dürften gerade einmal ausreichen um alle Applikationen zu starten (PP, PT/PA, Postgres), ohne das der Rechner mit dem Auslagern von Speicher beginnt.

      Während man beim Festplattentuning nicht viel falsch machen kann, ist das Speichertuning eine heikle Sache. Setzt man die Parameter falsch, so macht man aus einer langsamen Datenbank eine grottenlahme Datenbank. Das ganze ist also mit Vorsicht zu geniessen und man sollte schon begründen können, warum man diesen oder jenen Parameter verändert. Für optimales Tuning muss man ein wenig mit den Werten spielen.
      Standardmässig dürfte Postgres unter Windows so ungefähr 30 MB Speicher belegen. Das ist für einen Rechner mit 512 MB ein akzeptabler Wert, da andere Applikationen auch noch Speicher benötigen und der Rechner auf keinen Fall anfangen soll Speicher auf die Festplatte auszulagern. Aus diesem Grund sollte jeder mit nur 512 MB erstmal die Finger vom Speichertuning lassen, es sei denn er weiss genau was er tut.

      Den Speicherverbrauch von Postgres richtig einzustellen kann eine Verbesserung von mehreren 100% Performance bringen. Man muss sich im klaren darüber sein, dass Speicherzugriffe VIEL schneller sind als Festplattenzugriffe. Alles was im Speicher liegt ist nahezu sofort verfügbar und muss nicht mühsam auf der Festplatte zusammengeklaubt werden. Deshalb gilt zuallererst einmal der Grundsatz: Je mehr desto besser. Gesteht man Postgres allerdings zuviel Speicher zu, dann fängt Windows u.U. an diesen auf der Festplatte auszulagern. Das Resultat ist dann eine noch langsamere Datenbank als vorher.

      Die folgenden Parameter beziehen sich auf die Datei "postgresql.conf" welche im "Data" Ordner des Installationsverzeichnisses zu finden ist. Nach einer ßnderung dieser Datei muss PostgreSQL neu gestartet werden. Man kann hier unzählige Parameter tunen, doch im folgenden werde ich nur auf die wichtigsten eingehen:

      shared_buffers
      Dieser Parameter legt fest, wieviel Speicher die Datenbank als eigenen Cache verwendet. In diesem Speicherbereich werden alle Daten, die von der Festplatte gelesen wurden, zwischengelagert und sind somit bei Bedarf sofort verfügbar. Je grösser dieser Cache ist, desto besser. Man muss aber beachten, dass Postgres auch noch für andere Dinge Speicher verwendet. Deshalb darf man nicht den kompletten (freien) Speicher den Shared Memory Segments zuweisen, sondern muss noch ein wenig Luft lassen. Für Serverinstallationen mit vielen Verbindungen, nimmt man hier i.d.R. ca. 10-20% des freien Speichers. Nachdem ihr allerdings immer nur eine Verbindung habt, kann's ruhig ein wenig mehr sein. Gute Werte liegen hier im Bereich von 10000 - 20000 oder mehr. Jedes Segment belegt dabei 8kb an Speicher. Gibt man zuviel an, dann kann es sein, dass die Datenbank nicht mehr startet, weil Windows nicht genügend Segmente erlaubt oder zur Verfügung stellen kann. Nachdem ich keine Ahnung von Postgres unter Windows habe, müsst ihr das einfach ausprobieren.

      work_mem
      Dieser Parameter gibt die Grösse der Puffer an, die für Sortieroperationen und Hashtables verwendet werden. Allerdings ist das kein absoluter Wert, sondern ein Wert pro Operation. Wenn also eine Datenbankanfrage aus 3 Sortieroperationen besteht, dann müsst ihr den Wert mal drei nehmen. Hier kann ich keine allgemeingültigen Empfehlungen geben, da ich kein PT/PA habe und somit auch nicht weiss wie bei deren Operationen der Sortierbedarf aussieht. Dieser Parameter ist sehr gefährlich, da er schnell dazu führen kann, dass Windows Speicher auf die Festplatte auslagert. Ihr solltet also im Betrieb euren Speicherbedarf genau im Auge behalten, bis ihr die optimalen Einstellungen gefunden habt.

      max_fsm_pages
      Dieser Wert gibt die Grösse der "Free Space Map" an. Diese wird besonders bei vielen INSERT und DELETE Anweisungen relevant. Wenn ihr also viele Daten importiert, dann solltet ihr den Wert ein wenig hochschrauben. Für den Normalbetrieb, bei dem nur alle paar Minuten ein paar HHs importiert werden, würde ich ihn aber fast erstmal so lassen.

      fsync
      Ein sehr gefährlicher Parameter, da er (sollte euer Rechner mal abstürzen) zu einer geschrotteten Datenbank führen kann. Dieser Wert ist vor allem dann interessant, wenn ihr viele Daten importiert. Jede Operation wird bei Postgres als Transaktion abgebildet. Jede Transaktion wird in einer Datei vermerkt. Der Parameter "fsync" gibt nun an, ob diese Datei nach jeder Transaktion sofort geschrieben werden soll. Setzt man ihn auf 0, so wird diese Datei nicht ständig aktualisiert, was wiederum einiges an Performance bringen kann (bei Imports). Stürzt allerdings euer Rechner ab, dann weiss Postgres nichts über die Transaktionen und die Datenbank kann daher korrupt sein.

      Dies waren jetzt die meiner Meinung nach wichtigsten Parameter. Es gibt noch einige mehr, die die Performance massiv verbessern können, nur sollte man hier schon tiefere Kenntnisse über Betriebssysteme und Datenbanken mitbringen. Wer _wirklich_ grosse Datenbanken fährt und mit Poker seinen Lebensunterhalt bestreitet, der kann sich ja mal bei mir melden und wir arbeiten dann einige Werte aus. Alle anderen sollten mit den obigen Parametern ganz gut klar kommen.

      Ein Hinweis noch am Schluss: NICHT ßBERTREIBEN. Setzt die Werte langsam und in mehreren Schritten nach oben, bis ihr das Optimum für euren Rechner gefunden habt.


      btw, mit antivir hab ich versucht, macht keinen unterschied ob an oder aus.
      Verwunderlich, da man von einem Virenscanner schon erwarten würde, dass er die Dateien auch scannt. Kann ich aber nix gross dazu sagen, da ich nicht unter Windows arbeite und auch keinen Virenscanner habe.

      Gruss,
      Alex
    • Quietdeath
      Quietdeath
      Einsteiger
      Dabei seit: 09.08.2006 Beiträge: 51
      ich hab eine Frage:
      Wie kann ich meine Datenbanken auf eine andere Partition schieben?
      edit: Ich könnte natürlich ein Backup von den Datenbanken machen und postgresql neu installieren, aber die Lösung ziehe ich dann erst später in Betracht ;)

      Danke im Voraus
      mfg Q.D.
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Quietdeath
      ich hab eine Frage:
      Wie kann ich meine Datenbanken auf eine andere Partition schieben?
      edit: Ich könnte natürlich ein Backup von den Datenbanken machen und postgresql neu installieren, aber die Lösung ziehe ich dann erst später in Betracht ;)

      Danke im Voraus
      mfg Q.D.
      PostgreSQL Datenbanken verschieben?
    • Quietdeath
      Quietdeath
      Einsteiger
      Dabei seit: 09.08.2006 Beiträge: 51
      ah Danke =)
    • mausgambler
      mausgambler
      Bronze
      Dabei seit: 02.04.2005 Beiträge: 493
      Hallo !
      Ich möchte nicht wegen meiner Frage einen eigenen Tread aufmachen, und da es hier anscheinend ein paar Experten gibt:

      Wie kann ich den Namen der Datenbanken ändern ?
      Beispiel:
      Ich öffne Pokertracker und gehe auf Punkt "Maintain Database Names
      Nun steht in der linken Spalte z.b. Pokerdatenbank 2-4 (diesen Namen habe ich vergeben) aber auf der rechten Spalte PTPGSQL7
      oder:
      links:P okerdatenbank 5-10; rechts:jun_06___5_10 (war eine runtergeladenen Datenbank, die ich eingebunden habe)
      Nun muß ich immer wenn ich eine Datenbank einbinde (z.b. in den GLH) den rechten Namen angeben, der aber nicht sehr aussagekräftig ist

      Wie kann ich diesen ändern ?
      Bitte wenn möglich in Einzellschritten, da ich mich mit PostgreSQL nicht auskenne

      Danke !
    • onkelmeik
      onkelmeik
      Bronze
      Dabei seit: 10.02.2006 Beiträge: 651
      Original von mausgambler
      Hallo !
      Ich möchte nicht wegen meiner Frage einen eigenen Tread aufmachen, und da es hier anscheinend ein paar Experten gibt:

      Wie kann ich den Namen der Datenbanken ändern ?
      Beispiel:
      Ich öffne Pokertracker und gehe auf Punkt "Maintain Database Names
      Nun steht in der linken Spalte z.b. Pokerdatenbank 2-4 (diesen Namen habe ich vergeben) aber auf der rechten Spalte PTPGSQL7
      oder:
      links:P okerdatenbank 5-10; rechts:jun_06___5_10 (war eine runtergeladenen Datenbank, die ich eingebunden habe)
      Nun muß ich immer wenn ich eine Datenbank einbinde (z.b. in den GLH) den rechten Namen angeben, der aber nicht sehr aussagekräftig ist

      Wie kann ich diesen ändern ?
      Bitte wenn möglich in Einzellschritten, da ich mich mit PostgreSQL nicht auskenne

      Danke !
      So in etwa ...?!
      Datenbank importieren, aber "Database already exists"
    • mausgambler
      mausgambler
      Bronze
      Dabei seit: 02.04.2005 Beiträge: 493
      Danke, genau das was ich gesucht habe :P
    • Tekras
      Tekras
      Black
      Dabei seit: 03.02.2006 Beiträge: 2.789
      hm temar bei allen varuablen außer shared buffer (der bei mir bei 1000 stand und du empgehlst 20000 ;) ) steht bei mir ein # vor der Zeile, das heisst doch das die variabke gar nicht aktiv ist, richtig? sollte ich die also erstmal aktivieren oder was hat das auf sich?

      das nächste ist: wie bekomme ich die postgres anwendugen vernünftig beendet bzw nach dem beenden wieder gestartet? hab leider überhaupt kein plan von datenbanken ^^
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Tekras
      hm temar bei allen varuablen außer shared buffer (der bei mir bei 1000 stand und du empgehlst 20000 ;) ) steht bei mir ein # vor der Zeile, das heisst doch das die variabke gar nicht aktiv ist, richtig? sollte ich die also erstmal aktivieren oder was hat das auf sich?
      Ganz genau, die Einträge sind standardmässig mit '#' auskommentiert und mit den Voreinstellungen belegt. Bei dir also 1000 shared memory segments - also ungefähr 8 MB Speicher. Das ist natürlich für eine Datenbank mit mehreren hundert MB ein Witz. Legst du den Wert auf 20000, dann belegt Postgres ca. 160 MB Speicher für den Cache. Wenn du genug Hauptspeicher hast, dann kannst du das ganze auch noch höher schrauben. Ich würde aber erstmal mit einem Wert von max. 20000 testen. Die Datenbank braucht ja noch für andere Dinge Speicher.

      Bedenke aber, dass viele Betriebssystem in der Standardeinstellung keine so grossen shared memory Bereiche erlauben. Es kann also sein, dass die Datenbank nicht mehr startet. In diesem Fall muss man erstmal schauen, wie man Windows klar macht, dass solche grossen shared memory Blöcke OK sind. Dafür gibt's bestimmt irgendwo ne Registry Einstellung. Wenn die DB nicht mehr startet, dann halbiere den Wert so lange, bis sie wieder läuft. Wir müssen dann erstmal schauen, wie wir dein Windows umkonfigurieren können.


      das nächste ist: wie bekomme ich die postgres anwendugen vernünftig beendet bzw nach dem beenden wieder gestartet? hab leider überhaupt kein plan von datenbanken ^^
      Systemsteuerung->Verwaltung->Dienste->Postgres

      Und dort dann auf "Beenden" klicken.

      Gruss,
      Alex
    • Tekras
      Tekras
      Black
      Dabei seit: 03.02.2006 Beiträge: 2.789
      ne das hat alles hingehauenm hab immerhin 2gb, das sollte reichen,

      leider gibt es keinerlei besserung, er importiert die HandHistorys, nachdem er die 300 Hände eingelesen hat gibts dieses riesiege loch, er sucht da irgendwie die player statistiken, aber so wie es auschaut macht er einfach gar nix, die festplatte arbeitet nicht und auch sonst ist von aktivität des rechners nichts zu spüren, nach 90sek geht es dann flott weiter und der import ist nach ein paar sekunden abgeschlossen... das komische ist, das dieses phänomen erst aufgtereten ist, als ich meinen rechner neu aufgesetzt hatte und meine datenbank als backup aufgespielte, seitdem gibt es solche endlosen verzögerungen beim import... ich glaube ich exportiere mal sämtliche Hand Files und erstelle eine komplett neue POstgre Datenbank. ist zwar ne menge arbeit aber ich will wissen ob es dann wieder genauso ist oder ob es eine besserung gibt, der momentane zusatand ist einfach nicht akzeptabel
    • netsrak
      netsrak
      Gold
      Dabei seit: 11.03.2006 Beiträge: 36.835
      Bei Pokertracker gibt es einen Patch auf 2.14f, der einige der Performance Probleme speziell beim Import beheben soll.
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Tekras
      die festplatte arbeitet nicht und auch sonst ist von aktivität des rechners nichts zu spüren, nach 90sek geht es dann flott weiter und der import ist nach ein paar sekunden abgeschlossen...
      Das klingt definitiv nach einem PokerTracker Problem. Wenn es an der DB liegen würde, dann müsste er entweder wie wild auf der Platte rumwerkeln (=importieren von daten) oder aber 100% CPU Leistung beanspruchen (=aufbauen der Indexe).
    • Tekras
      Tekras
      Black
      Dabei seit: 03.02.2006 Beiträge: 2.789
      jo das glaube ich mittlerweile auch, hab auch schon ins PT-Forum gepostet, mal sehen was der dazu sagt
    • Oekonom
      Oekonom
      Bronze
      Dabei seit: 02.05.2006 Beiträge: 592
      hmm...

      also ich weiss so langsam auch nicht mehr weiter.

      ich hab meine datenbanken auf 2 serial ATA II platten im RAID 0 verbund.
      dazu noch 2gb ram.

      hab auch die datei entsprechend den anweisungen getuned.
      weiterhin hab ich die ganzen datenbanken geclustered.

      es kann doch nicht wahr sein, dass ich bei meiner datenbank von 1.5 Mio hands für läppische 6.000 neue über eine stunde brauche???

      früher ging sowas ratz fatz :(

      weiss nicht noch irgendjemand irgendwas, um das zu beschleunigen ?(
    • Temar
      Temar
      Bronze
      Dabei seit: 14.07.2006 Beiträge: 536
      Original von Oekonom
      es kann doch nicht wahr sein, dass ich bei meiner datenbank von 1.5 Mio hands für läppische 6.000 neue über eine stunde brauche???
      Doch, das liegt aber nicht an der Datenbank - das ist das dämliche PT. Wenn man sich mal die SQL-Anfragen anschaut, die PT da macht, dann sieht man mehrere hirnlose Sachen wie z.B. das hier:


      SELECT players.screen_name,
      players.location,
      0 as handle,
      players.treeview_icon,
      players.player_id,
      players.main_site_id,
      players.site_id,
      players.alias_id,
      players.hide_ind,
      players.ring_player,
      players.tourney_player,
      upper(players.screen_name) as upper_name
      FROM players
      WHERE ( players.main_site_id = 3 ) OR
      ( players.player_id = 0 );
      Hier werden erstmal alle (!) bekannte Spieler von PartyPoker geladen, obwohl vielleicht gerade einmal 20 in der HandHistory vorkommen. PT sucht sich dann aus den tausenden von Treffern die richtigen Spieler raus, anstatt das gleich von der Datenbank erledigen zu lassen. Das dauert natürlich alles eine weile. Man muss dabei bedenken, dass die Strukturen zur PT internen Verwaltung der Spielerdaten auch erst einmal im Speicher aufgebaut werden müssen. Das dauert natürlich alles ewig. Wie schnell es gehen könnte sieht man ja an einer fast leeren Datenbank. Das ist einfach miserable Programmierung und solche Beispiele wie oben findet man haufenweise.

      Gruss,
      Alex
    • 1
    • 2