[mira_talk] Re: Weird problem
- From: Torben Nielsen <torben@xxxxxxxxxx>
- To: mira_talk@xxxxxxxxxxxxx
- Date: Sun, 26 Oct 2014 11:33:53 -1000
Thanks to all who offered suggestions.
Felipe, I did not pre-clean the reads at all. That’s per Bastien. The MIRA
documentation is pretty specific about letting MIRA deal with it. I let MIRA
estimate insert sizes as well.
Chris, I do have a lot of sequences and I don’t expect these runs to finish
overnight. A week or two or even three is just fine. I know I’m using MIRA for
a task it was never intended for. My data is marine metagenomic and it’s a
fairly complex community.
The assemblies I am trying are ones I have tried before. I have two large
datasets that I have previously run MIRA on using older machines (one with
CentOS and one with Ubuntu). MIRA successfully finishes the first pass on both
datasets on both of those machines. MIRA invariably dies on the second pass due
to running out of memory. Both of these older machines have 300 GB or so of
memory available. But MIRA is quite snippety about pointing out that it dies
due to lack of memory.
I made no changes to the datasets or the manifests at all. I just copied them
over to the new machines. The new machines have 1.5 TB of main memory each.
Both were running Fedora 20 straight out of the box. I have now upgraded one
machine to Fedora 21 alpha. MIRA failed on both datasets at the same point in
processing. That is, the log files terminated at exactly the same point. MIRA
continued running after that. Top showed it running and consuming a full cpu.
However, nothing more was written to any files; i.e., the time stamps on the
log files and all other used files were frozen at the same point. I waited
several hours without seeing any change. When I finally decided to kill the
process, it was oblivious even to a “kill -9”; i.e., it had to be hung on
something in the kernel. I had to power cycle the machine to get rid of the
process.
At first I used the MIRA 4.0.2 statically linked binaries straight off the web.
Later I downloaded the sources and compiled my own binaries. It changed
nothing. That is, I saw identical behaviour.
> 1. please check that there’s space on the partition where the log file is
> written. I expect there is, but you never know.
MIRA is running all by itself on a 10 TB (usable) RAID10 (software) setup.
There are no other accounts on the machine.
> 2. if after an additional hour or two things haven’t progressed, perform an
> strace as suggested by Bob. (I’d like to get that)
I’m hoping to try that today. I left MIRA running last night to see if anything
would change overnight. The machine crashed in the middle of the night and I
have yet to work out what caused the crash. I’ll try it again today and run the
strace when it stops writing; a bit before would probably be good.
> 3. in the tmp directory you will find 16 files called “stattmp*.bin”. Please
> copy the 0 and 1 files, the same for hashstat.bin, compress them and please
> send me these three files together with the manifest you used.
Consider hashstat.bin sent. It has zero length. The other two are fairly large.
I’m compressing with bzip2 but it’s still over 50 GB for the two of them. I’m
going to upload them to my Dropbox account and send you a link to them that way
if that’s ok. I’ll send you the manifest file separately.
> Also: I’m just putting together something which will become 4.9.0
> (development version), maybe that could help. Stay tuned.
Thanks a lot. I’ll try anything to get this to work. I considered installing a
different Linux, but I’m reluctant to do that mostly because I’m convinced
there’s a problem in there and I’d prefer to know the problem is gone.
Thanks, Torben
--
You have received this mail because you are subscribed to the mira_talk mailing
list. For information on how to subscribe or unsubscribe, please visit
http://www.chevreux.org/mira_mailinglists.html
Other related posts:
