[GRASS-dev] Re: [GRASS GIS] #1625: Disk performance degrades by several orders of magnitude on two processes

[GRASS GIS]

#1625: Disk performance degrades by several orders of magnitude on two processes
---------------------+------------------------------------------------------
 Reporter:  sprice   |       Owner:  grass-dev@…              
     Type:  defect   |      Status:  new                      
 Priority:  normal   |   Milestone:  7.0.0                    
Component:  Default  |     Version:  svn-trunk                
 Keywords:           |    Platform:  MacOSX                   
      Cpu:  x86-64   |  
---------------------+------------------------------------------------------

Comment(by glynn):

 Replying to [ticket:1625 sprice]:
 > When there are two GRASS process competing for a single disk on an I/O
 bound task, performance doesn't just half. It decreases by several orders
 of magnitude.
 That's what I would expect, due to more time lost to seeking.
 > However, 'iostat' lists just as much data flowing off the disk as would
 be expected.
 That isn't what I would expect for a normal GRASS command. The only
 obvious case where I would expect that would be with in-memory
 calculations which result in physical RAM availability being exceeded. In
 that situation, memory would keep getting swapped out and back in again.

 > Also, when one task is canceled, the other process doesn't recover.
 'iostat' claims that just as much data is flowing, but the remaining
 process remains degraded until it is canceled and restarted.
 That is odd. Which commands, exactly?

 > I'd try to give a bit more debug info, but I suspect that it's some sort
 of interaction with a caching layer in GRASS where extra data is read, and
 then discarded, many times.
 Most GRASS raster commands just do sequential I/O. Any caching is internal
 to the process; there isn't any interaction between processes.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1625#comment:2>
GRASS GIS <http://grass.osgeo.org>