CODEWITHSUNDEEP
perlout-of-memory
Meera
Meera

Reputation: 1

Out of memory! in Perl program

sub fetch_ms_table {

  $ms_initial_cnt = 0;
  $logger->info("begin fetching TACCTTREE_MS");

  $SQL = "select $pk_string,LINK_C,LENGTH_Q,PATHS_Q from TACCTTREE_MS tree1 where OUT_Z>\"$process_time\"";

  &execsql($dbp, $SQL);
  $cnt  = 0;
  $cnt1 = 0;

  #load the MILESTONE table data
  while (@data = $dbp->dbnextrow()) {
    $data[0] =~ s/\s+//g;
    $taccttree_ms_cache{ $data[0] }{status}   = "d";    #default the record as deleted.
    $taccttree_ms_cache{ $data[0] }{pk}       = $data[0];
    $taccttree_ms_cache{ $data[0] }{LINK_C}   = $data[1];
    $taccttree_ms_cache{ $data[0] }{LENGTH_Q} = $data[2];
    $taccttree_ms_cache{ $data[0] }{PATHS_Q}  = $data[3];
    $ms_initial_cnt++;
  }

  $logger->info("end fetching taccttree_MS - fetched $ms_initial_cnt rows");
}

The above function fails giving the below log,

INFO> main::fetch_ms_table begin fetching TACCTTREE_MS 
Failed for 'Milestone TACCTTREE table'

Std Err 
Out of memory!

The SQL returns around 5,050,402 rows. The same subroutine is called twice from the main program. The first time it goes through fine and the second time it fails for out of memory

Upvotes: 0

Views: 142

Answers (1)

Ralph Marshall
Ralph Marshall

Reputation: 223

It's a little hard to tell from your example since you are either using global variables or just using them without declaring them; the previous comment about use strict; etc. is a good one.

My thought is that the $dbp variable (which seems to contain all of the results, based on the body of execsql) is consuming space after each call, and you don't have enough free space when the second call comes around. I suggest making dbp a my variable in this function and clearing it out before you exit the function.

Upvotes: 1

Related Questions