[GRASS-user] GRASS 7 Bottleneck
Maris Nartiss
maris.gis at gmail.com
Wed Feb 29 01:56:26 EST 2012
Hello,
the reasons for slow performance can be different. If performance
concerns You, You should perform Your module run profiling.
Take a look at http://valgrind.org/info/tools.html
>From Your description is hard to tell where's the problem - as it
might be a disk write - those are more expensive than reads; it could
be inefficient memory allocation, cache misses etc. Also 16 CPU's
don't change a thing, as most of GRASS code is single threaded -
unless You run Your module in parallel (data parallelization), You
will use only one CPU/core. Ensure that You don't hit swap, as it will
bring any fast system down on it's knees.
Not helpful,
Maris.
2012/2/28 Seth Price <seth at pricepages.org>:
> I'm running a few instances of GRASS, and I've hit an extreme bottleneck. The problem is that I can't figure out what it is.
>
> I have a module that I wrote in the GRASS 7.0 environment that should be I/O bound. It normally takes about 10 minutes to finish running. I have seven instances running from one disk, and each one is taking on the order of 10 hours to finish. Why?
>
> NOTE:
> - The processes aren't I/O bound. 'iostat' lists a constant 30 MB/s transfer rate. It should be able to handle twice that. The transfers per second are < 100, and I've seen it handle triple that (at 60 MB/s).
> - The load average is currently below 1. I have 16 processors, so CPU shouldn't be a problem.
> - I have 16 GB of RAM, and it's full, but not thrashing.
>
> If it's not I/O, CPU, or RAM, then what is it slowing GRASS?
> Thanks,
> Seth_______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
More information about the grass-user
mailing list