Thanks for the tip, Kelly - I tested this on my workstation at revision 4640 and am seeing the same behavior. The output SAM file is 1.9G. I will pull the latest changes from the repository and re-test.

By the way, is 0.12.1 still the preferred version of bowtie for HEAD? The NGSLocalSetup page indicates so, but seems a bit outdated. I am running 0.12.1 currently.


--
Branden Timm
bt...@glbrc.wisc.edu

On 1/13/2011 12:30 AM, Kelly Vincent wrote:
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:

1) 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
bt...@glbrc.wisc.edu

_______________________________________________
galaxy-dev mailing list
galaxy-dev@lists.bx.psu.edu
http://lists.bx.psu.edu/listinfo/galaxy-dev

_______________________________________________
galaxy-dev mailing list
galaxy-dev@lists.bx.psu.edu
http://lists.bx.psu.edu/listinfo/galaxy-dev

Reply via email to