in reply to How to Accurately Determine Amount of RAM

Hi Rob,

This sounds like an XY Problem to me. Rather than looking into how much memory there is, why not look into the issue of why you're using so much memory?

At a guess, I'd say you are reading the entire file into memory -- and when that exhausts available memory, your script fails. A better approach would be to read the file in a line (or chunk) at a time. Does that help at all?

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

  • Comment on Re: How to Accurately Determine Amount of RAM

Replies are listed 'Best First'.
Re^2: How to Accurately Determine Amount of RAM
by hepcat72 (Sexton) on Jul 08, 2014 at 18:12 UTC
    Hi Alex,

    It's not my program/code that is consuming the memory. It's a system call to a C program called muscle. My script comes nowhere near the memory requirements that muscle does. My script uses a simple hash strategy to find sequences (that are similar to one another and likely to yield positive results) to decide which sets of sequences to send together in a call to muscle. An exhaustive approach which takes very little memory would be to run muscle for every likely pair. I have code that does this and it takes a few orders of magnitude longer to do it that way than to run them all together and parse the results. However, muscle runs faster on large groups of sequences than it does for a full ("likely") pairwise comparison. But if I group too many of the sequences together, I hit memory limitations and things start crashing. So I would like to be able to compute a maximum number of sequences to run per gig of memory and break up my analysis as much as it takes to meet that limit so that I get the best performance.

    Rob

      OK -- I wasn't sure about your situation.

      So then I guess you have to see about maximizing the number of pairs without running out of memory. That sounds like an interesting challenge.

      Alex / talexb / Toronto

      Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.