In article <PMR.96Dec10094330 at unst.sanger.ac.uk> pmr at sanger.ac.uk (Peter Rice) writes:
>In article <32ACBDA7.57D9066B at pku.edu.cn> Tao Jiang <jiangt at pku.edu.cn> writes:
>> I downloaded the SRS version 5.0, and had a small test
>> yesterday. I installed only a very small part of EMBL
>> : phg.dat, and try to index it. To my surprising, I
>> found it would take me over 12 hours to index it (in fact,
> the indexing hasn't finished yet)
>> SRS 5.0 splits EMBL into smaller chunks (defined in embl.i as
> partSize:100000 for 100000 entries), and builds a separate index for
> each. There is a new "srsbuild -m" step which merges these smaller
> indices together once they have been compressed.
>> Having said that, I seem to have problems with the EMBL indexing
> too, so I am still checking on what is happening. After 82500+ entries
> from est1, I get:
>> > SRSDB:embl.is:70: error: insufficient memory - error during malloc,
> > could not allocate "Cursor object"
I tracked down the problem. It was caused by srsbuild using more
memory (131Mb) than I had available.
Even reducing "partSize:100000" in embl.i failed to reduce this by much.
I have increased the limits (unlimit datasize) on the machine I used.
For your very slow runs, I assume that srsbuild is using more memory
than the machine has, and it has been swapping like crazy.
I guess this is connected with changes in EMBL indexing since the last
beta release (there have been several changes that could trigger it),
but that is something Thure is best able to answer.
--
------------------------------------------------------------------------
Peter Rice | Informatics Division,
E-mail: pmr at sanger.ac.uk | The Sanger Centre,
Tel: (44) 1223 494967 | Wellcome Trust Genome Campus,
Fax: (44) 1223 494919 | Hinxton, Cambridge, CB10 1SA,
URL: http://www.sanger.ac.uk/~pmr/ | England
