ThinkGeo.com    |     Documentation    |     Premium Support

Memory and CPU problem

#1

I'm having a lot of problems with memory and CPU usage in the server. 


I've made some samples with just one simple shapefile (my final map is loading much more data).


And is consuming a lot of resources with just ZoomIn and ZoomOut. A try the same data with QuantumGIS and it's resource consumption is much less then thinkgeo's WPF sample.


With the Web sample I just open 3 browsers to simulate 3 users and got memory consumption ~ 600MB/700MB, and CPU 95% and more.


In the production server i'm having even more problems, since I'm using a big Oracle database. Thinkgeo starts raising some errors, like memory overflow, ORA:1426, and others (The layers sometimes works other times raises errors).


please download the samples and sample data from:


hotfile.com/dl/89858812/d6b86a6/ThinkGeoMemory.7z.html


 


 



#2

Hi Rui, 
  
 Thanks for samples, i agree with you that it’s a problem which has been submitted to our development team. Please let me introduce why this happened. When mapSuite draw the feature in certain extent, it must need to read all the features within the extent into   memory with specified .dbf information. And then draw the image in memory at first. If we use the SingleTile and set the current extent as full extent, it means that all the data will be loaded into memory and are disposed after drawing. I strongly recommend you to use MultiTile instead, it will load less data in a smaller extent and collect the memory unused immediately. Additionally, can you let us know your detail of the application? Maybe we can provide some workarounds. Waiting for the further information. 
  
 Thanks . 
 Johnny 


#3

The application is a simple online viewer for a Oracle DB. This Oracle DB has at the moment 74 layers, and in the map they should appear as independent elements. 1 oracle’s table -> 1 thinkgeo Overlay. 
  
 DB size: almost 1GB at the moment. 
  
 there are some tables that have more then 100K of rows, but those don’t show up at the beginnig so is fast. I’ve “tunned” yours oracle provider for the bounding box, I submitted here in the forum the optimization, but I guess you didn’t apply to yours, so if I use yours I think you will read full table into the memory. 
  
 But my biggest worry is really the resource consumption comparing with others like QuantumGIS. And this memory consumpting is causing some instability to the application. 
  
 I wish to help you more, but I don’t have access to your code, if I had maybe I could see something, since I have this big dataset. 
 You alse have big Oracle datasets, don’t you? 
  


#4

 


Hi Rui,
Thanks for your detailed information. I need to say we didn’t do a test with a so big dataset, up to 1GB. Now someone has been working on that, I think they can give something here later. You mentioned “I submitted here in the forum the optimization”, is it possible to let me know the links about them, so that I can take them into account?
Thanks,
Johnny

#5

Take a look at the following post: 
  
 gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/12/aft/7864/afv/topic/Default.aspx

#6

Hi Rui, 
 Thanks for providing the further information. Now we are preparing the big dataset in Oracle, maybe we need to spend few days on it, sorry for the inconvenience.  
 Thanks, 
 Johnny 


#7

How are things going?

#8

Hi Rui, 
  
 One of our developer is still working on this issue. We found the old version doesn’t use the spatial index in Oracle so that it queries slow. We are now still researching on the CPU and memory issue; just let you know it is still in progress. 
  
 Thanks, 
 Howard

#9

Hi Howard, 
 yes the not using the spatial index is some of the things I discussed in my post gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/12/aft/7864/afv/topic/Default.aspx before. 
 In my code I’m using the spatial Index, with the query I posted in the forum. 
  
 I think there is something wrong when you are rendering the things, as I post before using shapefiles is also very slow comparing OpenSource Desktop QuantumGIS and yours WPF API. 
  
 Could it be that you are loading to much information to memory? Are you loading also alphanumeric data when rendering? 


#10

Hi Rui, 
  
 So the research is still in progress. As far as I know, we only query the features in side of current viewport extent; then save it into the memory. Here are two things might cause the high CPU and memory usage. One is the viewport extent is pretty big so that, all features on your layer are be queried. While another reason is that the querying doesn’t work with the index which makes low performance. Thanks to your advice.  
  
 I guess, slow for shapefile is because the projection you added. Would you mind to remove the projection and set simple style instead to test. On the other hand, did you try WPF edition or WPF Desktop Edition? WPF Desktop has better user experience, please have a try. 
  
 Thanks, 
 Howard

#11

when you say: "then save it into the memory.", are you fetching into memory all columns on the table? Or only the Geometry?



#12

Rui, 
  
 That’s a good question. When we request features from a layer, the column values are requested when we need get them. For example, when you call get features method, we usually have two parameters. One is viewport extent to request features, another one is the retrieve column value condition; such as all columns or some specified column names. 
  
 During rendering, we don’t get all columns back if the column value is not needed; in another word, most of time, only geometry and feature id is requested. 
  
 Thanks, 
 Howard

#13

