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 <[email protected]>: > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
