[maker-devel] Huge memory usage

[Carson Holt]

You can pre-mask the genome, convert the RepaetMasker results to GFF3 and
pass them in, or just run the ./configure script in the RepeatMasker
directory to configure wublast to be the default.

You can also let MAKER install it's own separate installation of
RepeatMasker using rmblast.  Just go to the maker/src/ directory and run
this command --> ./Build repeatmasker

MAKER will use that installation preferentially if you let it install that.

Thanks,
Carson

From:  padioleau ismaël <ismpadioleau at gmail.com>
Date:  Fri, 13 Apr 2012 17:42:20 +0200
To:  Carson Holt <carsonhh at gmail.com>
Subject:  Re: [maker-devel] Huge memory usage

Dear Carson,

I have a problem with RepeatMasker on my cluster. It work with wublast but
not with Crossmatch. As maker try to run RepeatMasker with default I can not
successfully run maker.

I wanted to know if I can provide to maker the genome already masked (if I
run with wublast externally), I though it was possible but I can't found in
the configuration files where I should provide it i.e : In maker_opts.ctl,
should I provide the result from RepeatMasker to 'genome_gff:' and set
'rm_pass' to 1, or set rm_gff in the 'Repeat Masking' part of the file?
Or maybe I should provide directly the masked fasta as genome reference.

An other solution could be to ask maker to run RepeatMasker with the option
'-e wublast'.

Is it possible to use one of these solutions?

Thanks,

Ismael

2012/4/5 padioleau ismaël <ismpadioleau at gmail.com>
> Dear Carson,
> 
> Thank you for your very quick answering.
> 
> I realised that I missed some error messages and the problem seems to be
> linked to the DB_file package as you suggested. The person in charge of
> installation told me that he will recover the configuration.
> 
> I will test it after the Easter weekend and come back to you if we have other
> issues.
> 
> Have a nice Easter weekend,
> 
> Ismael
> 
> Here Is the error message:
> Use of uninitialized value $DB_File::db_version in numeric ge (>=) at
> /mnt/common/DevTools/install/Linux/x86_64/perl/perl-5.10.1/lib/5.10.1/x86_64-l
> inux-thread-multi/DB_File.pm line 276.
> Use of uninitialized value $DB_File::db_version in numeric gt (>) at
> /mnt/common/DevTools/install/Linux/x86_64/perl/perl-5.10.1/lib/5.10.1/x86_64-l
> inux-thread-multi/DB_File.pm line 280.
> Deep recursion on subroutine "DB_File::AUTOLOAD" at
> /mnt/common/DevTools/install/Linux/x86_64/perl/perl-5.10.1/lib/5.10.1/x86_64-l
> inux-thread-multi/DB_File.pm line 235.
> 
> 
> 
> 2012/4/5 Carson Holt <carsonhh at gmail.com>
>> The test should not use up more then a few megabytes of RAM.  Even on very
>> large datasets you should never really use more that 1 or 2 gig of RAM
>> perl MAKER instance
>> 
>> It's possible that their may be other perl modules that are broken need to
>> be reinstalled on your system.  This can happen when perl gets updated,
>> but you are pointing to modules built for a different perl version with
>> the PERL5LIB environmental variable.  Make sure you you have the latest
>> version of MAKER and run with --debug set.  Collect that output and send
>> it to me (the --debug option does some dependancy checking).
>> 
>> I know there is an issue on Macs with updating perl's DB_File module that
>> causes it to gobble up big sections of the hard drive (it will eventually
>> fill the drive if you let it).  It's not a memory issue but just one
>> example of how broken modules can cause weird behavior.
>> 
>> Thanks,
>> Carson
>> 
>> 
>> 
>> 
>> On 12-04-05 10:14 AM, "pingouinandsheep at gmail.com"
>> <pingouinandsheep at gmail.com> wrote:
>> 
>>> >Hello,
>>> >
>>> >When I try to run the test provided with maker2, maker start to use a
>>> >huge amount of memory. I stoped it after it reach ~100go of memory
>>> >used. I believe the test should not use that amount of memory.
>>> >
>>> >In an other message someone suggest that the bioperl version installed
>>> >could be the cause of the problem, but the bioperl installed on my
>>> >cluster is already at version 1.6.
>>> >
>>> >perl -MBio::Root::Version -e 'print $Bio::Root::Version::VERSION,"\n"'
>>> >1.006901
>>> >
>>> >Unfortunately I don't have an error message to provide, that could
>>> >clarify my problem.
>>> >
>>> >But maybe it is a recurrent problem and you know a few things I should
>>> >check.
>>> >
>>> >Thanks,
>>> >
>>> >Ismael
>>> >
>>> >_______________________________________________
>>> >maker-devel mailing list
>>> >maker-devel at box290.bluehost.com
>>> >http://box290.bluehost.com/mailman/listinfo/maker-devel_yandell-lab.org
>> 
>> 
> 
> 
> 
> -- 
> Ismaël Padioleau
> Evgeny Zdobnov Group (Computational Evolutionary Genomics Group)
> Emmanouil Dermitzakis Group
> Dpt de Médecine Génétique et Développement
> Université de Genève - Faculté de Médecine
> CMU -  Rue Michel-Servet 1
> CH 1211 Genève 4
> Tel: 0041 22 379 59 74
> ismael.padioleau at unige.ch
> 
> --
> Tel. 0041 78 77 69 561
> ismpadioleau at gmail.com



-- 
Ismaël Padioleau
Evgeny Zdobnov Group (Computational Evolutionary Genomics Group)
Emmanouil Dermitzakis Group
Dpt de Médecine Génétique et Développement
Université de Genève - Faculté de Médecine
CMU -  Rue Michel-Servet 1
CH 1211 Genève 4
Tel: 0041 22 379 59 74
ismael.padioleau at unige.ch

--
Tel. 0041 78 77 69 561
ismpadioleau at gmail.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://yandell-lab.org/pipermail/maker-devel_yandell-lab.org/attachments/20120413/b837286a/attachment-0003.html>