Well, those are not very good news :( 
  
 And the use of COM objects? You are using some, are they being free from memory?

#14

Hi Rui, 
  
 Currently, all for OracleFeatureSource is managed code. Just as Howard has mentioned, the low performance is caused by the spatial index, and we can address that the increased memory comes from the conversion between different projections, but we are still on the road. 
  
 Thanks, 
 Johnny 


#15

But is the projection related code also in managed code?

#16

Rui, 
  
 Definitely, Yes. But we are getting closer to the end. And any result will be posted here. 
  
 Thanks, 
 Johnny

#17

Any progress?

#18

 


Hi, Rui
Here’s the latest news about the memory and CPU consuming problem. We’ve tested the following classes in MapSuiteCore for Projection. ManagedProj4Projection, UnmanagedProj4Projection, Proj4Projection. We found that the memory consuming problem occurred in all of them.
However, while using ManagedProj4Projection or UnmanagedProj4Projection, the conversion is much faster than using Proj4Projection.
Here are two sets of data coming out of our tests with the shapefile you provided in your sample.
Test1:
Use code sample you provided:  ThinkGEOWEB_MemoryTest( 4 browsers to simulate 4 requests)



    
        
            
            ClassName
            
            
            Time First Imaged Returned(sec)
            
            
            Memory(MB)
            
            
            CPU(%)
            
        
        
            
            Proj4Projection
            
            
            45~60
            
            
            200 ~700
            
            
            25~70
            
        
        
            
            ManagedProj4Projection
            
            
            <30
            
            
            200~700
            
            
            25~70
            
        
        
            
            UnmanagedProj4Projection
            
            
            <30
            
            
            200~700
            
            
            25~70
            
        
    


 
Test2:
Just call GetAllFeature method in MapSuiteCore.



    
        
            
            ClassName
            
            
            Time All Feature Returned (sec)
            
            
            Memory(MB)
            
            
            Memory After Calling GC.Collect (MB)
            
            
            CPU(%)
            
        
        
            
            Proj4Projection
            
            
            26
            
            
            180
            
            
            14
            
            
            25
            
        
        
            
            ManagedProj4Projection
            
            
            14
            
            
            180
            
            
            14
            
            
            25
            
        
        
            
            UnmanagedProj4Projection
            
            
            14
            
            
            180
            
            
            14
            
            
            25
            
        
    


 
So, you can have a try on both ManagedProj4Projection and UnmanagedProj4Projection to see if it helps to improve the performance.
The other issue you’ve mentioned in the first post: “memory overflow, ORA: 1426”. Is it possible that the error is caused by some large geometry data?
We had encountered this kind of error when we were preparing some large data tables for Oracle Spatial. For example, like a record of a MultiplePolygon has more than 8,000 points in it, when calling Get_WKB function on this field, the same error is raised at the server side, in SQLPLUS. 
We’ll keep on working to solve the memory consuming problem. That’s for your information and advice.

Thanks.



#19

Hello, 

I have a column with the WKB pre-generated since sometimes the oracle's get_wkb() just takes to long. So when I get the WKB I'm really getting it from this pre-generated WKB. Then I have some PL/SQL that updates the WKB value as needed (for example: insert or updating). 



The memory overflow is not caused by large geometry data. When it happens, I just refresh the layer and it shows OK. And only happens after a while working on the map. Is like it's related with the memory usage. 


Since both services are in the same server (Oracle & IIS) could be this? ThinkGeo just sucks all the memory and there is some need on Oracle's side, could it be?



I've tested with a separated server, and this error don't appears, but thinkgeo started complaining about the WKB not being well formatted, although when I refresh the layer everything is nice again.  



I really think that all this problems are related with the amount of memory consumption by thinkgeo.



#20

 


Hi, Rui
Thanks for providing the information. I took your advice and tried to enlarge the memory of Oracle 10g server (In the past it was 1G, and now it’s 2G). It did help to reduce the frequency the error I mentioned in the earlier post, somehow, I still can’t get rid of it. At first I thought it probably was caused by the memory pressure during the querying, but after checking the performance of the Database Server, I found total memory usage just stayed at about 900MB. I can’t help but wondering if this kind of data is suitable for Spatial Querying, additionally, it’s weird that it seems this kind of error occurs randomly, it fits for the description in your post (At first, it works fine, after zooming in and out, the error is raised) .Here is the error message I got, I don’t know if it’s the same with the one you got in your application. It’s probably thrown at the server side and caught by the System.Data.OracleClient.
ORA-29532: Java call terminated by uncaught Java exception: java.lang.OutOfMemoryError
ORA-06512: at "MDSYS.SDO_UTIL", line 1960
ORA-06512: at "MDSYS.SDO_UTIL", line 1982
ORA-06512: at "MDSYS.SDO_GEOMETRY", line 30
Here’s another thing about the memory problem. We’ve found out the it’s the projection and the way we handle projection caused the large memory consumption, however, it’s not a memory leak, since when the memory pressure goes up, GC will recycle the garbage on the LOH, where most of the WKB bytes go (For the shapefile you provided in your sample, about up to 100MB), manually call GC.Collect will also have the memory pressure reduced.
We’ve created an issue about the memory consuming problem in our own issue system, and we’ll let you know if there’s any progress in fixing this problem.
I beg your pardon for keeping you waiting for so long, and I really appreciate if you would provide us further information.
Thanks.
James