This comment has been in my code for a long time. Its taken from a Feb 2005 posting by Aaron Darling.
# http://bioinformatics.org/pipermail/bioclusters/2005-February/002283.html
#
#> One additional factor that can significantly impact the run time is the
#> length of DB sequences that your queries hit. By default, versions
#> 1.2.x and 1.3.0 of mpiBLAST transmit the *entire* database sequence over
#> the wire, not just the portion of the sequence used in the resulting
#> alignment. Nucleotide databases like nt or the human chromosome DB
#> contain sequences several MB in length, which can result in LOTS of
#> network traffic. Long sequences are not usually a problem with protein
#> sequence databases. Fortunately, a workaround exists for blastn
#> searches. The command-line option --disable-mpi-db will prevent workers
#> from transmitting sequences over the network. Instead, the writer
#> process reads only the necessary parts of the sequence from the database
#> on shared storage (e.g. it reads a small amount of data from NFS instead
#> of a large amount of data from worker nodes).
#>
#> Summary: to get good performance, always use --disable-mpi-db when
#> performing blastn searches on databases with large sequence entries like
#> nt and human chromosomes.
Based on the above advice, I've long included "--disable-mpi-db" on the commandline for my large nucleotide databases. I've observed increasingly frequent, reproducible crashes for sometime now. Usually with an mpirun stderr including a message like
[blastall] FATAL ERROR: CoreLib [001.000] gi|56707187|ref|NC_006570.1|: Failed to allocate 154047549 bytes
Removing " --disable-mpi-db" from my command line has eliminated all crashes after several rounds of tests.
I will continue to investigate, but would welcome any relevant information from you all.
--
Mike Cariaso * Bioinformatics Software * http://cariaso.com
# http://bioinformatics.org/pipermail/bioclusters/2005-February/002283.html
#
#> One additional factor that can significantly impact the run time is the
#> length of DB sequences that your queries hit. By default, versions
#> 1.2.x and 1.3.0 of mpiBLAST transmit the *entire* database sequence over
#> the wire, not just the portion of the sequence used in the resulting
#> alignment. Nucleotide databases like nt or the human chromosome DB
#> contain sequences several MB in length, which can result in LOTS of
#> network traffic. Long sequences are not usually a problem with protein
#> sequence databases. Fortunately, a workaround exists for blastn
#> searches. The command-line option --disable-mpi-db will prevent workers
#> from transmitting sequences over the network. Instead, the writer
#> process reads only the necessary parts of the sequence from the database
#> on shared storage (e.g. it reads a small amount of data from NFS instead
#> of a large amount of data from worker nodes).
#>
#> Summary: to get good performance, always use --disable-mpi-db when
#> performing blastn searches on databases with large sequence entries like
#> nt and human chromosomes.
Based on the above advice, I've long included "--disable-mpi-db" on the commandline for my large nucleotide databases. I've observed increasingly frequent, reproducible crashes for sometime now. Usually with an mpirun stderr including a message like
[blastall] FATAL ERROR: CoreLib [001.000] gi|56707187|ref|NC_006570.1|: Failed to allocate 154047549 bytes
Removing " --disable-mpi-db" from my command line has eliminated all crashes after several rounds of tests.
I will continue to investigate, but would welcome any relevant information from you all.
Mike Cariaso * Bioinformatics Software * http://cariaso.com
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Mpiblast-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mpiblast-users
