Grosse Files fuer Perl unsichtbar?

Hallo,

ich bearbeite eine große Menge Geodaten (Landkarten) mit perl und kann
daher nicht alles in einem Array oder Hash halten. Darum wird vieles in
temporäre Dateien geschrieben, die dann wiederum z.B. mit system"sort
...." sortiert und dann abgearbeitet werden. Das funktioniert auch
bestens bei kleinen Dateien.

Ab einer bestimmten Größe (also mehr Eingangsdaten, dadurch größere
Tempfiles), werden die Dateien für den Perl-Prozess (und seine system
Aufrufe) "unsichtbar".

Ein "open(...) or die $!" sagt "no such file or directory".
ein system("cp -v $file1 $file2") ebenfalls, wie auch system("cat $file1
> $file2"). Ein system("wc -l $file1") liefert gar nichts usw...

In der Bash (ausserhalb des perl Prozesses) ist die Datei natürlich da.
Kann gelesen, kopiert usw. werden.

Einen falschen Dateinamen oder so benutze ich nicht. Der selbe Code
funktioniert mit weniger Daten. Erst ab einer gewissen Menge (so ca.
1.500.000 Straßen-Kanten) tritt das Problem auf, davor nicht.

Die Datei hat aber "nur" 150 MB. Es dürfte also noch lange keine
Probleme mit dem Filesystem geben. Getestet wurde es auch schon unter
xfs und ext3. Threads oder fork gibt es nicht im Programm.

Auch bei meinem Kollegen am anderen Ende der Republik läuft es
problemlos, sogar mit den großen Daten. Hier allerdings nicht (auf
einigen Rechnern schon getestet).

Den Quellcode kann ich leider nicht mitliefern da der zig Module
umfasst. Die kritische Stelle kann aber auf ein einfaches open oder -e
gekürzt werden, und er findet die Datei nicht, obwohl sie zur selben
Zeit mit ls in der Bash existiert.

Ich suche schon seit Wochen nach einer Lösung, und bin mit meinem Latein
am Ende. Hat irgendjemand eine Idee, an was das liegen könnte?!

Ratlos,
Dennis

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck writes:

>Ein "open(...) or die $!" sagt "no such file or directory".
>ein system("cp -v $file1 $file2") ebenfalls, wie auch system("cat $file1
>> $file2"). Ein system("wc -l $file1") liefert gar nichts usw...

Wenn cp oder wc die Datei nicht lesen koennen, dann ist das
kein perl-Problem. Dein Script wird entweder nicht im richtigen
Directory sein, oder der Dateiname ist falsch. Eventuell hast
du auch Probleme mit UTF8-Dateinamen.

--
--
Michael van Elst
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."

Re: Grosse Files fuer Perl unsichtbar?

Michael van Elst schrieb:
> Dennis Scheck writes:
>> Ein "open(...) or die $!" sagt "no such file or directory".
>> ein system("cp -v $file1 $file2") ebenfalls, wie auch system("cat
>> $file1 >> $file2"). Ein system("wc -l $file1") liefert gar
>> nichts usw...
>
> Wenn cp oder wc die Datei nicht lesen koennen, dann ist das
> kein perl-Problem. Dein Script wird entweder nicht im richtigen
> Directory sein, oder der Dateiname ist falsch. Eventuell hast
> du auch Probleme mit UTF8-Dateinamen.

Hmm, aber das ganze Ding läuft mit kleineren Dateien. Wenn ein logischer
Fehler im Programm wäre (also falsches Verzeichnis oder so), dann ginge
es mit kleineren Dateien ja auch nicht, da die Dateinamen immer gleich
sind und der Ablauf des Programms ja auch. Und Sonderzeichen ist in
umdb2gdf.tmp.l1.edges auch keines (das ist die Datei).

Ratlos,
Dennis

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck wrote:
> Ich suche schon seit Wochen nach einer Lösung, und bin mit meinem
> Latein am Ende. Hat irgendjemand eine Idee, an was das liegen
> könnte?!

Check mal vor einem open etc., ob Du im richtigen Directory stehst.
(via 'use Cwd;' und später '$a = getcwd();' etc.) und ob die ggf.
relativen File-Pathnames dazu passen.

Es könnte auch sein, daß Du in einem Verzeichnis stehst, während es
von außen gelöscht wird. Unter Linux/Unix bleiben Files solange
geöffnet, wie jemand darauf zugreift. Der Name im Dateisystem kann
aber meist unabhängig davon gelöscht werden.

Falls diese Tips nichts helfen, verwende 'strace' unter Linux bzw.
'truss' unter Solaris etc. um die Systemcalls Deines Perl-Programmes
zu verfolgen. Dann solltest Du sehen was versucht wird und welcher
Fehlercode erscheint, z.B.

$ strace perl -e 'if (-f "nonexisting") { print "nix da\n"};'
....
stat64("nonexisting", 0x81410c8) = -1 ENOENT (No such file or
directory)
....

Gruß

Guido

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck wrote:
> Michael van Elst schrieb:

>> Wenn cp oder wc die Datei nicht lesen koennen, dann ist das
>> kein perl-Problem. Dein Script wird entweder nicht im richtigen
>> Directory sein, oder der Dateiname ist falsch. Eventuell hast
>> du auch Probleme mit UTF8-Dateinamen.

> Hmm, aber das ganze Ding läuft mit kleineren Dateien. Wenn ein logischer
> Fehler im Programm wäre (also falsches Verzeichnis oder so), dann ginge
> es mit kleineren Dateien ja auch nicht, da die Dateinamen immer gleich
> sind und der Ablauf des Programms ja auch. Und Sonderzeichen ist in
> umdb2gdf.tmp.l1.edges auch keines (das ist die Datei).

Wenn das nur bei grösseren Dateien nicht funktioniert, wird da
vielleicht eine Race-Condition wirksam. Schau Dir mal genauer an, wie
die Dateien geschrieben und gelesen werden, bzw. was und vor allem wie
da dazwischen an Utilities aufgerufen wird.

Helmut Wollmersdorfer

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck:

> ich bearbeite eine große Menge Geodaten (Landkarten) mit perl und kann
> daher nicht alles in einem Array oder Hash halten. Darum wird vieles in
> temporäre Dateien geschrieben, die dann wiederum z.B. mit system"sort
> ..." sortiert und dann abgearbeitet werden. Das funktioniert auch
> bestens bei kleinen Dateien.
>
> Ab einer bestimmten Größe (also mehr Eingangsdaten, dadurch größere
> Tempfiles), werden die Dateien für den Perl-Prozess (und seine system
> Aufrufe) "unsichtbar".
>
> Ein "open(...) or die $!" sagt "no such file or directory".
> ein system("cp -v $file1 $file2") ebenfalls, wie auch system("cat $file1
> > $file2"). Ein system("wc -l $file1") liefert gar nichts usw...

Letzteres wundert mich - bei mir liefert ein

$file = "nicht_existierende_Datei.dat";
system("wc -l $file");

die Ausgabe:

wc: nicht_existierende_Datei.dat: no such file or directory

zurück. 'wc' liefert _immer_ eine Ausgabe, entweder die gewünschte
Information oder einen Fehler. Da stimmt in deinem Skript sonst irgend
etwas nicht. Du solltest umbedingt den Returnstatus von 'system'
checken. Und was gibt:

system("ls -l $file1");

zurück?

> Die Datei hat aber "nur" 150 MB. Es dürfte also noch lange keine
> Probleme mit dem Filesystem geben. Getestet wurde es auch schon unter
> xfs und ext3. Threads oder fork gibt es nicht im Programm.

Was mir hier noch einfällt (was ich aber aufgrund deiner Beschreibung
nicht annehme) ist die Option USE_LARGE_FILES, die man beim
Kompilieren angeben (und mittels "perl -V" überprüfen) kann. IIRC
muss diese Option gesetzt sein, damit man Dateien > 64 MB lesen
bzw. bearbeiten kann. Aber das ist zumindest bei mir auf allen Systemen,
egal ob Unix oder Windows, der Fall, d.h., die Option wird implizit
gesetzt, wenn das jeweilige File/Betriebssystem solche großen
Dateien unterstützt. Aber du kannst es ja bei dir sicherheitshalber
nachprüfen.

> Und Sonderzeichen ist in
> umdb2gdf.tmp.l1.edges auch keines (das ist die Datei).

Der Name ist nicht besonders glücklich gewählt - ist das am
Ende ein l (kleines "ell", gefolgt von der Ziffer "eins")? Heißt die
Datei immer so? Wo kommt der Name her? Hier kann man
oft über ähnliche, aber falsche Dateinamen stolpern. Und: endet
der Dateiname mit einem "" (was beim Gebrauch von
"system" nicht so ungewöhnlich wäre)? Dann muss du das
"" vor dem Öffnen der Datei erst weg-"chompen".

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Grosse Files fuer Perl unsichtbar?

On 2007-09-03 10:47, Ferry Bolhar wrote:
> Dennis Scheck:
>> Die Datei hat aber "nur" 150 MB. Es dürfte also noch lange keine
>> Probleme mit dem Filesystem geben. Getestet wurde es auch schon unter
>> xfs und ext3. Threads oder fork gibt es nicht im Programm.
>
> Was mir hier noch einfällt (was ich aber aufgrund deiner Beschreibung
> nicht annehme) ist die Option USE_LARGE_FILES, die man beim
> Kompilieren angeben (und mittels "perl -V" überprüfen) kann. IIRC
> muss diese Option gesetzt sein, damit man Dateien > 64 MB lesen
> bzw. bearbeiten kann.

Nein, das Limit ist 2 GB (oder 4 GB bei manchen Systemen).

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: Grosse Files fuer Perl unsichtbar?

Ferry Bolhar schrieb:
>> Ein system("wc -l $file1") liefert gar nichts usw...
>
> Letzteres wundert mich - bei mir liefert ein
> $file = "nicht_existierende_Datei.dat";
> system("wc -l $file");
> die Ausgabe:
> wc: nicht_existierende_Datei.dat: no such file or directory
> zurück. 'wc' liefert _immer_ eine Ausgabe, entweder die gewünschte
> Information oder einen Fehler. Da stimmt in deinem Skript sonst irgend
> etwas nicht. Du solltest umbedingt den Returnstatus von 'system'
> checken.

Hmm, nachdem Du sagtest, dass wc IMMER was zurückgibt, habe ich
weitergetestet, und selbst sowas funktioniert nicht mehr:
print "Test: " . qx/echo ok/;

Die Methode wo das drin ist wird zig-mal aufgerufen, und immer schreibt
er "Test: ok", erst wenn er das File nicht mehr findet, und gar nix mehr
geht, dann schreibt er "Test: ".

Bei den Perlbugs habe ich von einem gelesen, der hatte wohl ein ähnliches
Problem, der Bug wurde dann aber irgendwann zugemacht, weil es nicht mit
einem anderen Fall reproduziert werden konnte.

>> Und Sonderzeichen ist in
>> umdb2gdf.tmp.l1.edges auch keines (das ist die Datei).
> Der Name ist nicht besonders glücklich gewählt - ist das am
> Ende ein l (kleines "ell", gefolgt von der Ziffer "eins")? Heißt die
> Datei immer so? Wo kommt der Name her?

Ja, die Datei heisst immer so. Es geht um Geodaten, und das sind die
edges für Level 1. Schreibfehler oder so bei den Dateien sind
ausgeschlossen. Das Skript läuft mit kleiner Datenmenge, obwohl der
Programmfluss und die Dateinamen und alles immer das selbe sind.

Nur mit mehr Daten läuft es nicht mehr, und das einzige, was sich da
ändert ist, dass Loops öfters durchlaufen werden. Also an der Logik des
Programms liegt es vermutlich nicht.

Und dass noch ein am Dateinamen hängt ist auch nicht der Fall, der
Dateiname ist hard im Code drin und die Variable wird beim Öffnen fürs
Schreiben und fürs Lesen jeweils verwendet.

Da aber in dem Status nicht mal mehr qx/echo ok/ funktioniert, tippe ich
echt so langsam auf einen Perlbug...

Weitere Tipps und Hinweise weiterhin erwünscht. Das Dumme ist, dass das
Skript immer erst mal ein paar Stunden läuft, bis der Fehler auftritt,
ist also nicht so einfach schnell mal zu debuggen ...

Gruesse,
Dennis

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck writes:

>Die Methode wo das drin ist wird zig-mal aufgerufen, und immer schreibt
>er "Test: ok", erst wenn er das File nicht mehr findet, und gar nix mehr
>geht, dann schreibt er "Test: ".

Klingt nach einem memory- oder filehandle-leak.

Was sagt der Returnstatus von system() ?
--
--
Michael van Elst
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck wrote:
>
> Hmm, nachdem Du sagtest, dass wc IMMER was zurückgibt, habe ich
> weitergetestet, und selbst sowas funktioniert nicht mehr:
> print "Test: " . qx/echo ok/;
>
> Die Methode wo das drin ist wird zig-mal aufgerufen, und immer schreibt
> er "Test: ok", erst wenn er das File nicht mehr findet, und gar nix mehr
> geht, dann schreibt er "Test: ".

qx// gibt die Ausgabe auf stdout zurück, nicht stderr. Wenn Du wissen
willst, ob das Kommando fehlerfrei ausgeführt wurde, musst Du dessen
Ausführungsstatus ($?) prüfen! Alles andere ist Kaffeesatzleserei.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Grosse Files fuer Perl unsichtbar?

"Dennis Scheck" schrieb im Newsbeitrag
news:46dda564$1@news.arcor-ip.de....
>
> Hmm, nachdem Du sagtest, dass wc IMMER was zurückgibt, habe ich
> weitergetestet, und selbst sowas funktioniert nicht mehr:
> print "Test: " . qx/echo ok/;
>
> Die Methode wo das drin ist wird zig-mal aufgerufen, und immer schreibt
> er "Test: ok", erst wenn er das File nicht mehr findet, und gar nix mehr
> geht, dann schreibt er "Test: ".

Vielleicht überschreitest du die Maximalzahl zulässiger Prozesse in deinem
OS. Wie Frank schon schrieb, ohne Prüfung des Ausführungsstatus kommst du
nicht weiter.

Gruß

Klaus

Re: Grosse Files fuer Perl unsichtbar?

Frank Seitz:

>> Hmm, nachdem Du sagtest, dass wc IMMER was zurückgibt, habe ich
>> weitergetestet, und selbst sowas funktioniert nicht mehr:
>> print "Test: " . qx/echo ok/;
>
> qx// gibt die Ausgabe auf stdout zurück, nicht stderr.

qx// gibt überhaupt keine Ausgabe zurück, sonder liefert nur
als Resultat die vom ausgeführten Befehl generierte Ausgabe,
die (hier) als Stringteil zu "Test :" hinzugefügt und dann von
print ausgegeben wird.

> Wenn Du wissen
> willst, ob das Kommando fehlerfrei ausgeführt wurde, musst Du dessen
> Ausführungsstatus ($?) prüfen! Alles andere ist Kaffeesatzleserei.

So ist es.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Grosse Files fuer Perl unsichtbar?

Ferry Bolhar wrote:
> Frank Seitz:
>>
>>qx// gibt die Ausgabe auf stdout zurück, nicht stderr.
>
> qx// gibt überhaupt keine Ausgabe zurück,

....doch, die stdout-Ausgabe des aufgerufenen Kommandos...

> sonder liefert nur
> als Resultat die vom ausgeführten Befehl generierte Ausgabe,
> die (hier) als Stringteil zu "Test :" hinzugefügt und dann von
> print ausgegeben wird.

Ja, Ferry. Geh mal davon aus, dass ich weiß, was qx// tut,
auch wenn meine Formulierung anders interpretiert werden kann.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: Grosse Files fuer Perl unsichtbar?

Frank Seitz:

> Ja, Ferry. Geh mal davon aus, dass ich weiß, was qx// tut,
> auch wenn meine Formulierung anders interpretiert werden kann.

Sorry, Frank. Wollte dir nicht ans Bein pissen.

Ich habe nie bezweifelt, dass _du_ es weißt. Aber möglicherweise
weiß es der _OP_, für den deine Antwort ja bestimmt war, nicht
oder er interpretiert es anders. Daher meine Klarstellung.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: Grosse Files fuer Perl unsichtbar?

Dennis Scheck schrieb:
> ...
> Ich suche schon seit Wochen nach einer Lösung, und bin mit meinem Latein
> am Ende. Hat irgendjemand eine Idee, an was das liegen könnte?!

Hi,

was gibt denn folgendes aus:
system("/bin/ls -l $file1");
system("/bin/cat $file1");

?
Auf jedenfall würde ich um die Programme aufzurufen absolute Pfade
benutzen um sicher zu gehen an erster Stelle das es sich hier nicht um
ein PATH Problem handelt.

--
Regards,
Trinity Of Matrix
E-Mail (only for spammer): trinity.matrix@localhost.localdomain

Re: Grosse Files fuer Perl unsichtbar?

Frank Seitz schrieb:

> qx// gibt die Ausgabe auf stdout zurück, nicht stderr. Wenn Du wissen
> willst, ob das Kommando fehlerfrei ausgeführt wurde, musst Du dessen
> Ausführungsstatus ($?) prüfen! Alles andere ist Kaffeesatzleserei.

Ok, $? für qx/echo ok/ ist "-1", und $! ist "cannot allocate memory".
Allerdings liegt das wahrscheinlich nicht am Hauptspeicher direkt. wenn
ich unter top schaue hat das Skript "nur" 41% des Speichers belegt, und
man kann auch so noch normal an dem PC arbeiten (Irgendwelche Programme
starten wie z.B. Open Office) ohne dass man irgendeine Beeinträchtigung
fühlen würde.

Wir haben mittlerweile rausgefunden, dass mein Kollege in Berlin wo das
Skript läuft ein 64 Bit System hat, alle Rechner auf denen ich es hier
getestet habe nur 32 Bit...

Tipps weiterhin herzlich willkommen.

Dennis

Re: Grosse Files fuer Perl unsichtbar?

On 10 Sep., 00:03, Dennis Scheck wrote:
> Frank Seitz schrieb:
>
> > qx// gibt die Ausgabe auf stdout zurück, nicht stderr. Wenn Du wissen
> > willst, ob das Kommando fehlerfrei ausgeführt wurde, musst Du dessen
> > Ausführungsstatus ($?) prüfen! Alles andere ist Kaffeesatzleserei.
>
> Ok, $? für qx/echo ok/ ist "-1", und $! ist "cannot allocate memory".
> Allerdings liegt das wahrscheinlich nicht am Hauptspeicher direkt. wenn
> ich unter top schaue hat das Skript "nur" 41% des Speichers belegt,

Und wieviel Gigabyte sind das? Irgendwas in der Nähe von 2 bzw 4?
Und was sagt eigentlich
ulimit -a
(aufgerufen aus einer shell des Nutzers, unter dessen id auch das
Skript läuft.)
Weiterhin ist zu schauen nach sonstigen Limitierungen (Prozesse pro
User, etc.), die auf dem betreffenden OS wirksam sein könnten. Hier
hilft oft ein Blick in /var/adm/messages oder die analoge Datei auf
Deinem OS.