speicherprobs: ram-speicher freigeben? (Allgemeines zu Perl)

[thread]6166[/thread]

speicherprobs: ram-speicher freigeben?

norman

2004-03-26 16:07

User since
2004-03-11
46 Artikel
BenutzerIn
[default_avatar]

hallo zusammen,

mir ist die speichernutzung in perl nicht ganz klar. folgendes problem:

ich lese eine tabelle aus mysql komplett aus mit:

Code: (dl )

my $ref = $dbh->selectall_arrayref('select * from tab');
# mache den speicher frei
@{$ref} = (); # so???
undef(@{$ref}); # so???
# weiter im programm

frage 1:
warum wird der arbeitsspeicher nicht freigegeben? wie mache ich das?

frage2:
die mysql-db ist insgesamt 20 MB groß. perl nutzt zum einlesen ca. 250 MB RAM. warum????

gruß,
norman\n\n

sri

2004-03-26 17:35

User since
2004-01-29
828 Artikel
BenutzerIn

[quote=norman,26.03.2004, 15:07]

Code: (dl )

1
2

@{$ref} = (); # so???
undef(@{$ref}); # so???

[/quote]

Code: (dl )

1
2
3

# so!
undef @{$ref};
undef $ref; # oder out of scope, hauptsache refcount geht auf null

[quote=norman,26.03.2004, 15:07]
warum wird der arbeitsspeicher nicht freigegeben? wie mache ich das?
[/quote]
Ob der Garbage Collector den Speicher nur für den Prozess oder wieder für das Betriebssystem freigiebt hängt ganz allein vom Betriebssystem und der libc ab mit der dein Perl kompiliert wurde.

[quote=norman,26.03.2004, 15:07]
die mysql-db ist insgesamt 20 MB groß. perl nutzt zum einlesen ca. 250 MB RAM. warum????
[/quote]
Perl Datentypen können da recht verschwenderisch sein auch wenn dein Beispiel etwas sehr arg aussieht.
Vielleicht ein memory leak? Benutzt du iThreads oder ein XS Modul? Welche Perl Version?\n\n

http://mojolicio.us/

norman

2004-03-26 18:09

User since
2004-03-11
46 Artikel
BenutzerIn
[default_avatar]

hi!

nee, threads o.ä nutze ich nicht. das system ist win xp prof., die tabelle ist ca. 23 MB groß und hat 210.000 einträge. hier mal der komplette code:

Code: (dl )

use strict;
use DBI;

my $DB_HOST = "127.0.0.1";
my $DB_PORT = "3306";
my $DB_USER = "root";
my $DB_PASSWD = "";
my $DB_NAME = "test";

my $DB_DSN = "DBI:mysql:$DB_NAME:$DB_HOST:$DB_PORT";
my $dbh = DBI->connect($DB_DSN, $DB_USER, $DB_PASSWD, {PrintError => 1, RaiseError => 0, AutoCommit => 1});

my $abfrage = 'SELECT * FROM cluster;';
my $sth = $dbh->prepare($abfrage); 
$sth->execute();
my $ergebnis = $dbh->selectall_arrayref($sth);
$sth->finish();
		
$dbh->disconnect();

undef @{$ergebnis};
undef $ergebnis;

### hier ist die speicherbelegung immer noch voll

sleep(30);
exit;

### nach beenden des scripts die der speicher leer

ptk

2004-03-26 18:17

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

Code: (dl )

undef $ref

sollte ausreichen. Wenn der Speicher nicht freigegeben wird, kann das folgende Ursachen haben:
* es ist eine zirkulaere Referenz vorhanden (hier wahrscheinlich nicht der Fall)
* es gibt Faelle, wo ein undef nicht sofort zu einer Freigabe des Speichers fuehrt, sondern erst, wenn der aktuelle Scope verlassen wird (das ist z.B. bei Schleifen der Fall)
* der Speicher wird korrekt per free() freigegeben, aber das OS kann die Speicherseiten nicht freigeben. Das kann passieren, wenn hinter dem grossen Speicherblock noch kleinere Stuecke alloziiert wurden, die nach dem Freigeben des grossen weiter bestehen. Jetzt hat man ein riesiges ungenutztes Loch, das man nicht wegbekommt. Das ist nicht die Schuld von Perl, sondern des Speichermanagments des OS.

Dass du ueberhaupt mehr Speicher als erwartet verbrauchst, liegt daran, dass Perl einen Overhead fuer das Speichern von Variablen hat. Ein Integer, das eigentlich nur 4 Bytes belegen muesste, belegt ca. 24 Bytes. Weiteren Overhead kann es fuer benoetigte Referenzen etc. geben. Evtl. wird die Rueckgabe der Datenbank nicht sofort weggeschmissen.

Warum benutzt du eigentlich keine Schleife mit fetchrow?

norman

2004-03-26 18:51

User since
2004-03-11
46 Artikel
BenutzerIn
[default_avatar]

wenn möglich, nutze ich ein zeilenweises auslesen der tabelle, aber in diesem fall brauche ich - wenn möglich - den ganzen datensatz als matrix für eine vektorrechnung.

das perl satte 24 byte pro int braucht, wusste ich nicht. das ist ja ganz schön fett! gibt es eine möglichkeit diese speicherverschwendung einzudämmen?

gruß,
norman

Strat

2004-03-26 19:13

User since
2003-08-04
5246 Artikel
ModeratorIn

du verwendest selectall_arrayref. Brauchst du wirklich alle Datensaetze gleichzeitig im speicher?

nebenbei: undef($riesigeDatenstruktur) ist manchmal nicht so guenstig, weil das unter umstaenden recht lange brauchen kann (ich weiss allerdings nicht, ob dieses verhalten bei perl5.8 immer noch der fall ist; bei 5.6 war es teilweise echt uebel). besser $ref einfach aus dem scope bringen, sodass sich die perl-automatismen selbst darum kuemmern koennen.

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

ptk

2004-03-26 19:53

User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]

PDL benutzen! Damit kannst du die Daten hocheffizient ablegen und brauchst sogar die Vektoroperationen nicht selbst zu definieren.

norman

2004-03-26 23:16

User since
2004-03-11
46 Artikel
BenutzerIn
[default_avatar]

PDL? habs gerade bei cpan gesehn. das ist ja ne menge holz. das wird ne weile dauern.

kannst du mir verraten welches der module für die datenhaltung zuständig ist?

sri

2004-03-27 01:20

User since
2004-01-29
828 Artikel
BenutzerIn

[quote=ptk,26.03.2004, 17:17]* der Speicher wird korrekt per free() freigegeben, aber das OS kann die Speicherseiten nicht freigeben. Das kann passieren, wenn hinter dem grossen Speicherblock noch kleinere Stuecke alloziiert wurden, die nach dem Freigeben des grossen weiter bestehen. Jetzt hat man ein riesiges ungenutztes Loch, das man nicht wegbekommt. Das ist nicht die Schuld von Perl, sondern des Speichermanagments des OS.[/quote]
Woher stammt das Beispiel wenn ich fragen darf?

http://mojolicio.us/

norman

2004-03-27 14:13

User since
2004-03-11
46 Artikel
BenutzerIn
[default_avatar]

macht perl eigentlich speichertechnisch einen unterschied ob ich meine zahlen als 2.3434231234535 oder als 2.34 speichere?

View all threads created 2004-03-26 16:07.