Hallo mein HM ist seit heute Nachmitag total langsam und benötigt zum einlesen von Händen endlos lange woran kann das liegen.
Ralf
Benachrichtigungen
Alles löschen
Hold'em und Omaha Manager
33
Beiträge
12
Benutzer
0
Reactions
2,425
Ansichten
32 Antworten
Das Prob kenn ich nicht. Hast du mal deine Systemprozesse gecheckt? Vielleicht ist die Auslastung irgendwo sehr hoch und bremst das Prog aus.
Die Postgress.Exe zieht ca 80% weiß nur nicht warum.
Habe ca. 3.500.000 Mio Hände in meiner DB kann es daran liegen das die DB zu voll ist.
Ralf
Original von otto0815
Die Postgress.Exe zieht ca 80% weiß nur nicht warum.Habe ca. 3.500.000 Mio Hände in meiner DB kann es daran liegen das die DB zu voll ist.
Ralf
An den 3,5 Mio.liegt es wahrscheinlich nicht.Ich habe ca.16Mio Hände drin und wenn ich geminte Hände einlesen lasse habe ich jetzt noch ca.18H./s.
Wenn ich spiele und meine Auto Import Hände eingelesen werden haben sie auch bloß 0,5/s-2,0/s.Meinst du beim Auto Import?
Die Datenbank wird wohl (noch)nicht Vakuumiert wie bei PT.HM sagt zwar das die Geschwindigkeit bei zunehmender Größe nicht abnimmt aber andere Nutzer sagen auch das die Geschw.langsamer wird.
Ja ist beim Auto Import da zieht die Postgres.exe bis zu 98% da wird das System so langsam das ich bei den Tischen ausblinde weil ich einfach nicht schnell genug reagieren kann.
So ist ein Spielen in keinem Fall möglich.
Schau doch mal bei dir ob deine Postgress beim Einlesen auch stärker beansprucht wird.
Ralf
Original von otto0815
Die Postgress.Exe zieht ca 80% weiß nur nicht warum.Habe ca. 3.500.000 Mio Hände in meiner DB kann es daran liegen das die DB zu voll ist.
Ralf
naja.. bei 3.500.000 Mio Händen wird wohl jede software langam ^^. sorry, aber der musste sein
eigentlich wurde gerade das ausgeprägte langsamer Werden auch bei großen Datenbanken (auch auf alten Rechnern) oft verneint und deshalb wird wohl auch nicht viel daran gearbeitet mit mehreren Datenbanken gleichzeitig umgehen zu können.
Das was ich bisher von Datenbanken konvertiert habe sind ca 10 Millionen Hände. Mittlerweile bekomme ich selbst mit nem RAID-0 System (mit nem 3,3GHz Dual-Core) unter XP kaum noch über 10H/s (unter Vista sogar tendenziell noch weniger) und die Geschwindigkeit beim Filtern, also dem Arbeiten innerhalb der Datenbank ist auch nicht mehr schneller als beim PT. Der einzige Vorteil der momentan für mich bleibt sind die zusätzlichen Stats.
Hinzu kommen dann noch so Spielchen, dass der kaum exportierte PT-Hände von Titan annimmt oder ich beim Scannen mit SpadeEye den AutoImport erstmal stoppen darf, da SpadeEye sonst anscheinend igrendwie nicht die Datenbank abfragen darf.
HM mag ja ganz toll sein, aber das ewige Lobpreisen der Geschwindigkeit kann ich nicht mehr nachvollziehen.
Edit: sorry, fürs Abschweifen. Bin wegen dem Ding nur langsam etwas genervt
Original von xyxelxs2
eigentlich wurde gerade das ausgeprägte langsamer Werden auch bei großen Datenbanken (auch auf alten Rechnern) oft verneint und deshalb wird wohl auch nicht viel daran gearbeitet mit mehreren Datenbanken gleichzeitig umgehen zu können.
Das was ich bisher von Datenbanken konvertiert habe sind ca 10 Millionen Hände. Mittlerweile bekomme ich selbst mit nem RAID-0 System (mit nem 3,3GHz Dual-Core) unter XP kaum noch über 10H/s (unter Vista sogar tendenziell noch weniger) und die Geschwindigkeit beim Filtern, also dem Arbeiten innerhalb der Datenbank ist auch nicht mehr schneller als beim PT. Der einzige Vorteil der momentan für mich bleibt sind die zusätzlichen Stats.
Hinzu kommen dann noch so Spielchen, dass der kaum exportierte PT-Hände von Titan annimmt oder ich beim Scannen mit SpadeEye den AutoImport erstmal stoppen darf, da SpadeEye sonst anscheinend igrendwie nicht die Datenbank abfragen darf.HM mag ja ganz toll sein, aber das ewige Lobpreisen der Geschwindigkeit kann ich nicht mehr nachvollziehen.
Edit: sorry, fürs Abschweifen. Bin wegen dem Ding nur langsam etwas genervt
kann ich alles nur bestätigen 
Was kann man machen? Bin auch nich mehr so begeistert, wie zu anfang 
Original von contfold
Original von xyxelxs2
eigentlich wurde gerade das ausgeprägte langsamer Werden auch bei großen Datenbanken (auch auf alten Rechnern) oft verneint und deshalb wird wohl auch nicht viel daran gearbeitet mit mehreren Datenbanken gleichzeitig umgehen zu können.
Das was ich bisher von Datenbanken konvertiert habe sind ca 10 Millionen Hände. Mittlerweile bekomme ich selbst mit nem RAID-0 System (mit nem 3,3GHz Dual-Core) unter XP kaum noch über 10H/s (unter Vista sogar tendenziell noch weniger) und die Geschwindigkeit beim Filtern, also dem Arbeiten innerhalb der Datenbank ist auch nicht mehr schneller als beim PT. Der einzige Vorteil der momentan für mich bleibt sind die zusätzlichen Stats.
Hinzu kommen dann noch so Spielchen, dass der kaum exportierte PT-Hände von Titan annimmt oder ich beim Scannen mit SpadeEye den AutoImport erstmal stoppen darf, da SpadeEye sonst anscheinend igrendwie nicht die Datenbank abfragen darf.HM mag ja ganz toll sein, aber das ewige Lobpreisen der Geschwindigkeit kann ich nicht mehr nachvollziehen.
Edit: sorry, fürs Abschweifen. Bin wegen dem Ding nur langsam etwas genervt
kann ich alles nur bestätigen
Habt ihr schon 'mal versucht, euer PostgreSQL-Setup in der postgres.conf zu optimieren (Default-Einstellungen sind für Web-Server mit relativ vielen Connections und kurzen Queries und nicht für DW-like Applikationen mit Bulk-Loads) bzw. das Verzeichnis pg_xlog auf eine andere physische Platte zu legen?
HTH
Btw, mein Performanceabfall beim Laden im Vergleich zu einer fast leeren Datenbank liegt bei knapp unter 30% - derzeit 60 Hände/s bei +6,5 Mio Hände ...
Original von AKDJ10
Original von contfold
Original von xyxelxs2
eigentlich wurde gerade das ausgeprägte langsamer Werden auch bei großen Datenbanken (auch auf alten Rechnern) oft verneint und deshalb wird wohl auch nicht viel daran gearbeitet mit mehreren Datenbanken gleichzeitig umgehen zu können.
Das was ich bisher von Datenbanken konvertiert habe sind ca 10 Millionen Hände. Mittlerweile bekomme ich selbst mit nem RAID-0 System (mit nem 3,3GHz Dual-Core) unter XP kaum noch über 10H/s (unter Vista sogar tendenziell noch weniger) und die Geschwindigkeit beim Filtern, also dem Arbeiten innerhalb der Datenbank ist auch nicht mehr schneller als beim PT. Der einzige Vorteil der momentan für mich bleibt sind die zusätzlichen Stats.
Hinzu kommen dann noch so Spielchen, dass der kaum exportierte PT-Hände von Titan annimmt oder ich beim Scannen mit SpadeEye den AutoImport erstmal stoppen darf, da SpadeEye sonst anscheinend igrendwie nicht die Datenbank abfragen darf.HM mag ja ganz toll sein, aber das ewige Lobpreisen der Geschwindigkeit kann ich nicht mehr nachvollziehen.
Edit: sorry, fürs Abschweifen. Bin wegen dem Ding nur langsam etwas genervt
kann ich alles nur bestätigen
Habt ihr schon 'mal versucht, euer PostgreSQL-Setup in der postgres.conf zu optimieren (Default-Einstellungen sind für Web-Server mit relativ vielen Connections und kurzen Queries und nicht für DW-like Applikationen mit Bulk-Loads) bzw. das Verzeichnis pg_xlog auf eine andere physische Platte zu legen?
HTH
Was kann man denn da noch optimieren ohne was kaputt zu machen? Gibts da irgendwelche normalverständliche Guides?
Ich mache fast täglich 'n Vacuum bzw. lasse für eine noch bestehende PT2-Datenbank (da der HM derzeit auf Ongame noch für die Tonne ist) das PT-Defrag-Script hier aus dem Forum laufen. Nach Vacuum bzw. Script läuft dann noch ein Defragmentationsprogramm über die PostgreSQL-Partition. Danach gehts dann meisst noch für einige Zeit mit der Geschwindigkeit.
Das ganze würde sich erübrigen wenn mehrere Datenbanken unterstützt werden würden oder endlich alte Hände gepurged werden könnten.
Klare aussagen, ob man nun mit bestehenden Datenbanken gefahrlos zur neuen 8.3er Version (schneller) konvertieren kann gibts sowohl zu PT2 als auch HM nicht.
Ich leih mir dir Tage 'ne Raptor aus und gucke ob vielleicht die dort bessere Random Access Time der Festplatte noch was ausrichten kann. Raptoren oder 15K-SAS-Festplatten (+Einfachst-Controller) sind ja nicht mehr so teuer und mit etwas Bastelei auch leise.
EDIT: sorry, habe deinen Hinweis bezüglich der conf-Datei vor dem Posten nochnicht sehen können. Danke für den Tipp und die Erklärung. Ich schaue mir das mal an 
Original von xyxelxs2
Original von AKDJ10
Original von contfold
Original von xyxelxs2
eigentlich wurde gerade das ausgeprägte langsamer Werden auch bei großen Datenbanken (auch auf alten Rechnern) oft verneint und deshalb wird wohl auch nicht viel daran gearbeitet mit mehreren Datenbanken gleichzeitig umgehen zu können.
Das was ich bisher von Datenbanken konvertiert habe sind ca 10 Millionen Hände. Mittlerweile bekomme ich selbst mit nem RAID-0 System (mit nem 3,3GHz Dual-Core) unter XP kaum noch über 10H/s (unter Vista sogar tendenziell noch weniger) und die Geschwindigkeit beim Filtern, also dem Arbeiten innerhalb der Datenbank ist auch nicht mehr schneller als beim PT. Der einzige Vorteil der momentan für mich bleibt sind die zusätzlichen Stats.
Hinzu kommen dann noch so Spielchen, dass der kaum exportierte PT-Hände von Titan annimmt oder ich beim Scannen mit SpadeEye den AutoImport erstmal stoppen darf, da SpadeEye sonst anscheinend igrendwie nicht die Datenbank abfragen darf.HM mag ja ganz toll sein, aber das ewige Lobpreisen der Geschwindigkeit kann ich nicht mehr nachvollziehen.
Edit: sorry, fürs Abschweifen. Bin wegen dem Ding nur langsam etwas genervt
kann ich alles nur bestätigen
Habt ihr schon 'mal versucht, euer PostgreSQL-Setup in der postgres.conf zu optimieren (Default-Einstellungen sind für Web-Server mit relativ vielen Connections und kurzen Queries und nicht für DW-like Applikationen mit Bulk-Loads) bzw. das Verzeichnis pg_xlog auf eine andere physische Platte zu legen?
HTH
Was kann man denn da noch optimieren ohne was kaputt zu machen? Gibts da irgendwelche normalverständliche Guides?
Ich mache fast täglich 'n Vacuum bzw. lasse für eine noch bestehende PT2-Datenbank (da der HM derzeit auf Ongame noch für die Tonne ist) das PT-Defrag-Script hier aus dem Forum laufen. Nach Vacuum bzw. Script läuft dann noch ein Defragmentationsprogramm über die PostgreSQL-Partition. Danach gehts dann meisst noch für einige Zeit mit der Geschwindigkeit.
Das ganze würde sich erübrigen wenn mehrere Datenbanken unterstützt werden würden oder endlich alte Hände gepurged werden könnten.
Klare aussagen, ob man nun mit bestehenden Datenbanken gefahrlos zur neuen 8.3er Version (schneller) konvertieren kann gibts sowohl zu PT2 als auch HM nicht.
Ich leih mir dir Tage 'ne Raptor aus und gucke ob vielleicht die dort bessere Random Access Time der Festplatte noch was ausrichten kann. Raptoren oder 15K-SAS-Festplatten (+Einfachst-Controller) sind ja nicht mehr so teuer und mit etwas Bastelei auch leise.
Es wäre hilfreich, Postings trotz verständlicher Verärgerung zu lesen und versuchen zu verstehen ...
1. postgres.conf optimieren:
a. max_connections verringern (z.B. 5)
b. shared_buffers erhöhen (1/4 des verfügbaren Hauptspeichers)
c. work_mem auf 2MB erhöhen
d. maintenance_work_mem auf 128MB erhöhen
e. checkpoint_segments erhöhen (z.B. 16)
f. wal_buffers auf 1MB setzen
g. fsync auf off setzen (!!Achtung: nur zu empfehlen, wenn du regelmässig ein Full-Backup machst, denn wenn der Rechner abstürzt, kann die Datenbank defekt werden!!)
h. effective_cache_size erhöhen (2/3 des verfügbaren Hauptspeichers)
2. Wenn eine 2. physische Platte vorhanden ist,
a. PostgreSQL auf der 2. Platte (Nicht-System-Platte) installieren
b. und das Verzeichnis pg_xlog auf die 1. Platte legen.
Für Punkt 2 brauchst du noch ein Programm linkd.exe, das du auf der Microsoft-Homepage (als Teil des Windows Ressource Toolkits) findest. Mit diesem Programm erstellst du in dem Orginalverzeichnis (auf der 2. Platte) einen "logischen Verzeichnis-Link" auf die 1. Platte, wo das Verzeichnis tatsächlich liegt ...
HTH
Original von AKDJ10
Es wäre hilfreich, Postings trotz verständlicher Verärgerung zu lesen und versuchen zu verstehen ...
HTH
Als ich geantwortet habe, stand bei dir lediglich, ob wir unser postgresql-setup optimieren würden. Das was ich diesbezüglich tue und was auch immerwieder dazu gepredigt wird habe ich beschrieben.
b. shared_buffers erhöhen (1/4 des verfügbaren Hauptspeichers)
Tut mir leid, aber ich bin der totale PC noob ist der "verfügbare Hauptspeicher" der "Physikalische Speicher (KB) den man bei strg+alt+entf unter Systemleistung findet?
f. wal_buffers auf 1MB setzen
#wal_buffers = 8 # min 4, 8KB each
das steht bei mir... was muss ich nun anstatt der 8 dort hin schreiben? Ich verzweifel hier langsam bei dem ganzen Kauderwelsh
Wäre es möglich, dass du Deine postgres.conf hochlädst? Das wäre wirklich 1A
;(es is alles so grauenvoll langsam
ich will jetzt schon PT zurück
Selbst wenn ich jetzt die einzelnen Tabs öffnen möchte, muss ich ~40-60sek warten
Original von contfold
b. shared_buffers erhöhen (1/4 des verfügbaren Hauptspeichers)
Tut mir leid, aber ich bin der totale PC noob
Genau. Pyhsikalischer Speicher insgesamt verfügbar.
wenn davon schon ~1/3 im "Gebrauch" ist, wovon muss ich dann 1/4 für shared buffers nehmen? Vom gesamten oder ungebrauchten? Tut mir leid, wenn ich Dich mit solch blöden Fragen nerve
Das Problem ist, dass die Einstellungen extrem rechner- (ausstattungsabhängig) und datenbankspezifisch (größenabhängig) sind, da es Optimierungen sind. Ein geringfügiges Zuviel (bspw. beim effective_cache_size) verlangsamt das System! Daher nicht einfach stur abtippen, sondern entsprechend deiner Situation und meines vorigen Postings anpassen (führendes # löschen und Wert abändern).
(!!) Ohne Gewähr (!!) auszugsweise meine Settings:
max_connections = 5
shared_buffers = 768MB
work_mem = 2MB
maintenance_work_mem = 128MB
wal_buffers = 1MB
effective_cache_size = 2GB
Und (!!) nur (!!) wenn du ein Backup von der Datenbank machst dann auch
fsync = off
Der letzte Parameter kann bewirken, dass deine Datenbank bei einem Systemabsturz oder Datenbankabsturz defekt wird und du alles (das gesamte Datenbankverzeichnis) rücksichern musst oder, wenn du kein Backup hast, die Datenbank neu aufbauen muss!
Nach den Änderungen in der Datei postgres.conf am einfachsten den Rechner neu starten.
Und sichere vorher die Datei postgresql.conf weg, denn wenn es nicht klappt, genügt es die ursprüngliche Datei zurückzusichern und wiederum den Rechner neu zu starten.
Abschließend noch etwas: Alles auf eigene Gefahr!
Original von AKDJ10
Das Problem ist, dass die Einstellungen extrem rechner- (ausstattungsabhängig) und datenbankspezifisch (größenabhängig) sind, da es Optimierungen sind. Ein geringfügiges Zuviel (bspw. beim effective_cache_size) verlangsamt das System! Daher nicht einfach stur abtippen, sondern entsprechend deiner Situation und meines vorigen Postings anpassen (führendes # löschen und Wert abändern).(!!) Ohne Gewähr (!!) auszugsweise meine Settings:
max_connections = 5
shared_buffers = 768MB
work_mem = 2MB
maintenance_work_mem = 128MB
wal_buffers = 1MB
effective_cache_size = 2GB
Und (!!) nur (!!) wenn du ein Backup von der Datenbank machst dann auch
fsync = off
Der letzte Parameter kann bewirken, dass deine Datenbank bei einem Systemabsturz oder Datenbankabsturz defekt wird und du alles (das gesamte Datenbankverzeichnis) rücksichern musst oder, wenn du kein Backup hast, die Datenbank neu aufbauen muss!
Nach den Änderungen in der Datei postgres.conf am einfachsten den Rechner neu starten.
Und sichere vorher die Datei postgresql.conf weg, denn wenn es nicht klappt, genügt es die ursprüngliche Datei zurückzusichern und wiederum den Rechner neu zu starten.
Abschließend noch etwas: Alles auf eigene Gefahr!
Nachtrag: Zusätzliche Anwendungen Poker Clients, HM selbst, SpadeEye, usw. reduzieren deinen verfügbaren Speicher. In diesen Fällen musst du möglicherweise die Werte für shared_buffers, maintenance_work_mem und effective_cache_size kleiner wählen ...
Wieviel kleiner musst du ausprobieren ...