bowtie hanging after execution
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 btimm@glbrc.wisc.edu
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 btimm@glbrc.wisc.edu
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
We had the same problem while we were running on Galaxy server then we moved to cluster it worked fine. Vasu --- On Thu, 1/13/11, Kelly Vincent <kpvincent@bx.psu.edu> wrote: From: Kelly Vincent <kpvincent@bx.psu.edu> Subject: Re: [galaxy-dev] bowtie hanging after execution To: "Branden Timm" <btimm@wisc.edu> Cc: galaxy-dev@bx.psu.edu Date: Thursday, January 13, 2011, 12:30 AM 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 btimm@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
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 btimm@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 btimm@glbrc.wisc.edu
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Hi, We are running Bowtie 0.12.7 currently. I've updated the wiki to reflect the current version of the tools we're using (thanks for letting us know it was out of date!). Regards, Kelly On Jan 13, 2011, at 11:39 AM, Branden Timm wrote:
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 btimm@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 btimm@glbrc.wisc.edu
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Hi, Updating to the latest revision has solved the bowtie hanging problem. Thanks very much for your help! -Branden On 1/13/2011 10:52 AM, Kelly Vincent wrote:
Hi,
We are running Bowtie 0.12.7 currently. I've updated the wiki to reflect the current version of the tools we're using (thanks for letting us know it was out of date!).
Regards, Kelly
On Jan 13, 2011, at 11:39 AM, Branden Timm wrote:
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 btimm@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 btimm@glbrc.wisc.edu
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
participants (3)
-
Branden Timm -
Kelly Vincent -
vasu punj