locked
How to make spatial computations use more/all CPU power? RRS feed

  • Question

  • Hi,

    In an service I'm calculating spatial data (using Microsoft.SqlServer.Types) in memory. These calculations often take 4-5 minutes but they are never, ever, using more than 50% CPU. I have tried this on a single core too (Azure) and still, CPU won't go above 50%. I'd really like 100% CPU usage in these services. 

    What to look for in the code? I've got a lot of loops and where possible I'm using AsParallell() to take advantage of instances with multiple cores. 

    Why doesn't the service just claim full speed on the CPU and get the job done twice as fast?

    -- 
    Werner


    • Edited by Werner Clausen Thursday, February 6, 2014 12:58 PM
    • Moved by CoolDadTx Thursday, February 6, 2014 3:14 PM SQL related
    Thursday, February 6, 2014 12:57 PM

All replies

  • Hi,

    This is a quick reply to let you know that I'm trying to involve someone familiar with this topic to further look at this issue. There might be some time delay.

    Thanks.


    Tracy Cai
    TechNet Community Support

    Monday, February 10, 2014 3:14 AM
  • Hi Tracy,

    It would be fantastic to get some more speed on these calculation, I'll wait and hope that someone knows about this.

    Thanks.

    -- 
    Werner

    Monday, February 10, 2014 10:42 AM
  • Hi Werner,

    The CPU usage of 50% mentioned in the original post indicates that CPU might not be the bottleneck of the unideal performance.

    If spatial index is used, one potential cause can be that the grid density level might be too low, which could result in lots of I/Os and high waits of the CPU.

    You can tune the grid density by recreating the spatial index. The GRIDS clause of CREATE SPATIAL INDEX allows to specify a different grid density. 

    Wednesday, February 12, 2014 12:25 AM
  • Hi Werner,

    The CPU usage of 50% mentioned in the original post indicates that CPU might not be the bottleneck of the unideal performance.

    If spatial index is used, one potential cause can be that the grid density level might be too low, which could result in lots of I/Os and high waits of the CPU.

    You can tune the grid density by recreating the spatial index. The GRIDS clause of CREATE SPATIAL INDEX allows to specify a different grid density. 

    Thanks, I'll try that this week. Our indexes are created with MEDIUM for all levels at the moment. I'll try HIGH and see if that makes a difference.

    -- 
    Werner


    Tuesday, February 18, 2014 12:58 PM
  • Can you clarify what it is exactly that you're trying to do?

    you say that you're using the .net libraries to perform spatial computations in memory but then you mention that you also have spatial data (i'm assuming from the index comment) in the database..

    Where is the bottleneck? on the db site for when you're pulling out the spatial data or on the .net app server that's running the service?

    Is the query using the spatial indexes? is trace flag 4199 on?

    I found that rolling my own tesselation function greatly improved parallelism in regards to spatial queries, although this is only applicable to point in polygon type queries eg return the name/attribute of the complex polygon in which the lat/long sits

    more info here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/78132bca-2a95-45c1-b93c-64c83827dc4f/sql-2k8r2-any-performance-hints-for-bulk-loading-data-from-spatialgis-db-into-a-data-warehouse?forum=sqlspatial


    Jakub @ Adelaide, Australia

    Friday, March 21, 2014 12:02 AM