Branden,
Which revision of Galaxy are you using? What this sounds like is that it is taking a long time to set the metadata on the resulting SAM file, i.e., after the Bowtie job has run. Prior to 4698:48a81f235356 (12/1/10), all the lines in a large SAM file would be read to determine how many lines there were--this could take a very long time. But that changeset made it so that it gave up if the file was too large and did not set the number of lines. However, in 4842:7933d9312c38 (1/12/11), this was changed so that if the file is too large, it generates a rough estimate of the number of lines.
Regards, Kelly
On Jan 12, 2011, at 5:32 PM, Branden Timm wrote:
Hi All, I am seeing a strange problem with Galaxy and bowtie. Here is the scenario:
- I run bowtie for Illumina data (bowtie 0.12.5 Linux x86_64) on a
fastqsanger input generated by FASTQ-Groomer 2) On the system, I see the bowtie_wrapper and bowtie subprocesses start, with bowtie distributing across the four cores in the system 3) The bowtie and bowtie_wrapper processes stop a few minutes later, but the history item still shows that it is running. This happens for about 20 minutes. Paster.log show constant POST history_item_updates activities every three seconds, and the Galaxy server process itself hogs 100% of one of the system's cores.
I've tried this both on our production galaxy site (RHEL 5.5, Python 2.4.3) and my local workstation (RHEL 6, Python 2.6.5).
As part of my troubleshooting, I've extracted the bowtie_wrapper command from paster.log and run it on the command line. The tool completes successfully in a few minutes, which confirms that the Galaxy server process seems to be the culprit in this situation, not bowtie_wrapper.
Any help would be greatly appreciated. Cheers
-- Branden Timm University of Wisconsin Great Lakes Bioenergy Research Center btimm@glbrc.wisc.edu
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev