Seite 1 von 1
python PostgreSQL & Windows
Verfasst: Montag 27. Juni 2011, 21:08
von 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
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 07:18
von 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?
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 08:00
von Achimt
frabron hat geschrieben:Firewall gecheckt?
Der selbe User kommt zu anderen Databases ebenfalls rein, dürfte also nicht an der Firewall liegen.
frabron hat geschrieben: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
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 08:17
von 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
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.
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 09:35
von Achimt
frabron hat geschrieben: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
frabron hat geschrieben:Na, Kommandozeile auf
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
frabron hat geschrieben: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
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 09:48
von 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 ...
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 12:01
von 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
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 12:23
von 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?
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 12:54
von 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?
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 13:45
von 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
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 14:02
von 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 ...
Re: python PostgreSQL & Windows
Verfasst: Dienstag 28. Juni 2011, 18:27
von noisefloor
Hallo,
wie wäre es denn, von SQLAlchemy den Connection-Pool verwalten zu lassen?
Gruß, noisefloor
Re: python PostgreSQL & Windows
Verfasst: Mittwoch 29. Juni 2011, 06:55
von 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 ...
Re: python PostgreSQL & Windows
Verfasst: Mittwoch 29. Juni 2011, 08:39
von deets
noisefloor hat geschrieben: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.