python PostgreSQL & Windows

[Achimt]

Hallo allerseits,

ich versuche grad von sqlite3 auf PostGreSQL (Version 9.0) für Windows7 umzusteigen.
Unter python (Version 2.6) nutze ich pg8000.dbapi.

In PostGreSQL ist ja nur der Host nutzbar, bei der Herstellung der Verbindung in der Form

Code: Alles auswählen

conn = pg8000.dbapi.connect(host="localhost", user="Beispiel", \
                password="12345", database="Name)

bekomme aber bei einer Database immer folgende Fehlermeldung:

InterfaceError: ('communication error', error(10061, 'Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte'))

Hat jemand eine Idee? Interessanterweise werden alle anderen Databasen, die ich abfragen/verändern verbunden.

PS: user, password ist identisch zu den anderen Database / der name der Database ist korrekt (Vergleich mit pgAdminIII)

PPS: Ggf. liegts auch an Threads (bei vielen gleichzeitige Anfragen)?
scheint mir eher ein Windows-Fehler zu sein

[frabron]

Firewall gecheckt? Stimmt deine pg_hba.conf? Darf der Benutzer sich mit der DB verbinden? Kannst du dich mit anderen Clients (pgsql) mit dem User und Password auf der DB verbinden? Und warum benutzt du nicht psycopg2?

[Achimt]

Firewall gecheckt?

Der selbe User kommt zu anderen Databases ebenfalls rein, dürfte also nicht an der Firewall liegen.

Stimmt deine pg_hba.conf?

Was kann falsch sein? Ich hab max_connections = 100 in der postgrsql.conf ausgeschaltet (vllt. hätte es ja daran liegen, sind bestimmt mehr als 100 Threads...)
in der pg_hba.conf steht nur das drin

Code: Alles auswählen

# TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

Darf der Benutzer sich mit der DB verbinden?

Jap. s.o. Den Benutzer hab ich zum Eigentümer der DB gemacht.

Kannst du dich mit anderen Clients (pgsql) mit dem User und Password auf der DB verbinden?

da fehlt mir die Idee, wie ich das testen soll

Und warum benutzt du nicht psycopg2?

[/quote]
ist das besser / einfacher? Hatte mir die Liste http://www.python-forum.de/viewtopic.php?f=23&t=6848 angeschaut und da gefunden, dass pg8000 eine reine python-Schnittstelle ist und hab einfach die genommen...
Versteife mich aber nicht drauf

[frabron]

Das auskommentieren von max_connections macht afaik keinen Unterschied, da 100 der Default ist. Wenn du viele Verbindungen zur DB hast, kann es allerdings sein, dass der Wert zu niedrig ist und du ihn evt. erhöhen musst. Beachte aber, dass jede Verbindung zur DB Speicher vom shared_memory abknapst, so dass du den auch erhöhen musst.

da fehlt mir die Idee, wie ich das testen soll

Na, Kommandozeile auf

Code: Alles auswählen

psql -U $user -h localhost -d $datenbank --password

und sehen, ob du dich verbinden kannst. Wenn das geht, weisst du, dass es wohl nicht an Windows oder den Berechtigungen zum Zugriff auf die DB liegt, sondern an etwas anderem. Da könnte man ja auch mal die Anzahl der Threads auf 25 oder so verringern um zu sehen, ob du ins max_connections - Limit läufst. Ansonsten sind die ganzen pg_stat_* Funktionen hilfreich zur Analyse des Problems auf der Datenbankseite.

psycopg2 ist der quasi-Standard zur Kommunikation mit Postgresql unter Python. Wenn du keinen anderen Grund hast, das pg8000 zu nehmen, würde ich wohl wechseln.

[Achimt]

Das auskommentieren von max_connections macht afaik keinen Unterschied, da 100 der Default ist. Wenn du viele Verbindungen zur DB hast, kann es allerdings sein, dass der Wert zu niedrig ist und du ihn evt. erhöhen musst. Beachte aber, dass jede Verbindung zur DB Speicher vom shared_memory abknapst, so dass du den auch erhöhen musst.

ich hab deutlich mehr als 100 Threads die ggf. "zeitgleich" versuchen zuzugreifen

Na, Kommandozeile auf

Code: Alles auswählen

psql -U $user -h localhost -d $datenbank --password

und sehen, ob du dich verbinden kannst. Wenn das geht, weisst du, dass es wohl nicht an Windows oder den Berechtigungen zum Zugriff auf die DB liegt, sondern an etwas anderem. Da könnte man ja auch mal die Anzahl der Threads auf 25 oder so verringern um zu sehen, ob du ins max_connections - Limit läufst. Ansonsten sind die ganzen pg_stat_* Funktionen hilfreich zur Analyse des Problems auf der Datenbankseite.

mmh, da scheints zu hapern, egal mit welchem Benutzer ich es versuche immer schlägt die Passwort-Authentifizierung fehl

psycopg2 ist der quasi-Standard zur Kommunikation mit Postgresql unter Python. Wenn du keinen anderen Grund hast, das pg8000 zu nehmen, würde ich wohl wechseln.

ich werde es vsl. tun

Danke erstmal

[frabron]

mmh, da scheints zu hapern, egal mit welchem Benutzer ich es versuche immer schlägt die Passwort-Authentifizierung fehl

Hast du connect/usage Rechte? Das sieht man im create-Statement der Datenbank im PgAdmin ganz gut ...

[Achimt]

Fehler gefunden: es liegt eindeutig an den Threads. Ab ca. 190 / 200 laufenden Threads kommt die o.g. Fehlermeldung. Muss mir da was einfallen lassen, die sinnvoll zu reduzieren.

Irgendwie läuft aber alles viel langsamer ab als ich es von SQLite3 gewöhnt bin.

Danke an frabron

[deets]

Ich finde so eine Menge an connections eh fragwuerdig. Kannst du das nicht poolen? Die Datenbank kann ja nun auch nur soviel gleichzeitig machen - es bringt also auch nicht wirklich was, ihr unbegrenzt connections zuzumuten.

Waeren nicht ein producer/consumer ansatz da sinnvoller?

[frabron]

Postgresql-seitig gibt es pgpool-II als Connection-Pool Lösung. K.A. allerdings, ob's das auch für Windows gibt. Generell kann ich aus meiner Praxis sagen, dass Postgresql auf Windows schlechter performt als auf unixoiden Betriebssystemen, was bei der Menge an Verbindungen aber wohl eher nicht so wichtig ist.
Ich nehme an, über Threads hinweg kann man keine gemeinsame connection nutzen, oder?

[Achimt]

Ich nehme an, über Threads hinweg kann man keine gemeinsame connection nutzen, oder?

nein, das funzt nicht

und ich hab festgestellt, das alleine das Connecten zwischen 12 und 60s (dann gibts den timeout-Fehler) dauert.
Die eigentlichen SELCET/UPDATE-Anfragen gingen dann recht zügig.

Ich nehme an, dass der Host jede connect-Anfrage eines Users (in meinem Fall fragen alle Threads mit dem selben User an) blockt, bis die vorherige geschlossen wurde

[frabron]

Ab einem gewissen, vom Rechner abhängigen Level, ist das Erstellen von neuen connections ziemlich kostspielig für den Datenbankcluster. Du kannst noch shared_memory erhöhen und schauen, ob das was bringt. Das geht auch on-the-fly in der konsole ...

[noisefloor]

Hallo,

wie wäre es denn, von SQLAlchemy den Connection-Pool verwalten zu lassen?

Gruß, noisefloor

[frabron]

Das hatte ich mich auch schon gefragt, ob das eine Möglichkeit ist. Dazu kenne ich mich leider nicht genug mit Threads und den Implikationen aus, die da auftreten können. Deshalb hatte ich da nix erwähnt ...

[deets]

Hallo,

wie wäre es denn, von SQLAlchemy den Connection-Pool verwalten zu lassen?

Gruß, noisefloor

Das ist auch keine Magie. Das Problem ist ja nicht die Wiederverwendung einer connection, sondern schon der Aufbau von ausreichend vielen - da kann SA auch nicht zaubern.

Entweder der OP bekommt die Datenbank so getunt, dass sie das problemlos mitmacht. Oder aber er aendert seinen Programmaufbau, und verwendet einen thread-pool mit workern drin, die dann die Aufgaben abarbeiten. Dann kann er davon so viele machen, wie die Datenbank sinnvoll hergibt.