Welche Version?
Auf https://projects.commandprompt.com/p...hangeset/12608 finde ich einen Patch für 7.1 zu diesem Problem, ist Deine Version so alt?
Andreas
Hallo zusammen.
Ich hoffe ich bin hier in der richtigen Rubrik gelandet.
Ich habe ein riesiges sqlfile (4,5 GB) das per psql von der Konsole eingelesen werden muss.
Nach 10 minuten kommt dannPHP-Code:psql -h HOST -p PORT -U USER -q -o /dev/null -f file.sql 2>&1
Ich habe noch keine große Erfahrung mit postgres aber vielleicht ist es wichtig zu wissen das das ganze file eine Transaction ist. Im file.sql sind auch keine "plain" SQL Befehle wie z.B. INSERT, UPDATE, DELETE sondern alles aufrufe von pl/pgsql funktionen. Z.B. select * from insertNewUa(...)PHP-Code:psql:file.sql:11563401: cannot allocate memory for output buffer
Kleinere file.sql (20 - 50 MB) funktionieren bestens
Meine Frage lautet nun
- Was will mir psql mit dieser Fehlermeldung sagen ?
- Wie löse ich das Problem
Vielen Dank schonmal im voraus
Sigh
Welche Version?
Auf https://projects.commandprompt.com/p...hangeset/12608 finde ich einen Patch für 7.1 zu diesem Problem, ist Deine Version so alt?
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Vielleicht wäre es auch praktisch STDERR nicht unbedingt Richtung /dev/null zu schicken.
Wie sieht die Speicherkonfiguration deiner Datenbank aus?
Welche PostgreSQL Version ist das?
Was für Hardware ist das?
Ist das ein Backup, das zurückgespielt werden soll?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
der fehler passiert auf dem client -> psql -> pqlib
PostgreSQL Source Code: src/interfaces/libpq/fe-misc.c Source File
bei der zeile 11563401 deines file.sql ..
bei 2 gig address-raum für 32 bit prozesse darf man von durchschnittlicher zeilenbreite ca. 172 zeichen ausgehen .. was mir realistisch bei deinem fall erscheint ..
soweit ich das im quellcode erkennen konnte tritt der fehler in
diese funktion vergroessert den ausgabe-puffer fuer die connection - wenn daten/aufrufe ans backend gesendet werden.Code:00295 pqCheckOutBufferSpace(size_t bytes_needed, PGconn *conn)
wenn psql -f das gesamte script-file als ganzes an das backend sendet wuerde dies u.U. erklaeren,
warum das nen out-of-memory produziert. ich habe zwar gesehen, dass der code der wenigen aufrufer
dieser fkt. zwischendurch ein flush(..) vorsieht (also speicher bereits gesendeter daten freigeben) da stand aber ein "try" dabei ..
dann wäre also interessant ob es
1. ueberhaupt ein limit fuer die groesse von script-files gibt
2. unter welchen bedingungen es ein limit gibt
aus der doku habe ich leider nichts erfahren koennen
Geändert von symbiont (20.11.2008 um 09:53 Uhr)
Postgres Version: 8.3.3
System: Debian Etch
Hardware: Neue aber nix Spezielles
Es ist kein Backup das zurück gespielt werden soll. Es werden tägl. Daten erhoben und verarbeitet. Daraus resultiert dann so ein file.sql das dann eingespielt werden soll.
Memory Settings
shared_buffers = 57MB
work_mem = 512MB
maintenance_work_mem = 1024MB
max_stack_depth = 7MB
max_fsm_pages = 204800
effective_cache_size = 2048MB
Antworten auf Symbionts Fragen klingen so als ob Sie auch eine Antwort auf mein Problem wären![]()
nein - keine direkten antworten - aber vielleicht hinweise um eine antwort zu finden ..
ich wuerde mich auf den client konzentrieren .. der fehler tritt nicht im backend auf und hat auch nichts mit evtl. limits des backends zu tun ..
ich habe mal versucht in die richtung "grosse scripte" zu recherchieren .. da find ich aber nix gescheites ..
empfehlen wuerde ich einen alternativen weg zu erdenken wie du die "täglichen" daten in die pg db nudelst ...
am einfachsten waere es wohl das script zu splitten - ginge das? - oder muss das script zwingend in einer transaktion zum server flutschen .. das waere schon eine heftige aktion
deine backend memory einstellungen sehen irgendwie ziemlich zerfrickelt aus .. hast daran rumgespielt? (hat aber eher unwahrscheinlich mit dem problem zu tun)
[EDIT] Nachtrag ..
selbst wenn psql das script "kommandoweise" an das backend sendet, kann das ersehnte "flush" welches den speicher fuer den ausgabe-puffer freigibt - erst irgendwann "zum schluss" zum tragen kommen. interessant wäre, ob das ganze auf einem anderen OS (windows *g*) - weil anderes compilat - andere systemfunktionen - etc.) funktioniert. hast du schonmal versucht das auf einem anderen OS ablaufen zu lassen?
Geändert von symbiont (20.11.2008 um 10:20 Uhr)
Nein kein anderes OS versucht.
client hat btw auch Debian etch.
Ich bin nun auch als workaround zum Thema splitten gekommen. Ab welcher Größe (in byte) es kracht versuche ich mit "try and error" heraus zu finden.
und ja an den memory limits habe ich herumgefrickelt.
das system wird kein riesiges multiusersystem sein sondern man hat wenige user (connections) die dann jeweils schnelle Antwort über große mengen an Daten bekommen sollen. Nachdem ich dutzende von Optimierungstutorials gelesen habe (und ausprobiert) waren diese Settings bisher die besten.
abfragen die mit den standard settings 14 mins dauerten gehen nun in 10 sec.
falls es da aber grobe Schnitzer geben solle bin ich für anmerkungen immer offen (auch wenn das off topic wäre )
also wie ich schon schrieb - der fehler riecht nach ner kollision an der 2 GB grenze fuer 32 bit Prozesse - ich muss zugeben, das ich nicht hunderprozentig weiss, ob diese auch fuer debian OS gilt.
wenn du da experimentieren willst - versuch dich mal daran zu orientieren ..
d.h. aber nicht, dass ein 2 GB script file "genau" 2 GB Speicher fuer den Puffer beansprucht .. die funktion allociert ja auch Speicher fuer notwendigen Overhead des PG protokolls zum Backend ..
Wenn es nun aber tatsaechlich "daran" liegt, solltest du mit splitten auf 1GB "auf der sicheren Seite sein" ...
*gotcha*
hast mich erwischt.
habe das file.sql in 10.000.000 Zeilen zerlegen lassen und siehe da ^^
1 file ist ~ 2,2 GB
teste das einfach mal ansonsten splitte ich halt bei 5.000.000 Zeilen
gebe Feedback ob das 2,2GB durchläuft
Warum ich das eigentlich vermeiden wollte ist das ich eine extra tabelle habe, in der jedes file.sql quasi nen eintrag mit einer id (datum etc.) bekommt. diese tabelle wächst dann nichtmehr um 1 pro tag Sondern um ~ 10 pro tag (split halt)
aber das wird mich und meine datenbank sicher nicht umbringen![]()
ach - grau ist alle theorie ..
es koennte durchaus interessant sein, das psql mal auf einem anderen OS mit so grossen dateien laufen zu lassen ..
vielleicht gibt es auch eine 64 bit version vom client ? vielleicht ginge das dann auch ..
das sind nur so ideen - die man verfolgen koennte - wenn du schonmal beim experimentieren bist *g*
Geändert von symbiont (20.11.2008 um 11:04 Uhr)
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen