In article <3rnhdj$mf0 at usenet.ucs.indiana.edu> gilbertd at sunflower.bio.indiana.edu (Don Gilbert) writes:
> The latest release of GenBank has put SRSbuild here into a slow
> crawl. It has been trying to index this release for over 48 hours.
> It makes progress, but at a snail's pace. My guess is that
> this is a memory-limit problem. The previous GenBank build on this
> machine took probably less than 6 hours.
>> The above in my limited experience suggests this machine is paging virtual
> memory too much (page pi/po are kilobytes paged in/out per second)
It does indeed sound like a memory limit.
Does your srscheck+srsupdate index GenBank all in one go, or in reasonable
chunks? The extra EST data in the new genBank has probably changed the
relative index sizes - I certainly saw major differences between EMBL
(March-95) and EMBLNEW (Apr-95 onwards) as the WashU-Merck EST data arrived.
Changing the relative index sizes in odd/genbank.sdl may help. Oops. I
see odd/embl.sdl uses relIndexSize but odd/genbank.sdl uses alloc_factor.
Does this also work to split the indexing? One for Thure to answer ......
You can pick up our embl.sdl file to see how we control EMBL and EMBLNEW
at present - though I have to edit it any day now when EMBL 43 appears.
Aaaarrrrrggghhhh. It's there. Pick up embl.sdl if you dare, but I'll
be editing it today ... The URL is http://www.sanger.ac.uk/srs/srsc?-odd+EMBL
Otherwise I would guess an alternative machine would be a good solution.
Should take less than 48 hours to test it anyway :-)
--
------------------------------------------------------------------------
Peter Rice | Informatics Division
E-mail: pmr at sanger.ac.uk | The Sanger Centre
Tel: (44) 1223 494967 | Hinxton Hall, Hinxton,
Fax: (44) 1223 494919 | Cambs, CB10 1RQ
URL: http://www.sanger.ac.uk/~pmr/ | England
